How it works
From the moment someone types a handle into the launch form to the moment the tagged person gets paid, here is everything that happens and where.
1. A handle becomes an address#
When you tag @octocat, Dibs looks up the account's permanent id (GitHub's numeric user id, X's numeric account id). Usernames can change and be re-registered; ids can't. The id is hashed with the provider name into a 32-byte handle key:
handleKey = keccak256(abi.encode("github", "583231"));The Dibs factory contract derives a vault address from that key with CREATE2. The address is fully determined before the vault is deployed, so the launch form can show it, and Pons can start paying it, while no contract exists there yet. The vault is deployed the first time someone claims, and its bytecode is fixed by the factory: the same key always yields the same vault with the same rules.
2. The launch is an ordinary Pons launch#
The coin is created by Pons's own launch factory, from your wallet, with one difference: the creatorFeeRecipient field is set to the tagged account's vault. Dibs is not in the transaction path and never holds the coin. If you add a dev buy, Pons's launch-and-buy contract performs launch and purchase in a single transaction and exempts you from the launch-window snipe tax.
The launch also writes a short credit into the coin's on-chain description (“Creator fees go to github.com/octocat via Dibs”), so the attribution travels with the coin to Pons and any other frontend.
3. Fees accrue in the vault#
Pons charges 1% on every trade on the bonding curve. 70% of that, plus 100% of any creator tax the launcher set, belongs to the creator fee recipient. Pons sweeps these into its fee escrow, credited to the vault address. Anyone can trigger a sweep; Pons automation does it routinely. If the coin is paired with a stock rather than ETH, the fees are in that stock.
| Where the money is | Who controls it | Visible on |
|---|---|---|
| Pons fee escrow, credited to the vault | Only the vault can pull its balance | Coin page, handle page |
| Vault contract (after a pull) | Only pays the bound wallet | Claim page |
| Bound wallet | The tagged account's owner | Their wallet |
4. The owner claims#
The claim is the only place identity meets money, so it has three checks, none of which cost the claimant anything:
- Who you are: sign in with X or GitHub. Dibs reads only the account id and username.
- Which wallet: connect any wallet and sign one message. That proves you control it; typos can't send funds to a stranger.
- The attestation: the Dibs server signs a short-lived EIP-712 statement that this handle key may be bound to this wallet. The factory verifies it on-chain, binds the wallet, and the vault pays out.
Dibs's relayer submits that transaction and is repaid its gas out of the payout, so the owner never needs ETH and Dibs never spends any. Once a wallet is bound, later claims need no signature at all, and every payout can only ever go to the bound wallet.
5. After graduation#
When the curve raises its graduation threshold (4.2 ETH for ETH pairs, a per-asset amount for stocks), Pons seeds a Uniswap V4 pool and locks the liquidity. Trading continues there, and Pons's hook keeps routing the creator's share of pool fees to the same recipient, so the vault keeps earning. See Fees & economics.
What lives on-chain#
- Every vault address, every binding, and every payout.
- The coin itself, its metadata, and its fee recipient.
- All fee accounting, in the Pons escrow.
- Verification of every attestation, with a per-handle nonce so none can be replayed.