Fees and payouts
Fees and payouts
1. In brief
- 2% on every curve trade, 1% on every graduated-pool swap. Section 2.
- The ETH fee splits 30% creator / 40% promoters / 30% protocol. Section 3.
- A creator gets one 6-hour window a day to hand the promoters’ share to named KOLs, in whole percentages. Sections 4 and 5.
- A creator may allocate all of that window, none of it, or anything between. The limits are per KOL, not on the total. Section 5.
- Whatever is not allocated splits 50/50 between the creator and the platform when the window closes. Section 5.
- Each KOL’s rank caps what they may take from one window, from 10% at Unranked to 30% at Diamond. Section 6.
- Check eligibility before you sign. One ineligible line reverts the whole allocation. Section 8.
2. What a trade costs
| Venue | What is charged | Fee |
|---|---|---|
| Bonding curve | Every buy and every sell | 2% |
| Graduated Uniswap V4 pool | Every swap | 1% |
A round trip on the curve — one buy and one sell — therefore costs about 4% before the price moves at all. Gas is additional. Neither fee is refundable.
A graduated pool pays its fee in both currencies. The ETH leg splits as section 3 describes. The token leg is burned in full: there is no share to compute and no remainder to assign, and the contract re-reads total supply afterwards to confirm it fell by exactly the amount burned.
3. How the fee splits
| Share | Where it goes | Of the fee |
|---|---|---|
| Creator | Paid to the launch’s creator fee recipient. | 30% |
| Promoters (KOL) | Held by KolSplitter for the creator’s window. | 40% |
| Protocol | The remainder, after the two shares above. | 30% |
The same three shares apply to the curve fee and to the ETH leg of a graduated pool’s swap fee.
The protocol’s share is taken by subtraction, not by a third multiplication: the creator’s share and the promoters’ share are each computed and everything they leave is the protocol’s. Integer division truncates, and doing it this way assigns that truncation exactly once instead of leaving a wei nobody can claim.
These shares are fixed per launch at the moment it is created, and cannot be changed afterwards — not by the creator, not by us.
A launch’s own configuration is readable on chain and is the authority for that launch. The figures above describe launches created under the current fee model. A launch created before it carries the shares that were in force when it was created, and keeps them for the life of the token. Read the launch, not this page, if the two could differ.
4. The KOL allocation window
The promoters’ 40% does not sit with the creator. It accumulates in a contract called KolSplitter, and it becomes spendable only inside a window.
| Rule | Value |
|---|---|
| How often a window can open | Once every 24 hours |
| When the daily slot falls | On a fixed grid anchored at the launch instant |
| How long it stays open | 6 hours |
| What it holds | All promoter fees that arrived since the last window |
Because the grid is anchored at the launch instant, a creator picks their daily allocation time by picking when they launch. A keeper that opens a window late misses that slot; it never moves the others.
The keeper can only open a window and close an expired one. It supplies no amounts, no recipients and no rates — every figure is read from the contract’s own state and divided there. Closing is permissionless once the six hours are over, so anybody can settle a window and nobody can hold a creator’s money hostage by declining to.
5. How a creator allocates
Inside the window, the creator names KOLs and the share each is to receive. They pay their own gas. The rules:
| Rule | Value |
|---|---|
| Unit | Whole percentages of the window |
| Smallest allocation to one KOL | 1% |
| Largest allocation to one KOL | That KOL’s rank cap — section 6 |
| Largest total, across every KOL and every call | The window itself (100%) |
| Smallest total | None — a creator may allocate nothing |
Fractions cannot be expressed. An allocation of “1.9%” is not rejected — there is no way to write it down. The share is a whole number of percent, so nothing rounds and the contract does the multiplication against a window figure the creator does not have to compute.
Nothing caps the total. A creator may hand out the whole window, none of it, or anything between. The two limits are per KOL — the 1% floor, and that KOL’s rank cap — and the only ceiling on the total is the window itself, counted cumulatively across every call the creator makes inside it.
Allocating less is how a creator keeps more. Whatever is left when the window closes lapses, and splits 50/50 between the creator and the platform. An odd wei goes to the creator: the halves are taken by subtraction rather than by two divisions, so no wei is paid twice and none is stranded.
That remainder is a consequence of the creator’s own choice and not a floor anyone is promised. A creator who allocates the whole window leaves nothing to split, and a KOL should not read the 50/50 as money held back for them.
6. Rank caps
A KOL’s rank limits how much of one window they may be allocated. Rank is earned by lifetime fees paid to that KOL while working for other projects — not for their own — or granted by a vote of their peers, whichever is higher.
The lifetime figure is summed from the splitter’s own allocation events, so it is a measurement rather than a claim: anybody can recompute it from public logs without asking us, and section 12 says how. It only ever rises — the registry refuses a lower total than the one it already holds — so a rank cannot be reduced by us being behind, only reached later.
| Rank | Lifetime fees earned for other projects | Cap per window |
|---|---|---|
| Unranked | 0 | 10% |
| Bronze | 0.10 ETH | 12% |
| Silver | 0.25 ETH | 15% |
| Gold | 5 ETH | 20% |
| Platinum | 30 ETH | 25% |
| Diamond | 100 ETH | 30% |
The cap is a ceiling on one KOL in one window, not a budget: a creator may allocate anything from 1% up to it. An ineligible KOL reads a cap of zero, which is the same answer as “may not be allocated to”.
These thresholds and caps are settable by the platform owner. The values above are what the registry is deployed with. The contract is the authority at any moment — see section 12 for how to read the live table.
7. Who can be paid
A KOL must satisfy both of the following to be allocated to. Neither implies the other, and the same bar governs whether they may vote in a peer promotion.
- Eligible — enrolled on the platform with an X handle connected, and that handle carrying a live X Premium badge as of the last check. Premium and Verified Organizations both count; a legacy verification does not, because it is not a subscription and says nothing about whether an account is current. Platinum and Diamond are excused the subscription: a KOL who has earned that much for other projects has demonstrated the thing the subscription stands in for. The excused rank is settable and is Platinum as deployed.
- In good standing — attested recently enough to count as active. An attestation keeps an account active for a set window, 30 days as deployed, and the window is settable. An account nobody has attested inside it stops being payable until it is attested again.
- Not barred — the platform owner can withdraw an account’s KOL standing, and a barred account reads a cap of zero whatever its rank or badge. This is disclosed here rather than left to be discovered: it is the one input to your cap that is a decision rather than a measurement. What it does and does not affect, how it is recorded, and how it is reversed are in the terms of use.
An X subscription can be revoked at any time by X, which is why eligibility describes this instant rather than the day someone signed up. A badge is re-read daily and carried on chain within two hours of changing, so a lapse takes effect in about a day rather than immediately.
8. Checking before you sign
KolSplitter.previewAllocation answers, for each line of a proposed allocation, exactly what the real transaction would do with it: a status saying whether it would be accepted and why not, the wei it would become, and that KOL’s cap. It is a free read. It exists so a creator never learns that a KOL is ineligible from a failed transaction.
It reports every line rather than stopping at the first problem, so one read gives the whole list of what needs fixing. Two things about it matter more than anything else on this page.
One bad line reverts the whole allocation. The preview is a diagnostic list, not a proposed subset — the good lines do not go through on their own. Fix or remove every line that is not OK, then submit.
It is a snapshot. A KOL whose subscription lapses between the preview and the transaction is refused by the allocation regardless of what the preview said. The chain at the moment of the transaction is the authority, not the answer you read a minute earlier.
The lines are evaluated in order against a running total, and a refused line consumes none of it: the lines after it are judged against what would actually remain, not against a share a refused line never spent. A line can still be refused because the accepted lines above it used up the window.
9. How a KOL is paid
An allocation credits a balance; it does not send anything. A KOL withdraws it themselves, whenever they like, with claim() to their own address or claimTo(address) to another. There is no deadline and nothing expires.
Payment is pull rather than push on purpose: a KOL whose registered address cannot receive ETH fails only their own transaction, and can still recover the balance to an address that can.
10. The creator’s crew
Not available yet. The crew contract is written but is not wired into the launch flow, so no launch can name a crew today. The rules below are what it will enforce when it ships, not something a creator can use now.
A crew is a project’s founding group — the people tied to its founding — and it is a different relationship from a KOL, who is a promoter paid at the creator’s discretion out of the window described above. A crew is paid out of the creator’s own share, in every currency the launchpad pays, and it is not rank-gated in any way.
| Rule | Value |
|---|---|
| Largest crew, including the creator | 5 |
| Other wallets on the roster | 4 |
| Most that can be allocated away from the creator | 60% |
| Smallest share one crew member may hold | 10% |
The creator is the residual claimant rather than a name on the roster, so they always keep at least 40% of their own share.
The 60% is a ceiling, not a target, and there is no minimum total. A creator may name no crew at all and keep 100%, or give one member the 10% minimum and keep 90%.
A crew is fixed when the launch is created and can never be changed. Not by the creator, not by a member, not by the platform. There is no way to add someone, remove someone, raise or lower a share, or resign — those functions do not exist in the contract.
The reasoning is that a founding team is a fact rather than an arrangement. Someone who helped start a project remains one of the people who started it, whatever happens afterwards, so a disagreement is not grounds for editing history. If a creator wants to pay somebody temporarily — for a promotion, a campaign, a piece of work — that person should not be put on the crew at all. Pay them from your own wallet instead.
Get the addresses right before you launch. There is no second chance. A crew is set when the token is created, and a launch’s fee recipient is itself permanent, so a mistake cannot be corrected by deploying a new splitter — only by launching a new token.
- A mistyped address keeps its share for the life of the token, and everything credited to it is unreachable.
- A member cannot decline. Their share keeps arriving even if they want no further part in the project.
- A lost or stolen member key cannot be replaced or cut off. Whoever holds it collects that share permanently.
- Somebody who joins after the launch cannot be added, and can only be paid from the creator’s own wallet.
11. The protocol’s share, and THD
The protocol’s share passes the referral ledger first, so a referrer earns on it, and then reaches ProtocolFeeSplitter. That contract does two things: it routes each receipt, and it keeps the single running total the THD unlock is measured against.
The meter counts only registered payers. ETH arriving from anywhere else is not refused — refusing it would strand it — but it goes entirely to the treasury and never touches the counter. Nobody can accelerate a THD unlock by donating to it. The total is monotonic and has no setter, so nothing, including the owner, can lower it.
Of a counted receipt, half is routed to the liquidity contract that funds the THD pool, and half funds operations. The routing stops on its own once the liquidity contract’s target is reached, after which every later receipt goes wholly to the treasury.
Today the liquidity contract is not yet set, and while that is true every counted receipt goes wholly to the treasury. The 50% routing begins the moment that contract is wired in, with no redeploy.
Nothing is ever pushed at the THD contracts. The emission contract reads the fee total live and stores no figure of its own — there is no keeper reporting it and no trigger to press.
12. Verifying any of this yourself
Every figure on this page is a value in a deployed contract, and none of it has to be taken on trust. The contract addresses are published on this site, and the reads below answer the questions this document answers.
The calls
| Question | Call |
|---|---|
| This launch’s fee and its three shares | BondingCurve.config() |
| What an allocation would do, line by line | KolSplitter.previewAllocation(source, kols, percents) |
| The window rules | KolSplitter.WINDOW, MIN_WINDOW_INTERVAL |
| The smallest allocation to one KOL | KolSplitter.MIN_ALLOCATION_PCT |
| An address’s rank | KolRegistry.rankOf(address) |
| An address’s cap right now | KolRegistry.allocationCapBpsOf(address) |
| Whether an address may be paid | KolRegistry.isEligible(address), isInGoodStanding(address) |
| The live rank ladder | KolRegistry.allocationCapBps(rank), feeThresholdWei(rank) |
| Counted protocol fees to date | ProtocolFeeSplitter.totalProtocolFeesReceived() |
Where this page and the chain disagree, the chain is correct and this page is a bug — report it, and see the terms of use for what this document does and does not promise. The risk notice covers what these fees mean for anyone buying a token rather than launching one.
The Hood’s contracts are immutable, audited by Claude Fable 5. Nothing on this site is financial, investment, legal or tax advice.