The Bordrless standard

What a Token-2022 transfer hook is#

Checked against Token-2022 v11.0.0 (the build on mainnet) and Solana’s own documentation. These are the only statements this site makes about transfer hooks; the numbers point to the sources at the end of this section.

What a Bordrless hook is#

It keeps the safety rule that matters: it never gets the user’s signature. What it wants done to an operation, it answers, and the token program or the DEX applies the answer. Uniswap v4’s hook idea, on Solana, at the token level.

Sources#

A mint is an account of the token program (bordrless_token): decimals, supply, an optional maximum supply, four revocable authorities (mint, freeze, hook, metadata), the hook program and its flags, and the name, symbol and URI on chain. A holding is one owner’s token account for one mint, always the PDA of the pair, which anyone can create for anyone. Every holding keeps 64 bytes for the mint’s hook (section IV).

holding = PDA(["holding", mint, owner], token_program)
signer  = PDA(["hook-authority", hook_program], token_program)   // signs every call to that hook

create_mint    create_holding   transfer        mint_to          burn
approve        revoke           set_frozen      close_holding    write_hook_data
set_authority  set_hook         update_metadata

transfer(amount): authority (owner or delegate), source, destination, mint,
                  hook_program?, hook_signer?, then the hook's extra accounts

Transfers, mints and burns call the mint’s hook before and after the operation, for the callbacks its flags subscribe to (section III). Events are emitted by self-CPI and carry post-balances, so an indexer keeps exact holder balances without reading accounts. Hook data is not in events: an indexer that mirrors it reads the holding.

The calling program invokes a callback by CPI with an Anchor-style discriminator and Borsh arguments, signing with its ["hook-authority", hook_program] PDA, which is always the first account. The signer is one per hook program: a callback receives it as a signer and could pass it on in a CPI of its own, so a hook accepts only the signer made for it, and a signer another hook passes on vouches for nothing.

Callbacks#

For a mint or a burn, the mint stands in for the side the operation lacks. Pool callbacks also carry the caller’s opaque hook data (Uniswap v4’s hookData), up to 256 bytes.

Flags#

A mint subscribes its hook with Mint.hook_flags, a pool with Pool.hook_flags. A callback whose flag is off is never called, and an answer is read only when a flag allows one for that callback.

Arguments#

Before or after the operation, a callback is told everything the calling program knows about it. Balances and hook data are those before the operation in the before phase and after it in the after phase.

pub struct TokenHookArgs {
    pub op: TokenOp,                     // Transfer, Mint or Burn
    pub phase: Phase,                    // Before or After
    pub mint: Pubkey,
    pub source: Pubkey,                  // the mint, for a mint
    pub destination: Pubkey,             // the mint, for a burn
    pub source_owner: Pubkey,
    pub destination_owner: Pubkey,
    pub authority: Pubkey,               // who signed
    pub authority_is_delegate: bool,
    pub amount: u64,
    pub delta: u64,                      // what the cuts took (known after)
    pub source_balance: u64,
    pub destination_balance: u64,
    pub decimals: u8,
    pub supply: u64,
    pub source_hook_data: [u8; 64],      // the holdings' 64 bytes
    pub destination_hook_data: [u8; 64],
}

pub struct PoolHookArgs {
    pub op: PoolOp,                      // Initialize, AddLiquidity, RemoveLiquidity or Swap
    pub phase: Phase,
    pub pool: Pubkey,
    pub base_mint: Pubkey,
    pub quote_mint: Pubkey,
    pub actor: Pubkey,                   // the trader or liquidity provider
    pub recipient: Pubkey,               // the owner of the holding that receives
    pub direction: u8,                   // 0 a sell (base in), 1 a buy (quote in)
    pub amount_in: u64,
    pub amount_out: u64,                 // known after
    pub base_reserve: u64,
    pub quote_reserve: u64,
    pub virtual_base: u64,
    pub virtual_quote: u64,
    pub lp_fee_bps: u16,                 // after a swap: the fee applied
    pub protocol_fee_bps: u16,
    pub swap_count: u64,
    pub created_at: i64,
    pub lp_amount: u64,
    pub hook_data: Vec<u8>,              // from the caller, up to 256 bytes
}

Answers#

A before_* callback, and a pool’s after_swap, may answer in its return data. Which fields it may fill depends on the callback and the flags; a field it may not fill must be empty, zero or None, or the whole answer is refused (UnsupportedHookReturn).

pub const MAX_DELTAS: usize = 3;
pub const HOOK_DATA_LEN: usize = 64;

pub struct Delta {
    pub amount: u64,                     // above zero
    pub account: u8,                     // index in the callback's accounts; must be an extra
}

pub struct HookReturn {
    pub deltas: Vec<Delta>,                              // at most MAX_DELTAS
    pub burn: u64,                                       // pool swap callbacks only
    pub lp_fee_bps: Option<u16>,                         // before_swap only
    pub source_hook_data: Option<[u8; HOOK_DATA_LEN]>,   // token callbacks only
    pub destination_hook_data: Option<[u8; HOOK_DATA_LEN]>,
}

After-phase token callbacks, and initialize and liquidity callbacks, answer nothing. The calling program, after decoding:

• reads an answer only when the flags allow one for that callback, and only when the return data is the hook program’s own;
• takes at most three cuts, each above zero, no account named twice, the sums in checked arithmetic (an overflow is DeltaTooLarge);
• on a transfer: the cuts add up to at most the amount, each to a writable holding of the mint that is not frozen and is neither the source nor the destination. The source loses the amount; the destination gains the amount less the cuts. A token callback never answers a burn;
• on a swap: the cuts and the burn stay below the side’s amount, each cut to a writable holding of that side’s mint, never a vault or one of the trader’s holdings; a burn needs the mint passed writable (MintNotWritable), and min_amount_out is checked against what the recipient’s holding actually gained.

Extra accounts#

A hook that needs accounts of its own publishes them at PDA(["bordrless-hook-accounts", mint-or-pool], hook_program): a list of literal keys, or PDAs whose seeds are literals or keys already in the callback’s list (the fixed prefix first, then the extras in order). Clients resolve the list and append the accounts; the calling programs pass them through untouched.

A swap, in order#

The protocol fee is always taken in the pool’s quote token, on both sides; the LP fee stays on the input side. A pool hook’s answer is taken at two points, drawn on ink below: from the input before the curve, and from the output after it.

Each pool copies how Bordrless is paid from the DEX config when it is created and keeps it for life (fee_model). An ordinary pool, one anyone opens, pays a flat 1% of the quote. A launch pool, a curve the launchpad creates as its own hook (only the launchpad’s: a curve any other program opens as its hook pays the flat rate), pays no flat rate: Bordrless takes 25% of what the pool’s hooks cut on each swap, the creator fee, holder rewards and any cut a creator’s own token hook takes, measured by the DEX as what left the trade and reached someone, in the quote. A base-side cut is valued at the swap’s own price. Burns and the LP fee are not shared, and a launch whose rules collect nothing pays nothing: there is no floor.

Holding.hook_data: [u8; 64] sits after frozen. Only the mint’s hook program can change it, in two ways:

1. by answering source_hook_data or destination_hook_data from before_transfer, before_mint (the destination only) or before_burn (the source only), when the mint has WRITES_HOOK_DATA; the token program writes it with the balances, after applying the operation;
2. by calling write_hook_data(data), signed by its own ["hook-authority"] PDA at the canonical bump, for a mint whose hook it is and which has the flag. It calls no hook. The kit’s claim uses it.

close_holding refuses a holding whose data is not all zero when the mint has a hook with WRITES_HOOK_DATA (HookDataNotEmpty): a hook’s record of what a holder is owed must not vanish with the account. Without a hook, or without the flag, nobody can ever clear the data, so the holding closes regardless.

Who can install it#

• KitConfig, at ["kit", mint], is created only by init, which must be signed by PDA(["kit-caller", mint], LAUNCH_ID). The kit knows LAUNCH_ID as a constant; that PDA signs nothing else and holds nothing.
• A kit launch’s mint is created with hook_program = KIT_ID and hook_authority = None, so which program runs is fixed from the token’s first instruction. The kit’s own code can change while it has an upgrade authority (section XI).
• Anyone can create a mint that names the kit as its hook. Without a KitConfig, which only a launch can create, every callback for that mint fails, so such a mint can never move.

Modules#

The mint’s flags are BEFORE_TRANSFER, plus BEFORE_BURN | WRITES_HOOK_DATA when holder rewards or the early-buyer lock is on. A launch with none of these modules gets no hook at all; a burn alone runs in the pool hook.

Owners#

• Excluded: the pool and the launch. Their holdings are not settled, not capped and not counted in eligible, and they cannot claim. Every other owner is a holder.
• Refused destinations (DestinationNotAllowed): the launch, the kit config, the default key, and the ids of the token, DEX, bridge, launch and kit programs.
• With holder rewards on, no program can hold the token: a transfer to an owner that is not excluded must go to an address on the ed25519 curve. No other pool, vault, escrow or multisig can hold it, so every pool trade happens on the launch pool and pays its rules. Trades that never hold the token in a program (two wallets swapping with each other, an order book moving tokens as a delegate) are not prevented and pay no launch fees; max wallet and the locks still apply to them.
• With holder rewards off, anyone can open another pool for the token. Burn, the creator fee and the buy and sell rates apply only on the launch pool, and max wallet caps another pool’s vault like any wallet until graduation.

The callbacks#

before_burn runs the sync, the early-buyer check, the settle and the eligible count on the source alone, and answers the source’s bytes. The creator wallet lock does not apply to burns: a burn extracts nothing.

Instructions#

Runtime#

• Callbacks make no CPIs and emit no events. While a callback runs, the token program is on the stack, so the kit could not call it for any mint.
• Heights: swap, then token, then kit is 3; a router on top makes 4. With no events in callbacks, a routed swap never reaches the limit of 5.
• Known addresses are compared with constants instead of derived on chain: the token program’s signer for the kit is C2Y3B3hZTesJQqLYrZ7qoaZUoRmwYWh5Qh3MuFxruouE, the DEX’s signer for the launchpad 6Ztfr97cUewdViXDXdZUsQq4pz7MYdygvK1WijALjZ5q.

A verified kit token#

The site and the indexer treat a token as a Bordrless launch with kit rules only when a Launch exists at ["launch", mint], the mint’s hook program is the kit with no hook authority and no mint authority, its flags match the config’s modules, and the KitConfig at ["kit", mint] names that launch and its pool. The indexer lists launches only from LaunchCreated, so look-alike mints never reach the board.

A fee on every transfer is the one thing Token-2022 already does, with its transfer-fee extension, so it makes a poor example. Holder rewards are the kit’s real work. The launch pool’s hook takes the holder fee from each trade, in bridged SOL, and pays it into the reward vault, a holding of the token’s KitConfig. The kit divides whatever arrives among the eligible supply.

The accounting#

KitConfig keeps acc_per_share: the lamports earned so far per eligible base unit, scaled by 10¹². Each holder’s 64 bytes keep a snapshot of it and what the holder is owed. Every callback first syncs, dividing what arrived since the last one, then settles each holder it touches at the balance it had before the operation.

pub fn sync(&mut self, vault_amount: u64, now: i64) -> Result<()> {
    let released = self.release(now)?;          // the share stream; paused while nobody is eligible
    let total = vault_amount + self.total_claimed;
    let fresh = total - self.seen + released;    // what arrived since the last sync
    self.seen = total;
    if self.divides() {                         // eligible > 0 and eligible >= min_eligible
        let pot = fresh + self.held;
        self.held = 0;
        if pot > 0 {
            let scaled = u128::from(pot) * SCALE + self.rem;     // SCALE = 10^12
            let inc = scaled / u128::from(self.eligible);
            self.rem = scaled - inc * u128::from(self.eligible);  // the exact remainder, kept
            self.acc_per_share += inc;
            self.total_distributed += pot;
        }
    } else {
        self.held += fresh;                     // waits until holders hold enough
    }
    Ok(())
}

pub fn settle(data: &mut HolderData, balance: u64, balance_after: u64, acc_per_share: u128) -> Result<()> {
    let earned = u128::from(balance) * (acc_per_share - data.snapshot) / SCALE;   // rounded down
    data.owed += u64::try_from(earned)?;
    data.snapshot = if balance_after == 0 { 0 } else { acc_per_share };
    Ok(())
}

While holders hold less than min_eligible, a thousandth of the supply, nothing is divided: what arrives waits in held, and the pool hook takes no holder fee at all. Rewards accrue with every trade, not by the second, and they stay with the wallet that earned them.

Claims#

claim syncs, settles the holder at its balance and pays min(owed, reward vault) to the holder’s bridged-SOL holding. It writes bytes 0 to 23 through write_hook_data and keeps bytes 24 to 63 exactly as read, so a claim never unlocks an early buyer. A wallet that sold everything keeps what it earned: what it is owed stays in its holding until it claims, and the holding cannot close until then. The site claims for up to about four tokens in one transaction and unwraps the SOL.

Share with holders#

share(amount) lets anyone send bridged SOL that every holder receives in proportion to what they hold. It streams: a share joins the stream at its own rate, its amount over 3,600 seconds, and is out within the hour, so buying just before a share and selling after it gains nothing. While nobody is eligible the stream pauses, and resumes with the same time left.

Why the vault always covers it#

After every instruction the reward vault holds at least what every holder could claim, plus what is held, plus what is still streaming. Four facts carry it:

1. eligible is the sum of the balances that will be settled: every balance change of the token passes through a kit callback, minting is impossible (no mint authority), and excluded owners are never settled and cannot claim;
2. every balance change of a holder is settled first, at the balance before the change;
3. rounding always favours the vault: the division floors with its remainder kept, owed floors, stream releases floor;
4. shared lamports count as seen when they arrive and reach holders only as they are released.

The off-chain mirror#

What the site shows as claimable is a pure function of account state, read with one call for KitConfig, the reward vault and the holding:

released  = what the stream releases by now        // 0 while nobody is eligible
pending   = vault.amount + total_claimed - seen + released
acc       = acc_per_share
if eligible > 0 and eligible >= min_eligible and pending + held > 0:
    acc   = acc_per_share + ((pending + held) * SCALE + rem) / eligible
claimable = 0 for the pool and the launch,
            else owed + balance * (acc - snapshot) / SCALE          // floors
a claim pays min(claimable, vault.amount)

The last two are safety rails, said honestly: a transfer hook could do these too; here they’re standard, bounded on chain and fixed at launch.

Choices and presets#

The launch form offers these choices, under “Token rules (fixed at launch)”, and starts on Plain.

Half-Life#

Half-Life is Bordrless’s own token hook, and the clearest example of what a hook here can do that a Token-2022 transfer hook can’t. Sell or send a Half-Life token the moment you get it and 20% of what you move is burned. The fee halves every six hours you hold (10% at 6 h, 5% at 12 h, 1.25% at a day) and is gone after two days. Buys never pay it. Pick “Half-Life” on the launch page; it launches from Bordrless’s config ABz5Je9FznnotUQxxaj28vn18t1Wv9SsDzEfDxGLRJY.

• Every holding remembers when its tokens arrived, in the 64 bytes of hook data inside the holding. Tokens sent to another wallet keep their age, so moving them resets nothing; buying more averages the age by weight.
• The fee is taken from the tokens being moved, before they move, into the token’s furnace. Anyone can burn the furnace, so early sellers shrink the supply for everyone who stays.
• A transfer hook can’t take part of a transfer, can’t keep state inside a holding without an extra account per holder, and Token-2022’s own transfer fee is one rate for everyone.
• The launch prepares the hook for the mint, launches, and lights the furnace: three transactions in one approval. On sells, Bordrless’s share is 25% of the fee’s value in SOL, as for every launch rule. The program is open source and a verified build: programs/half_life.

Build your own#

A launch can run a token hook you wrote instead of the kit. The rules travel in a LaunchConfig: an account anyone makes once with the SDK (buildCreateConfig) and reuses, holding the rules, the creator fee, the hook program and its flags, and a label. Its key is what the launch page takes under “Build your own”: the page reads it, shows every rule and the hook with who can upgrade it, checks it against the bounds, and launches with it. The mint is created with that hook and no hook authority.

• Burn and the creator fee are pool-hook rules and may go with a custom hook; holder rewards, max wallet and the locks are the kit’s, so a config with a hook can’t have them (one token hook per mint).
• The hook must be prepared for the mint before the launch: its registry at ["bordrless-hook-accounts", mint] for the mint address the page shows (tax_hook.prepare is the worked example). The registry must not depend on who sends or receives.
• Nobody vets the code. Such a token is “Custom hook, unverified” on every surface, with the program, its upgrade authority or “fixed”, and the one warning: written by the creator, not Bordrless; it can refuse transfers or take part of them. A hook that refuses sells is a honeypot the DEX stays sound through: the swap fails whole, nothing moves.

Bounds#

create_launch refuses anything outside the launch config’s bounds, and no config can raise a bound past its ceiling. The kit checks its own hard bounds again in init.

One fee per side#

The site shows one compounded figure per side, in the order the DEX charges them, and names who receives each part:

buy  = 1 - (1 - (creator + holders)(1 + s)) (1 - lp) (1 - burn_buy)
sell = 1 - (1 - burn_sell) (1 - lp) (1 - (creator + holders)(1 + s))

lp is the current LP fee (the sniper fee while it is elevated, 0.3% after) and holders is 0 while nobody is eligible. Bordrless takes 25% of what a launch’s rules collect: a quarter of the creator fee and holder rewards (and of what a creator’s own hook takes), in SOL, on buys and on sells, on the curve and after graduation. A launch whose rules collect nothing pays Bordrless nothing; burns and the pool fee are not shared. Plain (creator 1%) is 1.5437% per side, printed to a tenth and rounded up: Buy 1.6% · Sell 1.6%; Diamond hands (creator 0.5%, holders 1%) Buy 2.2% · Sell 2.2%. Price impact is the curve’s movement only; fees are their own lines.

Every launch mints 1,000,000,000 tokens; 75% are sold on the curve, and it graduates at a fixed SOL raise. On each swap of its pool:

• Before every swap it sets the LP fee: 0.3%, or during the first 30 seconds a fee that starts at 80% and falls linearly to 0.3%. The pool keeps it.
• A buy: before the curve, the creator fee and, while holders hold enough, the holder fee, from the SOL in, as cuts to the launch’s SOL holding and to the holder vault; after the curve, the burn from the tokens out.
• A sell: before the curve, the burn from the tokens in; after it, the creator and holder fees from the SOL out. The DEX then holds its quarter of those two fees back from the delivery.
• The creator’s own first buy, into the creator’s wallet inside the sniper window, pays the normal LP fee instead of the sniper fee, once. A bot that buys first no longer takes that exemption from the creator.

index 5   launch                  writable
index 6   launch SOL holding      writable   creator fees are paid here
index 7   holder vault            writable   holder fees are paid here
index 8   kit config              read       for the holder-fee threshold

Graduation is a separate, permissionless instruction. It tops the pool up from the reserve so the price does not move when the virtual reserves are dropped, burns the rest, and the DEX mints the first LP to the launch, which has no instruction to spend it. For a launch with kit rules it then calls the kit’s graduate, which lifts max wallet. Solana forbids indirect reentrancy, which is also why graduation is its own instruction rather than part of after_swap.

The bridge wraps SPL Token and Token-2022 mints and native SOL into mints of the standard, one for one, and unwraps them. The original sits in a vault owned by the wrapper PDA. A mint nobody has bridged yet is registered by the first wallet that bridges it. Bridged SOL is what every launch is quoted in; the site wraps and unwraps it inside a trade, so a trader only ever sees SOL.

The addresses are the same on localnet and devnet; mainnet gets its own keys at deploy time. An upgrade authority is read from each program’s ProgramData account; a dash means it has not been read yet, not that there is none.

• The token, DEX, launch, kit and bridge programs keep their upgrade authority, the deployer key, on localnet and devnet. Section X shows who holds each one.
• Before the first mainnet launch, each authority moves to a multisig behind a public timelock.
• The kit’s upgrade authority is revoked once the kit is audited.
• The DEX’s pause flag, which stops every swap, moves to the same multisig.
• Every program’s IDL is published on chain at deploy, so explorers decode its accounts, KitConfig included.

That is why the site says a launch’s rules are “fixed at launch: the creator can’t change these” and claims no more. Nothing a creator signs can change a launch’s rules: they are written into its KitConfig and its Launch at creation, and no instruction rewrites them. But while a program keeps an upgrade authority, its code can change.