The Thesis

Est. 2026

ZipF - The Physical Commerce Intelligence Company

A full-stack commerce infrastructure play: our own POS hardware, a fully in-house software suite, and payment rails - deployed as one integrated terminal network that turns every offline transaction into a structured commerce event, and builds a proprietary demand graph of the physical economy on top. Because ZipF generates the bill itself, every transaction is captured regardless of how it is paid - UPI, card, wallet, or cash. Restaurants are the wedge; every checkout counter in the physical economy, in India and worldwide, is the market.

White paper · v3.0 August 21, 2026 · ZipF · Live FX ₹96 = $1

Every market figure in this document is verified against published 2024-2026 sources, cited inline and in the appendix.

Executive Summary

Websites, apps, and platforms that claim to know what is happening in local commerce - maps, review sites, discovery listicles, influencer content - are all built on proxies: ratings, check-ins, SEO articles, foot-traffic pings. None of them know the one thing that actually matters: what people actually bought. Item-level, price-level, time-stamped, sentiment-attached purchase truth sits locked inside millions of merchant POS systems and payment rails, and nobody has aggregated it into a queryable asset.

Whoever owns the transaction event stream sits upstream of everyone else.

ZipF deploys its own commerce terminal - company hardware running a fully in-house software suite (POS + billing + payments + QR customer surface + feedback + loyalty + analytics) - into physical merchants, starting with restaurants and cafés, priced at ₹199-₹499/month so that merchants adopt it as an obviously good deal. The terminal is the business's sensor. Every bill it touches becomes a structured commerce event: who (anonymous/repeat), what (line items), where (outlet, neighborhood), when (timestamp), how much (basket), how they felt (feedback and sentiment), and what happened next (repeat visit, redemption). Aggregated across hundreds of thousands of merchants, those events become a Commerce Event Graph - a continuously refreshed, proprietary dataset of real-world demand that no maps platform, review site, delivery app, or footfall company can structurally reproduce.

Distribution runs two converging funnels. The integration funnel connects the POS systems merchants already run - Square, Toast, and Clover in the US; Petpooja, Razorpay, and Restroworks in India - and delivers Commerce Brain intelligence within minutes of an OAuth connect. The hardware funnel deploys the ZipF terminal as the flagship: the complete event stream, payments, and automation in one device. Software acquires the merchant; intelligence retains them; the terminal completes the data. That sequence gets ZipF to market on two continents from day one, with the terminal arriving as an upgrade merchants ask for rather than hardware a startup has to push.

The platform in one view

• Layer 1 · Hardware - the ZipF commerce terminalCompany-owned Android terminal, white-label manufactured to spec (₹25,000 landed). Bills, prints, accepts UPI and cards, and renders the QR customer surface at every checkout.
• Layer 2 · Software - 100% in-house suitePOS and billing, payments, KOT/order management, CRM and loyalty, feedback and review routing, offers engine, merchant analytics app. One codebase, one data model, zero third-party software dependencies.
• Layer 3 · Infrastructure - the event pipelineEvery bill, scan, payment, rating, and redemption is written as a normalized commerce event into an India-resident pipeline: event capture → normalization (menus, SKUs, categories) → the Commerce Event Graph.
• Layer 4 · Intelligence - the productsMerchant AI and benchmarking, market and CPG intelligence, closed-loop ad attribution, site selection, proprietary indices, governed data APIs, and the Commerce Signal Network for systematic, quantamental, and high-frequency desks.
• Layer 5 · Monetization - sixteen revenue layersMerchant SaaS, payments economics, loyalty, offers marketplace, advertising and attribution, enterprise data contracts, API and token licensing, city intelligence, and capital-markets signal feeds - all riding one installed base and one dataset.

The Opportunity

Local commerce already runs on a multi-billion-dollar B2B data supply chain - it is just assembled from proxies. Discovery publishers build "best restaurants in town" content from mapping APIs (Google Places, Geoapify), review aggregators (TripAdvisor, Yelp), social chatter, direct PR submissions, and manual scouting - then monetize the resulting attention twice: once directly (sponsored listings, "pay-to-play" placement, affiliate booking commissions of $0.25-$2.50+ per cover via OpenTable/Resy), and once indirectly, by feeding reader behavior into the ad-tech and identity-resolution stack. Enormous value flows through this chain, yet every participant is working from second-hand signals.

The five-layer stack between a kitchen and a hedge-fund terminal

Industry structure of today's local-discovery data economy. ZipF sits below all five layers - at the source, where the record is created.

The defining design principle follows directly: ZipF is built on its own rails. The proprietary asset comes entirely from the company's own merchant network, its own POS software, and its own transaction/feedback infrastructure. External APIs (Google Places, Foursquare) serve purely as enrichment - merchant identification and metadata - which keeps the core dataset fully owned, fully licensable, and free of upstream platform dependency. That is the most defensible position in the stack.

The Product

The merchant-facing proposition is one sentence: "One terminal runs your whole counter - billing, payments, reviews, loyalty, and intelligence - from ₹199/month." Merchants adopt readily because at ₹199-₹499/month the bundle (POS + payments + reviews + feedback + loyalty + analytics) is self-evidently worth it, and because the software is in-house the marginal cost of serving each merchant is near zero. Strategically, the subscription both pays for itself and funds the growth of the network's data asset.

The in-house product suite

Token architecture - the QR carries a pointer, the bill stays server-side

The QR encodes only a transaction token; the bill itself lives on ZipF's servers - dynamic, verifiable, privacy-safe, and unlimited in what it can carry. The terminal generates the token at billing time; the customer's scan resolves it server-side:

Four data-acquisition layers

One transaction, fully captured

The Commerce Event Graph

Internally, the dataset is the Commerce Event Graph: every event answers eight questions, and the joins between events answer the questions markets pay for.

The data spine

The canonical commerce ontology - the quiet technical moat

Cross-platform intelligence lives or dies on normalization, and normalization is a deceptively hard problem that compounds in ZipF's favor. One POS calls an item SKU 7843, another Item ID 88321; the same product appears as "COLD BREW LARGE", "Cold Brew - L", and "CB 16oz". ZipF's normalizer resolves all of them to one canonical product, then normalizes price, quantity, category, location, merchant, time, and units across every source. The result is a canonical commerce ontology - a cross-POS product and entity graph that grows harder to reproduce with every integration and every month of history.

You aren't collecting reviews. You're collecting demand.

Why this beats every existing local-commerce dataset

The moat condition, concretely: after ~2 years of deployment the target graph is 70,000 restaurants · 500M transactions · 4M menu items · 300 cities · 20 restaurant categories. At that point ZipF answers questions no competitor can trivially reproduce: What dishes are exploding in Bengaluru? Which cuisines are growing fastest in Pune? What price point kills dessert conversion? Which neighborhoods show early Korean-food demand? Which chains are gaining share with 18-24-year-olds? Which menu items rise before Google search volume catches up?

Market Opportunity

ZipF monetizes across five stacked markets: (1) the underlying Indian food-services economy it instruments, (2) the merchant software/POS market it sells into, (3) the alternative-data / commerce-intelligence market it licenses into, (4) the retail/commerce media market its advertising layer taps, and (5) the global POS infrastructure market the same stack addresses worldwide.

5.1 · The base economy: Indian food services

5.2 · Payments and terminals: the rails are ready

5.3 · The intelligence market this sells into

Card panels see a total at a merchant. ZipF sees the bill that created it: SKU, quantity, price, discount, basket, location, time, sentiment, and repeat. That is the same buyer class, at item-level fidelity, from merchant operating infrastructure rather than a reconstructed card panel.

5.4 · The advertising market the attribution layer taps

5.5 · TAM stack summary

5.6 · The global picture - every checkout counter on earth

The 5M-device India plan addresses under 2% of the world's installed terminals. People pay at counters everywhere, and the machine economics travel: the same terminal + in-house software + event pipeline works at a café in Bengaluru, a diner in Austin, or a pharmacy in Dubai - and because ZipF generates the bill, capture works identically across UPI, cards, wallets, and cash in every market. India is the beachhead for density and cost advantage; the US - where Toast has proven merchants pay $13K+ per location per year for exactly this category of software - is a day-one second theater.

Every checkout counter on earth is addressable.

Global revenue ceiling - per-device economics × world installed base

5.7 · The US market - proven ARPU, day-one entry

ZipF enters the US on day one through the Square and Toast ecosystems, where merchant willingness to pay is proven at public-market scale. Toast alone powers roughly 20% of US SMB and mid-market restaurants and earns about $13,300 of ARR per location per year; Square processes $250B of GPV across 4.5M+ sellers. The integration-led funnel reaches these merchants through the Square App Marketplace with zero hardware capex - and every US location carries roughly 70× the per-device revenue of the India base case.

Go-to-Market: Intelligence First, Terminal as Flagship

We go to market in a deliberate sequence. We connect the POS systems merchants already use, we win them with intelligence, we grow the cross-platform graph, and we finish on our own terminal. Every stage compounds into the next. None of them wait on a factory.

• 1 · We connect firstWe attach to Square, Toast, and Clover in the US (OAuth, delegated seller access) and Petpooja, Razorpay, Restroworks, and GoFrugal in India. A merchant connects an existing POS in minutes. We are in market on both continents without manufacturing a single terminal.
• 2 · We win with Commerce BrainOne product, not a hundred features. We connect a POS and within 10 minutes we tell the merchant what the business made, what changed, which items and customers are over- and under-performing, and today's action plan - then we execute it on command.
• 3 · We grow the cross-platform graphEvery merchant we connect feeds the normalizer and the Commerce Event Graph, POS-agnostic. We answer questions no single platform can answer from its own data. That is the moat we hold.
• 4 · We finish on our own terminalA connection gives us 60-80% of the available data. Our terminal gives us the complete commerce event stream - payments, QR sentiment surface, offers, automation. Merchants who want the deepest intelligence upgrade to the device we own. Software is how we acquire. The terminal is how we complete.

How the moat compounds

The stages stack: a cross-platform graph across 10+ ecosystems is a strong moat on its own; adding 100K+ owned physical endpoints makes it formidable; adding years of history, the canonical ontology, workflow lock-in, cross-industry coverage, enterprise contracts, and closed-loop measurement makes the network effectively unclonable - a competitor would have to recreate the entire network, not copy the software.

Distribution and the flywheel

The Sixteen-Layer Monetization Stack

The same underlying event graph is sold in sixteen distinct forms to sixteen distinct buyer groups. None of the later layers require new data collection - only new packaging, governance, and sales motions. The stack is sequenced deliberately: Layers 0-2 fund data acquisition; Layers 3-11 are high-margin expansion; Layers 12-15 are the endgame. Price per customer rises as the buyer moves from merchant analytics to brands, advertising, research, PE/venture, systematic and quantamental funds, macro and commodity desks, and low-latency trading teams.

Layer detail

Proprietary Indices and the Commerce Signal API

The endgame packaging is a family of branded, derived indices and a production API - ZipF's own IP, compressing the network into numbers and feeds a desk can subscribe to, with granularity a pricing dial. Events originate from merchant operating infrastructure ZipF owns. That provenance is the product: stable collection, item-level fidelity, and a capture layer no card panel reconstructs.

Three primitives sit under every contract. Events are observed economic activity. Signals are processed, normalized indicators. Forecasts are what those signals imply about a company, category, or economy. The path is Event → Signal → Forecast → Decision. Different customers pay at different layers.

Signal surface

Value steps up the stack. Event-level access is the infrastructure license. Category demand is the market view. Company same-store estimates are the nowcast. Panel-implied revenue versus consensus is the estimate the desk trades. Point-in-time backtested expected return over the next sessions is the alpha layer. We sell each layer as its own SKU, with the last the most restricted and the most expensive.

Revenue Model and Scenarios

9.1 · SaaS-only ARR ladder (floor revenue)

9.2 · Full-stack revenue scenarios (illustrative models, not forecasts)

9.3 · Enterprise contract price book (to be market-tested)

9.4 · Commerce Signal Network - token, seat, and exclusivity price book

Capital-markets customers buy on-demand usage, API credits, and data tokens rather than a single annual dump. Three meters: data tokens (API calls), compute tokens (jobs such as "restaurant demand for these 4,000 companies"), and signal tokens (implied revenue-growth and alpha endpoints). The token is the unit of access to economic information.

The division does not need millions of data customers. A few hundred valuable seats is the model:

Operating scenario for L15. YipitData at ~$280M ARR (2026) is the proof that normalized alternative data, sold as institutional intelligence, supports that scale of contract book.

Unit Economics

10.1 · Cost to acquire and deploy one merchant

10.2 · What one mature merchant generates per month

Variable costs cover cloud, support, device maintenance, borne payment costs, SMS/WhatsApp, fraud/shrinkage, servicing. The payments + POS + data + advertising combination - not POS SaaS alone - is what makes the machine economics work.

The Path to Cash Cow

The company's defining financial question: "How much capital is needed to subsidize the first X merchants until the installed base becomes self-financing?" Cash-cow is defined precisely: cash generated by the existing installed base exceeds the cash required to acquire and deploy the next cohort plus corporate operating costs. Past that point, more merchants → more cash → more merchants, with no further equity needed.

11.1 · Stage model at ₹1,500/month mature contribution

At 167,000 locations, the network starts funding itself.

11.2 · The self-funding threshold equation

11.3 · Interactive model explorer

The three levers that drive the entire company - contribution per merchant, all-in CAC, and monthly burn - are adjustable below. Every headline metric and the installed-base chart recompute instantly.

Strategic Focus and Sequencing

Every Vertical, Every Geography - and the Comparables That Prove Each Piece

Restaurants are the starting wedge because transaction frequency is high and item-level data is excellent - but the terminal works wherever a bill is made. The system generalizes across the physical economy, and each new vertical multiplies both the SaaS TAM and the intelligence surface:

At full breadth the graph becomes a real-time physical-economy sensor: what people eat, buy, refill, book, and repair at the counter. Restaurants (food), retail (goods), pharmacies (categories), salons (beauty), gyms (fitness), entertainment (attendance and spend), hotels (occupancy-linked retail), events, electronics, auto/service. The same logic runs geographically: India first for density and greenfield, the US from day one for ARPU (Toast's $13K+/location proves the willingness to pay), then every market where people pay at a counter - which is all of them. Payment-method agnosticism makes the stack portable: it needs no UPI, no specific card network, no local payments monopoly - only a counter that issues bills.

The blueprint economics: software is the hook, the transaction stream is the engine

Square and Toast prove the economic architecture ZipF is built on. Neither is really a "$49/month POS company" - both are payments companies with a POS operating system attached. The low subscription gets the merchant; the transaction flow, financial products, and adjacent software carry the economics. The POS is the control plane.

Every piece of the model has a live proof point

No single competitor combines all five: subsidized hardware + SMB SaaS + payments economics + zero-party sentiment + a licensable cross-platform commerce graph. Toast is closest in stack but US-centric and does not sell market intelligence; Square owns payments + POS but its view stops at the edge of its own network - it cannot compute POS-agnostic neighborhood demand; Pine Labs/Paytm own acceptance but not item-level or sentiment data; Petpooja owns restaurant software but not the data business; LiveRamp/Visa own data markets but not the capture layer; Consumer Edge and Bloomberg Second Measure own the financial-markets buyer and the card-panel nowcast, not the merchant operating system that writes the bill. Because ZipF sits above every ecosystem it integrates, each of these players is a data source, distribution partner, or downstream buyer before it is a competitor. The open position is the intersection: capture the event, publish the signal.

Appendix

Every bill on earth is a data point. ZipF is the machine that reads them.