The reseller path

We onboard one party.
They onboard ten thousand.

The scheme does not onboard the world, and it should not try. A partner enrolls once and hard, then mints identities inside its own namespace under caps its bond secures — and eats the risk of every one, which is precisely why it polices them. Card networks settled this shape fifty years ago; we inherit the playbook instead of paying to rediscover it.

Why the obvious version dies

The naive reading — everyone registers with us, every party a direct counterparty — is a flat registry. It fails three ways, and each one is fatal on its own.

Operationally

Human-reviewed attestations cannot onboard a partner's ten thousand merchants. The federation becomes a DMV, and the queue is the product.

Commercially

No serious commerce partner sends its ecosystem to register on someone else's forms under someone else's brand. They want their own protocol with settlement underneath.

Legally

“Any user joins the economy” read as any user holding positions is the sentence that ends the counsel meeting. Retail speculation on failure is not a product.

The four parties
The settlerplays the scheme

Owns the rules, the receipt, the splits and the settlement rails. It does not onboard the world.

Carries
The outcome taxonomy and neutral resolution — the things no partner can fork.
Earns
House points on settled value.
Operator platformsplays issuers

Onboard and vouch for the agents that do the work, inside their own namespace.

Carries
The agent-side bond, and roll-up liability for every identity they mint.
Earns
The operator point on their agents' settled jobs.
Commerce partnersplays acquirers

Onboard and vouch for the vendors and merchants whose surfaces the work happens on.

Carries
A master bond sized to their namespace caps.
Earns
A share of the vendor point, plus their own margin priced inside their slice.
Agents and usersplays cardholders

Buy assured outcomes, or check one. They never register with the scheme at all.

Carries
Nothing. No bond, no license, no positions.
Earns
The outcome they paid for, or their money back.
Three rings, three friction budgets

The budgets are deliberate in both directions. Every sector's smoothest path is the lowest ring that serves it. Sales effort concentrates entirely on ring 1, because each ring-1 win onboards its own ring 2 for free.

Ring 1
Licensees
Days

Commerce partners, operator platforms, rails, desks, evaluators.

To enter
k-of-n federation attestation, a registration fee, and a posted bond.
Why
These parties carry delegated authority to mint identities. They must be expensive to be, or the delegation means nothing.
Ring 2
Delegated
Minutes

Merchants, vendors, individual agents — admitted through a partner.

To enter
One API call inside a partner's namespace, capped by that partner's bond.
Why
No human in our loop. The partner already vouched, and already eats the risk.
Ring 3
Users
Seconds

Anyone buying an assured outcome, or checking one.

To enter
Nothing at all.
Why
First value is one payment or one free verification. Consumption only — a user never holds a position, in any phase.
The access matrix

The last column is the load-bearing one. A permission model is only as good as what it forbids, and these prohibitions are what keep retail out of positions and keep the verification surface neutral.

ActorSettler SDKReseller SDKNever
Partner backend
ring 1
Full partner surface under its own namespace keysOwns itMinting outside caps; underwriting past the master bond
Cohort partner
ring 2
Nothing directly — its identity lives inside the namespaceregister, postJob, submitWork, receiptsDirect positions; namespace keys
Staker
ring 2
Nothingstake, back, claim, dashboardAny settler API call; any direct position
Any user
ring 3
receipt.verify and payment — free, keylessThe partner's own storefrontRegistration anywhere
Auditor, or anyone
no ring
receipt.verify and the explorerThe partner's public pagesNeeding anyone's permission

One call a reseller may never wrap: receipt.verify. A partner may white-label the entire storefront, but the “view proof” moment always resolves on a neutral surface — because a verification layer that can be fully white-labeled can be fully impersonated, and then it verifies nothing.

Two verbs, and the business model between them
READBuilding
How you arrive

The root and the proofs: free, keyless, forever. The decoded tape as a filtered stream. A partner can replace its own decode stack with this and build nothing.

WRITEProposed
How you belong

Licensed, namespaced, bonded. Chain headers, protocol events, envelopes, job declarations. A write is not an upload — it is membership in the record.

Read is the commons. Write is the economy.
The split, and what keeps it honest

Every number here is a parameter still to be confirmed. What is not negotiable is the shape.

1 point
The worker's operator

On its own settled jobs. Verified history becomes an asset that is portable nowhere else.

1 point
Vendors of record

Pro-rated by envelope count. Computed from evidence, never self-declared.

3 points
House

Cost recovery and the rails. Never drops below the cost line.

Shares pay out of fee flows, never out of escrow principal.
Splits nest: a partner's cut of its merchants comes out of its own slice, never from newly minted points. The total never grows.
The receipt is the royalty statement — vendors_of_record is computed from the evidence envelopes, so there is no self-reporting and no reconciliation meeting.
Shares vest only on settled receipts. Enrolling ten thousand shell vendors that no job traverses earns exactly zero.
Why integration compounds
1More writersEach new write partner enriches the record.
2A richer recordAttracts readers, at zero marginal integration cost to anyone already there.
3Readers convertTheir own users want their events visible and settleable. Read is deliberately generous so the upgrade is the natural next step.
4Volume feeds sharesWhich keeps writers writing. The value of being integrated rises with every integration.

The loop is structural rather than marketed: the API is two-sided on the same object, so what one partner writes is literally what another reads. Nobody has to build anything for anyone else.