Instruction

Candidates

Every week so far

Where the fees go

Buys and burns

Four steps

1. 

   One closed program

   Every day the keeper counts how often each program is called, over a sample of blocks spread across seven days, and keeps the ones with no verified build and no published interface. The twenty busiest are the ballot.

2. 

   Holders pick one

   Monday to Wednesday noon UTC a holder signs the sentence ARE vote <program id> week <n>. Weight is the smaller of the balance now and a day ago, capped at five percent of all votes per wallet. No votes, and the busiest candidate is taken.

3. 

   The bench runs

   The bytecode is read at one slot, which the report names. Every sBPF instruction is decoded. A thousand real transactions give up the selectors, the argument layout, the account roles and the seeds behind the program addresses.

4. 

   And then it is marked

   The recovered interface is handed back the same transactions. A call counts only when every argument is accounted for and the account list is one the bench saw. One leftover byte fails it. That share is the coverage, and it is published whatever it says.

Is the number worth anything

Coverage grades the bench against itself, so it was tested once against a program whose real interface IS public. The bench never saw that interface; it was read afterwards and compared.

If the program is yours

Nothing here is taken from anywhere private. The bytecode is what the chain serves to anyone who asks for it, and the transactions are the ones already in every block. No protection is bypassed and nothing is broken into. But a reading can be wrong, and the author is the one person who knows that for certain.

How the bench reaches you

If the bench ever sees a weakness

It does not go in the report, it does not go in the repository, and no working attack is written anywhere. The address in the program's own security.txt is written to, and a description follows only after a fix or after ninety days. If a program publishes no security.txt there is nobody to write to, so nothing at all is published about it beyond the interface.

The rest of the rules

What a week publishes

The recovered IDL as a file Anchor tooling reads, pseudo Rust for the recovered paths, a standalone decoder, and a report with the slot, the sample size and the coverage. A week under fifty percent ships marked draft.

Responsible disclosure

If the bench sees a possible weakness it does not go in the report. The owner is written to at the address in the program's security.txt, and a description follows after a fix or after ninety days. There is no attack code in any report or repository, ever.

Owners of programs

Everything used is public: bytecode the chain serves and transactions anyone can read. Nothing is bypassed and nothing is broken into. A correction from the author beats anything a disassembler can see, so if a program here is yours, say so and the page says what you said.

The budget

Half of the forwarded fees pay for the model and the server, forty percent buys $ARE and burns it once a day, ten percent pays for RPC and hosting. The model has a weekly ceiling and whatever is left rolls into the next week.

What can go wrong

A program can be upgraded mid week, so the report names the slot it was read at. A recovery can be poor, and the coverage says so instead of hiding it. The argument list is recovered from bytes, so a struct the author declared as one argument comes back as the fields it is made of.