Solana's Verifiable Buyback Standard.
Revenue flies home.

Contract Address (Solana)

jj8qR527NXAjxnFoxQmPR1DczyoEdFGxiCwFNMCpump

A protocol earns fees. It says it used some of those fees to buy its own token back. That sentence is usually true and almost never checkable, because the only party who can tell you where to look is the party making the claim.

Bybak is a proposed standard for how to write that down so a stranger can look it up. It does not decide what a protocol should return, how much, or when. It specifies how the return executes and how it reads afterward: an identifier issued before the buying starts, an accumulation sliced across a window declared in advance, a destination declared before the tokens move, and a completion record published in one schema so returns from different protocols can be laid side by side.

The name comes from pigeon racing. A racing bird wears a numbered ring put on before it can fly, and the ring cannot come off afterward. Take the bird three hundred miles away and it comes home anyway. Nobody asks the bird where it has been. Somebody reads the ring.

That is the whole idea. Not a promise that revenue came home, but a number on its leg saying which return it was.

The reference program is deployed to Solana devnet as 8n1BA3TB1tfYzU75GR9CDePXZEeoXXEYQVEs3QqwTRrj, with the IDL published on chain. Mainnet deployment is prepared and has not been executed.

A buyback today is legible in isolation and illegible together. The transactions are on chain, and so are ten thousand unrelated ones from the same wallets. Without an identifier there is nothing binding a set of fills to the claim. Without a declared window the reported price is whichever interval was chosen after the fact. Without a declared destination, where the tokens went is answered afterward, and afterward there is always an answer and the answer is always reasonable.

None of that requires anybody to be lying. The failure is structural, and structural failures are fixed with shapes rather than with promises.

The second half of the argument is comparison. Forty protocols publishing in forty private formats produce forty things that cannot be set beside one another. The same forty publishing one schema produce a single question that can be asked of all of them. A schema only one team can see is not a standard, which is why the draft is public and stays public. Implementing it needs no permission and no relationship with anyone here.

%%{init: {'theme':'base','themeVariables':{
  'primaryColor':'#E9A94E',
  'primaryTextColor':'#2A3350',
  'primaryBorderColor':'#C79A4B',
  'lineColor':'#8A857C',
  'secondaryColor':'#9BA8C4',
  'tertiaryColor':'#EDE9E1',
  'fontFamily':'Inter, system-ui, sans-serif'
}}}%%
flowchart LR
  subgraph before["Declared before"]
    D["Identifier, input amount<br/>window, destination"]
  end

  subgraph away["Acquisition, elsewhere"]
    A["Executor chosen by the protocol<br/>slices across the declared window"]
  end

  subgraph after["Recorded after"]
    R["Acquired amount, average price<br/>resolved destination split"]
  end

  D --> A
  A --> R
  R --> S(["Any stranger<br/>derives the address, reads the record"])

  classDef band fill:#E9A94E,stroke:#C79A4B,color:#2A3350;
  classDef away fill:#9BA8C4,stroke:#8A857C,color:#2A3350;
  classDef read fill:#EDE9E1,stroke:#8A857C,color:#2A3350;
  class D,R band;
  class A away;
  class S read;

Three ideas carry the design.

• Band. An execution identifier issued before the acquisition begins and bound to one return. It cannot be attached afterward to something that already happened.
• Loft. A destination declared before the buy rather than explained after it. A destination chosen once the outcome is known is a different object entirely.
• Feed. One completion schema, so two protocols' records can sit next to each other and be read at a glance.

The declaration is validated when it is made, not trusted when it settles.

pub enum Destination {
    Burn,
    Liquidity,
    Stakers,
    Weighted { burn_bps: u16, liquidity_bps: u16, stakers_bps: u16 },
}

pub enum Schedule {
    Immediate,
    Twap { window_seconds: u32, slice_count: u16 },
}

A weighted split must total exactly ten thousand basis points. A time weighted schedule must span at least sixty seconds and declare a positive slice count, so that a single block print cannot be presented as an averaged acquisition. The execution identifier is unique per protocol because the account address is derived from it, which makes reuse impossible rather than merely disallowed.

Every account address in the system is derived from public seeds, so a reader needs nothing but the protocol's public key.

solana program show 8n1BA3TB1tfYzU75GR9CDePXZEeoXXEYQVEs3QqwTRrj \
  --url https://api.devnet.solana.com

• bybak — the specification draft, the reference Anchor program and its test suite, the account model, the devnet verification run, and notes on reading a record.

Stated on the first line rather than the last one, because a project arguing for verifiability that asks to be taken on faith has lost before it starts.

• Not a custodian. The program holds no revenue and moves no tokens.
• Not a venue or a router. Solana has both.
• Not a yield product. Nothing to deposit and no strategy to have an opinion about.
• Not an endorsement. Compliance would describe the shape of an execution, never whether it was a good idea.

The Loft is an X native community. No Telegram, no Discord, nothing to join anywhere else.

1. Show the record, not the announcement. A screenshot of a chart is not a record. A transaction a stranger can pull is.
2. Bring the window, not the candle. A single fill is one moment somebody selected. An average across a declared period is a number nobody chose.
3. State what is drafted and what is running. Hold this project to the same line it holds everyone else to.

• Site — https://bybak.fi
• X — https://x.com/bybak_fi
• Repository — https://github.com/bybakfi/bybak

Individual repositories are licensed under MIT unless noted otherwise.