A fee arrives. The program splits it four ways: a quarter to buying and burning $CHARLIE, and the rest to the three legs the coin's own dev chose. No key the dev or Charlie holds can redirect any of it. Below is that happening on a chain, with signatures.
GFA3nG9geMhpPXaExVLGYBtj6aJX7S125dLzv4EcXGiG GFA3nG...XGiG, on devnetcharlie_pool: 2500 bps of the creator fee (25%), asserted against the program's own compiled constant on every distributeroute(mint): SOL burn 500, own burn 2000, ops 5000 — summing to 7500, which is what the toll leaves| leg | share of the fee | lamports | destination |
|---|---|---|---|
| $CHARLIE buy & burn The protocol's share. A PDA of the program; no key exists for it, and no instruction moves lamports out of it except the crank that buys $CHARLIE and burns it. | 25.00% | 200,000 | charlie_poolCJEC7B...V5qL |
| SOL burn Solana's incinerator. The runtime removes these lamports from the total supply at the end of the block -- not merely unspendable, destroyed. That is why its balance below is zero. | 5.00% | 40,000 | incinerator |
| the coin's own buy & burn The dev's own buy-and-burn leg, a PDA of the program derived from their mint. | 20.00% | 160,000 | burn_poolHkwxMn...Y1Kg |
| ops An ordinary wallet the dev names. Spendable, and the page says so: what it is spent on is not something a chain shows. | 50.00% | 400,000 | route.ops_address |
| the fee that arrived | 100% | 800,000 | collector(mint)HHeLyM...TA3s |
| left in the collector the integer-division remainder. It is not swept to a leg -- which leg got it would depend on the order of the code -- so it waits and is counted in the next distribution. | 0.00% | 0 |
The toll came to 25.00% of the fee, which is what TOLL_BPS = 2500 means. It is a constant in the program's code and is not a field of any account a dev can write — the three shares they do choose are required to sum to exactly what the toll leaves.
| # | fee in | toll | SOL burn | own burn | ops | distribute |
|---|---|---|---|---|---|---|
| 1 | 400,000 | 100,000 | 20,000 | 80,000 | 200,000 | 5E3MWmzc...XZar3F |
| 2 | 400,000 | 100,000 | 20,000 | 80,000 | 200,000 | 5PBfm9n2...Dh2Ljw |
The figures in that table are the program's own, emitted by distribute and read back out of each transaction's logs. The balances of the two pools were also read directly and agree with them; the SOL burn leg has no balance to read, because the runtime destroys it.
distribute takes no signer. The round below was called by a wallet that is neither the coin's admin nor its ops address — it has no claim on any leg — and the toll moved anyway:
67oped...KBt8, admin: no, ops: nocharlie_pool gained exactly that (100,000)That last line is deliberate, not an oversight. A fixed tip for calling the crank would be an extractable bounty: whoever called it would be paid out of the toll and both burn legs, so the legs would fund their own collection. The crank's incentive is the ops share and the protocol's own operation.
The guarantee is an absence, and an absence is only worth stating if you try the thing and print the refusal. Each of these was submitted to the deployed program:
distribute: ops account is not the one route namesdistribute: the SOL burn leg pays the incinerator, and nothing elseroute: the three dev shares must sum to 10000 - TOLL_BPSroute updatedIt is not mainnet, it is not enrollment, and it is not a claim that any coin earns anything. The creator fee arriving was a transfer, not pump. The program is upgradeable, which means the absences above are today's absences and not yet permanent — revoking upgrade authority is the one-way door that makes them guarantees, and it comes after the pipeline has run in production, not before.