The Thesis

Est. 2026

ZipF - The Physical Commerce Intelligence Company

Physical commerce intelligence: own POS hardware, in-house software, and a demand graph of the real economy. Every bill at a physical location becomes a structured event - item, price, place, time, sentiment, repeat - that models, agents, and desks can query. Restaurants and foodservice are the first wedge. The same schema covers a café, a salon, a retail outlet, a clinic. 292 million checkout endpoints already exist. Agents will need them to be machine-readable.

White paper · v3.4 August 27, 2026 · ZipF · quoted in dollars

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

The boxes measure the physical economy and the software/data layers that sit on it. Foodservice is where ZipF lands first because frequency and SKU-level bills are richest. The product is physical commerce intelligence - models of demand, not another restaurant directory.

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 locations, starting with restaurants and cafés, then the same schema at salons, retail outlets, and any counter that writes a bill. In the US we connect first at zero hardware capex through Square, Toast, and Clover, where merchants already pay on the order of $13,300 of software-and-fintech ARR per location. India is a later density beachhead on the same stack. The terminal is the location's sensor. The flagship device also writes the room - occupancy from the Wi-Fi radio, queue from 60 GHz mmWave in the bezel, air from a CO2 cell - and signs the bill and that occupancy on a secure element at the second they happen. 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 outlets, those events become a Commerce Event Graph - a continuously refreshed model of real-world demand that no maps platform, review site, delivery app, or footfall company can structurally reproduce. That graph is what future agents query when a static filter is not enough.

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 terminalUS and worldwide first: connect to the Square, Toast, or Clover already on the counter, $0 hardware capex. Flagship is a company-owned Android terminal: about $199 landed in the US (under Square Terminal at $299) and ₹10,000 (~$104) on the India beachhead. Bills, prints, accepts cards and local rails, renders the QR customer surface, measures the room (Wi-Fi CSI / 802.11bf, 60 GHz mmWave, CO2), and signs the ticket and occupancy on a secure element at creation.
• 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 region-resident pipelines (US and India day one): 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 - seventeen revenue layersMerchant SaaS, payments economics, loyalty, offers marketplace, advertising and attribution, enterprise data contracts, API and token licensing, city intelligence, capital-markets signal feeds, and prediction-market settlement - 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 in every market: one surface runs the whole counter - billing, payments, reviews, loyalty, and intelligence. In the US we connect first through Square, Toast, and Clover at $0 hardware capex; US operators already pay $0 / $49 / $69-$149 per location per month for POS software, and Toast's full stack earns about $13,300 of ARR per location. The same bundle lands later in India as a density beachhead. Because the software is in-house, the marginal cost of serving each merchant is near zero. The subscription pays for itself and funds the data asset.

The in-house product suite

The flagship terminal as a room sensor

The ZipF terminal is the location's sensor. It writes the bill. It also writes the room, from parts that live in the same chassis, and it signs both at the second they happen. Occupancy next to tickets is conversion. Queue next to tickets is wait and walk-away. Air next to occupancy is a second read of how full and how stuffy the space is. That join is what merchants, brands, agents, desks, and prediction venues query from one fleet.

Line drawings of each module sit after the Commerce Event Graph.

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 nine 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.

We are not collecting reviews. We are 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, spanning US metros and the India beachhead. At that point ZipF answers questions no competitor can trivially reproduce: What dishes are exploding in Austin? Which cuisines are growing fastest in Brooklyn? What price point kills dessert conversion in Chicago? Which Dubai neighborhoods show early Korean-food demand? Which US chains are gaining share with 18-24-year-olds? Which menu items in Bengaluru and Pune rise before Google search volume catches up?

The moat is the full funnel, not extra fields on the bill

A POS competitor can match line items, taxes, and tenders. That is not a moat. Hardware that exposes "more data points than Square or Toast" is a feature they can copy. The durable edge is seeing what happens before the bill and after it, then joining that to the bill itself: discovery → view → consideration → intent → purchase → experience → feedback → repeat. Traditional POS companies see the last completed sale. Ad platforms see attention. CRM companies see customers. ZipF sits on the layer that connects all four.

We do not win by collecting more columns on the receipt. We win by seeing the entire funnel.

Travel already proved the mechanism. Look-to-book in booking engines is commonly on the order of 100:1 (a 1% conversion). Direct hotel websites convert at about 2.2-3.9%; OTAs convert the same query at 12-15% because the visitor arrives with higher intent and a lower-friction representation. We take that mechanism to the physical counter. Representation quality and pre-purchase intent determine economics, and the company that observes consider-to-buy - not only sold-to-paid - owns a harder dataset to reconstruct.

In plain English

• A guest asks their agent for a five-star lodge tonight: lake-view room, dinner still plating, table at 8. We already wrote the folio and the last kitchen ticket. The agent books from our state.
• Maps still says the resort is open until 11. We closed the kitchen at 9:30. The next reservation never leaves the driveway.
• A couple wants a quiet steakhouse under $200 with a booth. We return wait, available cuts, average spend, and whether people like them stay. Their agent answers in English. We are the feed underneath.
• Hotels already proved it: the listing that is current and trusted converts. We put that live representation on the café, the salon, the resort - every counter we instrument.
• A hundred people look at a room, one books. A thousand people see a dish, fifty-one pay. We see the rest of that funnel. That is the dataset we own.

Uncaptured demand - what the POS never sees

The POS reports units sold. The graph can estimate units wanted. If 10,000 people viewed or searched matcha and 2,000 bought, 8,000 units of latent demand were not fulfilled - stock-out, price, wait, hours, or location. That is a merchant product ("you captured $X of $Y of observed demand") and a market product (distributors, CPG, chains, and desks buy category-level unmet demand). Illustrative, not a live panel: a store that sold $24,000 of an item while leaking $4,700 of attempted demand has a different operating problem than a store that simply "sold $24,000."

Real-time commerce state, not a static directory

Today a Maps card says "open until 11 PM." That is a static field someone typed last year. At 9:30 on a Tuesday the kitchen has already closed, the wait is 45 minutes, and matcha is sold out. You still walk over. The listing did not lie about the legal hours. It just was not true for you, right now.

In two or three years the end user does not open Maps and read hours. They tell an agent: "Find me a quiet place in East Austin to work for three hours, under $20, with an outlet, and order my usual if they have it." The agent does not want a paragraph of vibe. It sends a structured query - location, party, budget, duration, dietary, noise, power, "usual" SKU, time. Something has to answer with structured state: open for food, wait 8 minutes, cold brew and croissant available, matcha sold out, workspace score 91 because people like this actually stay, fit 0.93. If that answer is stale, the agent books the wrong place or drops the merchant. If it is live, the agent only gets it from the network that writes the bill.

That is what "open until 11 PM" becomes. Not a directory field. A live parameter on a query: is the kitchen firing, is there a seat, is the SKU there, is this person likely to be happy. ZipF provides the infrastructure those agents call. ChatGPT-class assistants, travel agents, shopping agents, voice agents, and AI browsers become the clients. The merchant does not integrate fifty of them. They write one event stream. We normalize it. The agents query us.

The person never sees our API. They talk to their agent in plain language. The agent turns that sentence into a structured request. We answer with structured state. The agent then books, orders, or drops the merchant. The parameters are not generic "hours" and "rating." They are the fields that decide whether this person, this minute, should go.

Illustrative request/response contract. The agent application is the client. ZipF is the physical-world infrastructure. One merchant event stream, many agent apps on top.

Because ZipF writes the bill, live availability, crowding, and sell-outs can propagate to the QR, the ordering surface, and an agent API the same minute they happen. That is Commerce Content Sync: one canonical product, price, photo, modifier, and availability - pushed to POS, QR, web, delivery, loyalty, and agents - instead of five stale copies.

Agent-ready merchants - the physical world as a live API

An AI agent does not want "delicious food, beautiful ambience." It wants structured, current facts: cuisine, price band, capacity, outdoor seats, wait, vegetarian share, average spend, hours, sold-out SKUs, whether people actually stay two hours with a laptop. Incomplete representation means the agent simply drops the merchant. The new KPI is agent consideration → recommendation → book/buy, alongside human consider-to-buy. ZipF's graph is the ground truth those agents query.

We are building that layer now, while most physical businesses are still a website and a Google card. In the next couple of years the default interface for "where should I eat / sit / get a haircut / pick up a prescription" becomes an agent. Those applications will not each sign fifty POS contracts. They will call one context API. The query is personalized to the person - budget, diet, noise, history, "usual." The response is personalized to the minute - open for this intent, this SKU, this wait. Once that habit exists, the agent app is dependent on whoever holds live state plus outcome history. Scraping cannot replace it. A single-chain POS cannot replace it across a city. That is the lock-in: we started before the agents needed us; they arrive and the infra is already there.

Scale, in dollars, is the flow those agents sit on - not a restaurant SaaS TAM. Juniper: $8B of agentic-commerce GTV in 2026, $1.5T in 2030, $3.5T in 2031. McKinsey: $3-5T of global consumer commerce mediated by agents by 2030, of which $0.9-1T is US B2C goods. Gartner: $234B of enterprise application spend exposed to agents that bypass dashboards by 2030. We do not take those numbers as ZipF revenue. We take them as the volume of decisions that will need a live physical-world answer. If even a thin infrastructure take rides that flow - tokens on search and state, a fee when the agent acts - the US and worldwide agent layer is a second company sitting on the same graph as merchant software.

Illustrative Commerce Context API payload for a US location. Live fields come from the POS + QR + session graph, not from a scraped website. Tokenized the same way as L15: search, availability, representation, reasoning, then a transaction fee if the agent executes.

Pricing analogues are public category anchors, not ZipF list prices. Strategic / institutional seats remain in the $250K-$2M+/year band already used in §9.

Market Opportunity

ZipF monetizes across stacked dollar markets that must not be added together: (1) the worldwide foodservice economy it instruments - $3.3T globally, $1.55T in the US, (2) merchant software and POS - $130.6B worldwide, plus a $13.4B restaurant-POS-software slice, (3) alternative data and DaaS - $17.4B (2024) → $76.8B (2030), (4) $200B global retail media and $178B commerce media, (5) agentic commerce GTV of $8B (2026) → $1.5T (2030) as the flow agents transact against, and (6) every checkout counter on earth. India is a density beachhead inside that picture, not the ceiling.

5.1 · The base economy: worldwide foodservice and the US restaurant market

5.2 · US competitors and the platforms ZipF sits on

ZipF does not replace Toast or Square. It sits on them, then completes the graph they cannot see past their own network edge. The US competitive set is the proof that the category already has dollar-scale buyers - and the gap ZipF fills is cross-platform, item-level demand.

The arithmetic that makes the US a day-one theater: at Toast-proven ARPU, every 10,000 US locations represent ≈ $133M/year of revenue potential. The integration funnel acquires them through the Square App Marketplace, OAuth, and partner revenue-share. Dollar-denominated enterprise data contracts and US retail-media budgets monetize the identical Commerce Event Graph. Toast is the closest stack in the US and does not sell market-wide intelligence. Square owns payments and POS on its own network and cannot compute POS-agnostic neighborhood demand. Clover, Lightspeed, Aloha, and Simphony widen the same gap. ZipF's product is the join.

5.3 · Global POS infrastructure - every checkout counter on earth

People pay at counters everywhere. The same terminal + in-house software + event pipeline works at a diner in Austin, a café in London, a pharmacy in Dubai, or a restaurant in Bengaluru. Because ZipF generates the bill, capture is identical across cards, wallets, UPI, and cash. The 5M-device India plan is under 2% of the world's installed terminals.

Every checkout counter on earth is addressable.

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

5.4 · 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 dollar buyer class, at item-level fidelity, from merchant operating infrastructure rather than a reconstructed card panel.

5.5 · Advertising: $200B global retail media, the offline checkout still open

5.6 · India as density beachhead

India is not the TAM. It is the geography where hardware can be landed cheaply and ~82% of restaurants still run without digital POS. Quoted here in dollars, inside the worldwide markets above.

Razorpay device prices from POS machine charges. ZipF at ₹10,000 is a full commerce terminal (POS + billing + QR + loyalty), not a swipe machine. Figures at ₹96 = $1. Planning construct, not a forecast. If the merchant buys the device, hardware CAC falls to about $0 and every ₹1,000 month is contribution from day one.

5.7 · TAM stack summary

5.8 · Adjacent dollar markets: agents, data, APIs, restaurant POS

These layers are not added together. They are different pools of spend ZipF can participate in. Agentic-commerce GTV is the flow of commerce, the way card volume is the flow Visa sits on - not ZipF's TAM. Restaurant POS software is the infrastructure wedge. DaaS and API marketplaces are the intelligence and machine-to-machine pools. Commerce media is already in §5.5.

Gartner's $985B and Grand View's $24.5B measure different perimeters. Juniper and McKinsey measure transaction value, not vendor revenue. ZipF's story is: POS embeds us, the funnel graph becomes the intelligence product, agents make the interface itself valuable.

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 Seventeen-Layer Monetization Stack

The same underlying event graph is sold in seventeen distinct forms to seventeen 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-16 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, low-latency trading teams, and prediction venues.

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

Quote the company in dollars. The US and worldwide software bands below are the unit of account. India is a later beachhead on the same product, not the TAM.

9.1 · US / worldwide software ladder

Arithmetic on published US POS software prices, not ZipF list prices and not a forecast. $0 / $49 / $69-$149 are Square location software bands. $13,300 ARR/location and ~180K locations are Toast's disclosed FY/Q2 2026 figures (software plus fintech). A ZipF attach on those stacks is a slice of that ARPU; a ZipF-owned terminal can take more of it.

India beachhead, for completeness: 100K locations on the ₹1,000/month subscription is about $12.5M ARR. That is not the worldwide plan.

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 and L16. Prediction venues and the desks that quote those markets sit on this same ladder: named feeds, settlement licenses, exclusivity. YipitData at ~$280M ARR (2026) is the proof that normalized alternative data, sold as institutional intelligence, supports that scale of contract book.

9.5 · Agent infrastructure - the personalization layer only a live graph can sell

Static directories answer filters: open now, rating above 4.2, cuisine = Italian. An agent answering a person does not use filters. It needs a conditional: given this intent, this hour, this party, this budget, this dietary constraint, this history - which physical location should I recommend, and can I complete the action. That function is personalized at query time. If the ground truth is not live, the agent guesses. If it is live, it only goes through the network that has it.

Google can approximate intent. A POS vendor can report what sold at one chain. Only a cross-location commerce graph can join live state with observed outcome. That is why agentic commerce is not "another restaurant search API." It is a new distribution surface that pays for ground truth. Juniper's $8B → $1.5T → $3.5T GTV path is the flow. The infrastructure take is tokens and completed actions, the way Stripe sits under checkout without owning the merchandise.

These are stacked on the same event. They are not added as TAM. Agent GTV ($1.5T-3.5T), DaaS ($76.8B), API marketplaces ($25.2B → $82.1B), and commerce media ($200B+) are the pools. ZipF's take is the context layer those pools cannot compute without the bill.

Unit Economics

Read the unit in dollars first. A US location we attach through Square, Toast, or Clover has about $0 hardware CAC. Software sits in the $49-$149/month band already proven on those stacks. Toast's full software-and-fintech stack is $13,300 ARR per location. Payments, loyalty, and a thin data/ads allocation sit on top of that. US and worldwide payback is faster because ARPU is higher and the terminal is often already on the counter.

India is a later density beachhead on a cheaper terminal: ₹10,000 all-in CAC (~$104) and a ₹1,000/month contribution floor (~$10), recovered in 10 months. It is not the worldwide unit. The US owned-terminal path is optimized the same way - under Square's published hardware - so contribution and payback move together in each theater.

10.1 · Cost to acquire and deploy one merchant

10.1a · Three theaters - CAC, contribution, payback

Lower CAC only helps if the monthly contribution is the one that theater can actually collect. The table is the operating model: connect sits inside published Square/Toast bands; owned terminals are priced under published competitor hardware.

$49 / $149 are published Square location software bands. $299 is Square Terminal. ₹5,699 / ₹7,799 are Razorpay lifetime POS devices. ZipF rows are the operating model. If the merchant pays for the device, hardware CAC is about $0 in that theater and surplus starts in month 1.

10.2 · What one mature merchant generates per month

$49 / $149 are published Square location software bands. $1,108 is Toast's $13,300 ARR per location, monthly. An allocated ZipF attach sits inside those bands; a ZipF-owned terminal can take more of the Toast stack.

10.2a · Data participation as merchant product

Twenty to twenty-five percent of ZipF's data invoice - the same idea as Polymarket sending maker rebates for book depth - is applied as product the outlet already buys, in this order: ZipF OS at $0 ($49-$149/month, $588-$1,788/year), then the flagship terminal at $0 ($199 landed), then a payments take-rate cut (10 bps on Toast-average ~$1.08M GPV/location is $1,080/year), then inbound demand they keep (offers marketplace, agent index, brand campaigns; illustrative 20 extra covers/month at a $35 ticket is $8,400/year GTV). Chains take an L10 site-selection credit ($5K-$50K). Ticket-weighted: a busy counter unlocks more of the stack. At a $37.5M data book and 10,000 locations the pool is $8.44M/year, $844 per location - Plus-band software is covered; busy counters sit on Premium. At a $100M book the outlet is net paid in product. Same flywheel as the rest of this paper: data revenue subsidizes the merchant product.

GPV analogue: Toast $195B / ~180K locations ≈ $1.08M per location. 10 bps is a planning cut. Inbound 20 covers/month × $35 is an illustrative offers/agent funnel. GTV stays with the merchant. Write-offs are ZipF's cost, funded by the data pool. Operating model, inspectable arithmetic.

10.3 · Contribution is not a $49 SaaS number - it is a stack

$149 is the merchant software floor already proven by Square Premium. Payments, loyalty, data, media, and desk allocation sit on top. That is the number the cash-cow plan is built on. The graph opens additional high-margin lines that allocate back onto the same location. They do not replace the floor. They lift C, and N = burn ÷ C falls with it.

That is the out-of-the-box reading of unit economics. Hardware still acquires. The merchant stack still pays back the terminal. The future-ready lift is that each location is also a row in an agent index, a media graph, a desk feed, and a prediction-market series. HFTs already buy health-of-the-economy features at information-level latency. Agents will buy the same features as operable state. One capture layer, five payers.

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 $149/month mature contribution

At about 20,000 locations on the $149 band, the network starts funding itself.

11.2 · The self-funding threshold equation

11.3 · Interactive model explorer

US and worldwide unit of account. The three levers - contribution per merchant, all-in CAC, and monthly burn - recompute the economics in dollars.

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. The same logic runs geographically: the US from day one for ARPU (Toast's $13K+/location proves willingness to pay on a $1.55T restaurant economy), worldwide POS as the TAM (292M devices, $130.6B market), and India as the density beachhead. 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.