The creator pool
One membership funds the extensions people actually use. The split is published, the unit is defined, and the ledger is public — this page is the whole deal, stated once.
On this page (7 sections)
The deal
A user buys one intentic membership ($20/month). It unlocks every premium extension for them,
everywhere they work. 70% of membership revenue forms the creator pool, and each month the pool is divided among
premium extensions in proportion to how much members actually used them. The remaining 30% runs the platform.
There is no per-extension billing, no checkout between a user and each tool they try, and no cut taken from anything you sell outside the pool. A creator lists once and earns from use; a member pays once and stops thinking about it.
The unit: an active day
The pool pays on member active-days: one member's sandbox actually used your extension on one calendar day (UTC). Used means user-driven work — the extension's UI doing real work in front of its owner, or its backend answering its UI. Not installs, not opens of the store page, not background timers.
Why this unit, and not the obvious alternatives:
- Not installs — installs are a one-click number that can be farmed and forgotten. Retained use can't be faked without delivering something someone returns to.
- Not minutes or tokens — those pay slow, bloated tools more for being slow and bloated.
- Not ratings — a day someone came back is a rating that costs the rater nothing to be honest about.
A day bit is also deliberately the least a revenue share can run on, which is the privacy design: what leaves a member's sandbox is extension id + date, nothing else — no routes, no counts, no content. Free extensions and private installs report nothing at all, not even their names.
The anti-gaming rule, in writing
Engagement farming — nagging, self-firing activity, anything engineered to mint day bits rather than do work someone asked for — is delisting grounds. The registry's review can remove a listing from the pool, and the reason is stated on the row like every other trust decision. YouTube took a decade to write this down; we are writing it down on day one.
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 (1000 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. A service's provider earns a published share (70%) of the credit value members actually consume — and those earnings settle out of the pool first, because services carry real upstream costs; what remains is what active-days divide among premium extensions. The order is printed in the ledger itself, month by month.
The ledger is public
The platform serves GET /pool/transparency to anyone, no login: member count, gross revenue, the split, the pool, and
every premium extension's active-days, share, and slice — plus every service's runs, credits, and earnings — this month and the two
before it. The share percentages are exact, computed from the same ledger the payouts will settle on. Member counts for past months
are today's snapshot (the platform keeps no status history), and the page you are reading says so rather than dressing an estimate
up as an audit.
What exists today, honestly
- Working now: premium listings, the membership, the premium gate, use-day metering, credits and metered service runs (spend, refund, signed forwarding), the pool math, and the public ledger.
- Not yet: payout rails — the ledger accrues and is public from day one; moving money to creators (Stripe Connect or similar) is the next layer, and until it lands the numbers are the commitment, visibly accumulating. Also 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 (70%) 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 & marketplace — 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.