How it works
Due is one idea: the field in pons that decides where creator fees go does not have to point at the launcher. It can point at a contract only the creator can empty.
Who the fees can go to
Every token launched through Due is attached to one social media username. That username is turned into a string, the string is hashed, and the hash becomes the address of a vault. The fees go there. Nowhere else.
Nothing in that chain involves us. The same username always produces the same address, on any machine, whether or not a token exists and whether or not Due is still around. One creator has one vault, however many tokens are named after them.
The platforms
| Platform | String that is hashed | Vault | Can be claimed today |
|---|---|---|---|
| X | x:username | open | yes |
| TikTok | tiktok:username | open | yes |
| instagram:username | open | not yet | |
| reddit:username | open | not yet | |
| linkedin:username | soon | soon |
Instagram and Reddit vaults work exactly like the others and collect fees from the first trade onward. What is missing is the ownership check: we have not written the code that reads those profiles, so we cannot sign a statement for them yet. The money accumulates and waits. It does not go anywhere else in the meantime.
LinkedIn is a step behind that. The four names above are compiled into the launcher, so a launch for a LinkedIn handle is refused outright rather than parked. Reading the profile turns out to be the easy half: a code in the headline is visible without logging in, the same way it is on X. What it needs is a new launcher, which changes no vault address and nothing already claimed. It is a deploy, not a redesign.
What counts as the same username
Capitals and a leading at sign are ignored, so @Bassem69 and bassem69 are one vault and not two. Letters, digits, dots, underscores and hyphens are allowed. Anything else is rejected rather than quietly stripped, because silently dropping a character is how one creator ends up with two vaults holding two piles of their own money.
Every address a fee can reach
| Destination | Who decides | When |
|---|---|---|
| The vault of the attached username | Nobody. The contract writes this field itself. | Always, from the first trade |
| Our rev share sink, 10% of the fee | Nobody. The rate is fixed in the vault bytecode. | The moment a fee is pulled in, before the rest is credited |
| Any wallet the creator names | The creator, after binding their account | Whenever they call withdraw |
| Any address, skipping the vault entirely | The creator, using redirect | For fees earned after that call |
| A new wallet, after losing the old one | Us, proposing publicly, with the creator able to veto | 72 hours after the proposal at the earliest |
That is the complete list. Our 10% is on it, in the open, and it is the only claim we have. What it is not is a lever: there is no path that reaches a balance already sitting in a vault, none that pays the person who launched the token, and none that sweeps anything to a treasury after an expiry date. Those functions were never written, which is a stronger statement than promising not to call them.
Where our share goes
10% of each fee, taken the moment it is pulled out of pons and before the remaining 90% is credited to the creator. It goes back into the token as rev share rather than to a wallet that sits on it.
Three things bound it, and all three are in the bytecode rather than in this paragraph. The rate is immutable, set when the vault logic is built. It is capped at 20%, so even a future deployment cannot go past that. And it applies only to money arriving: once a fee has landed in a vault it is the creator's, and no function here can reach it. If our own sink is ever broken or refuses payment, the pull still succeeds and the creator keeps the whole fee, because that is the only direction the failure is allowed to fall.
Changing the rate later would mean deploying a new vault implementation, which moves every vault address and is therefore impossible to do quietly. That is deliberate: the thing that makes the address predictable is the same thing that makes the rate stuck.
The vault belongs to the string, not to the human. If a creator changes their username, or somebody else takes over an abandoned one, the vault for that name follows the name. That is the price of an address anyone can compute without asking us, and we would rather state it than hide it.
The route one fee takes
- 01Somebody tradespons withholds 1% on the trade. The protocol takes its share and the rest belongs to the creator.
- 02The fee sits on the curveNot paid out yet. A sweep moves it to the escrow. Our interface counts this separately, because otherwise a vault looks empty when it is not.
- 03The escrow credits the vaultIn the name of the vault address, not in ours. Anyone may call the claim, because the escrow always pays the caller and the caller is the contract itself.
- 04The vault waitsIndefinitely. No expiry, no sweep to a treasury, no clause about forfeiting after twelve months.
- 05The creator withdrawsAfter their wallet has been bound to the username. That is the only key on the lock.
What we can and cannot do
There is one thing a contract cannot work out for itself: whether a wallet really belongs to a TikTok account. That judgement is ours, so here is exactly how far it reaches.
| What we can do | What we cannot do |
|---|---|
| Bind a username nobody has claimed yet to a wallet | Take money out of a vault. No function, no key, no upgrade. |
| Propose a rebind, in public, with 72 hours of waiting | Execute that rebind inside those 72 hours |
| Change our launch fee, up to a ceiling fixed in the bytecode | Change the 10% rev share, or apply it to a balance that has already landed |
| Take the website offline | Stop a creator withdrawing anyway, through a block explorer |
And the creator can cut us out entirely. transferHandle moves their username to a new wallet without any signature from us, and redirect points future fees straight at their own address.
Verification, step by step
You look up your username
We compute the vault address from the name itself. That works even if nothing has ever been launched for you.
You put a code on your profile
No wallet needed yet. Somebody copying the code out of your bio can do nothing with it: their own attempt produces a different code, and that one is not on your page.
We look, and we sign
We fetch your public profile and search for the code. No login, no OAuth, no access to your account. Then we sign a statement that is valid for fifteen minutes.
You name a wallet and submit
The first and only step that needs one, so you find out what is waiting before you go and install anything. Your wallet, your transaction, your gas. We cannot bind on your behalf, which is exactly the difference between a signature and a key.
What it costs
If our launch fee bothers you: launch directly on pons and set creatorFeeRecipient to the vault address yourself. It is printed on every creator page. That saves you the launch fee. The rev share still applies, because it lives in the vault rather than in the launch, and a creator who wants none of it can point their fees somewhere else entirely with redirect once they have claimed.
What can go wrong
All of it, including the parts that make us look bad.
We can bind the wrong person
For a username nobody holds yet, binding happens immediately and without a waiting period. That is the sharpest edge in the design. A delay on a first binding only punishes the real creator, because at that point there is no counterparty. The correction comes after: a wrong binding sits publicly in an event, and the owner can move their handle themselves.
Fees nobody collects stay put
Forever. That is a choice, and it has a cost: money nobody claims does nobody any good. We think an expiry date is worse.
A vault with a balance advertises a token
Saying the creator has 0.4 ETH waiting sells somebody else's token, and we put it at the top of the page. That helps tokens the creator may never have wanted.
The creator may want none of this
Due cannot delete a token, because nobody can. What is possible: an owner marks their handle as disowned and that then sits at the top of their page. It changes nothing about the token, only about what we say regarding it.
The profile check is fragile
Reading public profile pages is not a stable API. When the check breaks we show it as we could not look, never as you are not the owner.
The contracts are unaudited
They are tested and the design is deliberately small, but no outside party has reviewed them. Treat them accordingly.
Where it runs
Robinhood Chain, chainId 4663. Due builds on pons v2 and touches nothing else.