The deal
A user buys one intentic membership ($20/month). It includes every premium extension wherever they work and a daily allowance of credits, the pool's only currency. Every credit a member spends pays 90% of its dollar value to the creator it went to; the rest runs the platform. Two ways credits move:
- Install donations: installing a premium extension donates a published number of credits to its publisher, once, automatically. Updating it donates again, at most once a month. That is the whole way non-service extensions earn.
- Service runs: metered per-run spends on priced services (the section below).
There is no per-extension checkout, no subscription-per-tool, and no cut taken from anything you sell outside the pool. A creator lists once and earns from installs; a member pays once and supports what they choose by choosing it.
No telemetry, by construction
Sandboxes are self-hosted: yours, like your editor. So the pool pays on nothing a sandbox could report: no usage pings, no active-day bits, no counts, ever. The only economic signal that exists is what passes through the platform's own hands: a member's deliberate install donation, a member's service run. Your machine tells nobody what you run on it.
Why donations at install, and not the obvious alternatives:
- Not usage metering: a self-hosted client can invent any usage it likes, and honest ones shouldn't phone home at all.
- Not minutes or tokens: those pay slow, bloated tools more for being slow and bloated.
- Not a per-tool checkout: friction at every install kills the browsing that makes a catalog worth listing in.
Why farming loses money, arithmetically
A member's credits are bounded by their own membership: a month's allowance is worth exactly what they paid. So a publisher "farming" donations to their own listing with bought memberships can only redirect a 90% share of money they themselves paid in: every farmed dollar costs more than it returns, at any scale. The monthly donation dedupe also stops update spam: an install can donate at most twelve times a year however often its publisher ships. What remains for policy is only nudging real users into meaningless updates, which is delisting grounds, stated on the row like every other trust decision.
Services & credits: runs with real costs
Some tools aren't a prompt and glue: they call paid data APIs or burn real compute per run. Those are services, and they run on credits: a membership includes a daily allowance (1,000 credits, resetting at UTC midnight, same honest reset as the free trial), and a service publishes its credit price. The rules a member can hold us to:
- The price is visible before the run. Any surface can ask what a run costs and what's left today; a refusal for lack of credits answers with the remaining count and when it resets.
- No charge on failure. Credits are spent atomically before the call and refunded automatically when the provider errors or never answers. A provider's "your query was malformed" is an answer: that one is paid for and relayed verbatim.
- The platform is the intermediary. The provider never learns who the user is; the user never holds a provider account or key. Every forwarded call is signed so a provider can verify it came from intentic and drop everything else.
A credit's dollar value is derived, not invented: the membership price divided by a month's allowance. Donations and runs both spend from the same daily allowance, so a member's total support is bounded by exactly what they paid, which is what makes the whole economy sybil-proof. Credits nobody spends pay nobody: the pool figure is a ceiling payouts approach, and the ledger prints both numbers so neither can pose as the other.
Who let it in, and your worst case. The catalog is curated: in v1 every service is admitted, and when it goes bad delisted, by the platform; there is no self-serve path onto it. Nothing of a provider's ever runs on your machine, so a run's whole blast radius is its listed price and the JSON answer your agent reads back. The mechanical case never needs a dispute (no answer, no charge, enforced in code); a served answer is paid even when it disappoints, and chronic disappointment is what delisting is for rather than a per-run argument.
Running something that costs real money per call? Offer a service explains the provider's endpoint, signature checks, payments, refunds and admission.
The books are open
The platform serves GET /pool/transparency to anyone, no login, and the ledger renders it for people. It publishes two kinds of month and never lets them be confused. The month in progress is computed live and its revenue is an estimate — members × price — because nobody can know what a month took until it is over. A finished month is the frozen record: what actually settled at Stripe, the fees Stripe took on it, the pool, what creators earned, and what became of every cent of it — paid, in flight, carried, unclaimed, or expired back into the pool.
Publishing only the total earned would let "90% to creators" hide any amount of money that never actually reached anybody, which is why the outcomes are broken out and why they add up to the distributed total. It also means the margin is visible: revenue minus fees minus the pool is what the platform keeps, and you can do that subtraction yourself. Member counts on an open month are today's snapshot (the platform keeps no membership history); a closed month's is the count recorded when it closed.
Getting paid
Earnings accrue against the publisher name in your manifest, which is a label until somebody proves it is theirs. You claim it by committing a token the platform gives you to any repository the registry already lists under that name — push access is the proof, and it is the same thing the registry vouched for when it accepted your listing. Then you connect a payout account through Stripe's own hosted setup; bank details, identity documents and tax forms are collected by Stripe, and this platform never sees or stores them.
A month closes as soon as it is over and becomes payable mid-month. The gap is a deliberate hold window for refunds and card disputes, not an unexplained delay, and the date is stated rather than implied. You are paid once per cycle for everything you are owed across every name you hold; a balance under the published minimum carries to the next run rather than becoming a transfer whose fee eats it. A payment that fails is never abandoned and never sent twice — it is retried until it lands.
Claim late and you still get paid: statements are never bound to an account, so proving a name in October settles what it earned in July. Earnings owed to a name nobody proves stay claimable for twelve months, then return to the pool and are split among creators who are still shipping. That is the one case where money you earned can stop being yours, so it is stated here, shown on the ledger, and given a deadline you can see.
What exists today, honestly
- Working now: premium listings, the membership, install donations with the monthly dedupe, credits and metered service runs (spend, refund, signed forwarding), the demo service, the pool math, publisher claims, connected payout accounts, the monthly close against settled revenue, automatic payouts, and the public ledger.
- Not yet: credit top-ups and rollover (the daily allowance is the whole meter), streaming runs (a run is JSON in, JSON out, up to a minute), and self-serve provider onboarding (the first services are onboarded by hand).
The split (90%) is configuration the platform publishes on the ledger itself, so this page and the endpoint cannot quietly disagree. If the number ever changes, it changes loudly, prospectively, and on that page first.
Opting in
One field on your registry entry. Everything else on Publish & registries: the sha-pinned pointer, the manifest gate, the trust states: applies to premium listings unchanged.
{
"name": "acme.reddit-research",
"kind": "extension",
"tier": "premium",
"description": "Deep subreddit research: audiences, timing, and what actually gets traction.",
"version": "1.2.0",
"source": { "source": "github", "repo": "acme/reddit-research", "sha": "9f2c1ab…" }
}Premium is honored on the official registry, because that is the registry the platform's pool reads. A private registry can mark rows premium for its own purposes, but the public pool neither sees nor pays them.