Verafy Harness v0.0.4: The Judiciary Signer, and Every VIP So Far

Most crypto losses aren't clever hacks. They're keys. A multisig with three signers is three people who can be phished, pressured, bribed or just wrong on the same afternoon. A launch that promises the team's tokens are locked is a promise, until someone moves them. Every wallet rule today is either code, which can only check what code can see, or a person, who can be talked into anything.

Yesterday's post introduced Verafy Harness: an AI model wrapped in everything a validator does, judging contracts written in words, in juries drawn across model families. That post ended with a jury that could rule. This one is about what a ruling can do once it has teeth.

The answer in v0.0.4-alpha is the Judiciary Signer: a member of a Squads multisig that no person holds a key for. It votes yes or no on a proposal only when a sealed jury ruling says to, and only if that ruling is bound to the exact bytes of the transaction. Around it, this release ships a policy language, a harness registry, hardware attestation, model certification, bias profiles, an on-chain encoder, a validator commission covenant and records for selling physical things.

It is a prototype on a local validator, not a product on mainnet. This post says exactly which parts have run.

The VIP system

Every feature in this release started as a written proposal before any code: a Verafy Improvement Proposal, or VIP. It's the same habit as Solana's SIMDs or Ethereum's EIPs, applied to one project.

A VIP says what is broken today, what changes, the trade-off, and what would make it done. It gets a tracking issue. Then it gets built, and the status line says what shipped and what is still open, in plain words. A VIP is never marked done by leaving the hard part out of its status: VIP-0013 says "verification; a run in a real enclave and a reproducible image open," because that's the truth.

The rules:

• Written first. No feature lands without its VIP.
• Status is a sentence. "Idea", then "Shipped (version)", with anything still open named.
• Numbers are labeled. Every figure is measured, modeled or vendor-reported, and says which.
• Defaults are Rex's call. Where a VIP picks a default (bond weighting, unbonding time, prices), it says so, and it can be changed.

Pilots with real teams get their own designation, a Verafy App Pilot (VAP), so a proposal for the protocol is never confused with a project for a customer. More on those below.

All proposals live in docs/proposals, with an index.

Every VIP, and where it stands

Nineteen VIPs are shipped. Eight are upcoming.

The rest of this post walks through them.

The Judiciary Signer

Here's the setup. A treasury is a Squads multisig. Its members are two people and one Judiciary Signer, with a threshold of two. The people can't move funds alone: they need the signer, and the signer only votes the way a jury ruled.

The signer is a program address, so no key for it exists anywhere. It is a program called verafy_judiciary, and its address is derived from its config account. When it's attached, the config fixes four things that can never change afterward:

• The jury: one to eight harness keys.
• The bar: the share of the jury that must agree.
• The policy: by hash.
• The models: by hash, up to three, each open-weight or certified.

A proposal becomes a case. Registering a case records a hash that binds the signer, the proposal and the transaction account's bytes. Change one byte of the transaction and the case no longer matches. The jury rules on that case through verafy_ruling, the program from earlier releases that handles commit, reveal and seal. Then anyone can call decide, and the signer approves or rejects the Squads proposal by calling into Squads itself.

Before it votes, the program checks that the ruling:

• is sealed, and its challenge window has passed;
• came from exactly the jury named at attach time;
• clears the bar;
• carries this case's hash, so it is about this transaction and nothing else.

It also has a way out if the jury never shows up. An optional escape hatch approves a case after a long, public delay with no ruling. A case the jury rejected can never escape. The case fee sits in the case account until the ruling, and is then split among the jurors who revealed.

What has run

The Squads v4 program was dumped from mainnet and loaded onto a local Solana validator, alongside Verafy's four programs. A script then ran 30 checks end to end, against real Squads accounts and real cross-program calls. 30 of 30 passed (measured, November 8, 2026 UTC, solana-test-validator 2.1.21, results file). Among them:

• the human alone doesn't reach the threshold;
• a ruling from a jury the signer didn't name is refused;
• a ruling on a different case is refused;
• a ruling still inside its challenge window is refused;
• after the window, the signer approves, and the transfer executes from the vault;
• a decided case can't be decided again;
• a REJECT ruling votes no, and a rejected case can never escape;
• the escape hatch is refused before its delay and works after it;
• the case fee splits among the jurors who revealed, once.

Nothing is deployed to devnet or mainnet yet. That's VIP-0020, and it's waiting on devnet SOL for the deployer, because the public faucet is rate limited.

Programs first, SIMD later

All of this runs on ordinary Solana programs. No change to Solana is needed. That's a deliberate rule, VIP-0017: build on programs now, measure where programs fall short in real use, and only then propose a SIMD for the specific limit that hurts. The three draft SIMDs from Bringing Inference Programs To Solana are still the long-term shape. The programs are how it ships this year.

Policies, and Covenant Launch

A policy is what a Judiciary Signer enforces (VIP-0011). It has three parts:

• Rules: checks any computer runs on the decoded transaction and gets the same answer. Allowed programs, a maximum per transaction, a maximum per window, allowed recipients, a release schedule, and whether the wallet's own config may change.
• Intent: one plain statement of what the wallet is for.
• Judgment: the questions only a jury can answer, like "is this payment for the milestone the grant describes?"

Rules run first, and a hard rule breach is a rejection whatever the jury thinks. Judgment comes in only where rules can't reach. Four templates ship: treasury, upgrade authority, commission covenant and Covenant Launch.

Covenant Launch is the one I most want someone to try. Today's meme coin launch usually hides the creator's supply across many wallets and sells it into buyers. Covenant Launch does the reverse:

• The creator's share, say 80%, sits in one visible Squads wallet.
• The covenant says how much may be released, when, and to whom. For example: nothing for 30 days, then 5% a month, only to the published market maker and exchange addresses.
• The Judiciary Signer refuses anything else, including a transfer one lamport over schedule.
• Anyone can read the covenant and check that the signer on chain carries the same hash, before they buy.

It doesn't make a coin worth anything. It makes one specific kind of rug impossible to do quietly.

The harness registry

Until now, the pool of harnesses was a file. VIP-0012 puts it on chain. verafy_registry holds one account per harness: its key, operator, model and family, a commitment to the model, its endpoint, its price per seat, its attestation hash and its bond.

• Register needs both the harness key and the operator to sign, proving the operator controls the key that will vote.
• Find every harness with one getProgramAccounts call.
• Pay from the case escrow when the ruling is decided.
• Retire, then wait out an unbonding delay before the bond can be withdrawn, so a harness can't pull its bond the moment it misbehaves. The delay is 864,000 slots, about two epochs at 400 ms slots (modeled), and illustrative until it's set.

The model can't be changed by update. A new model is a new harness.

verafy harness register    # put your harness on the registry
verafy discover            # list every registered harness

On the local validator, three harnesses registered and were discovered in one RPC call, a non-operator was refused, a retired harness dropped out of discovery, and an early withdrawal was refused (measured, part of the 30 checks).

Hardware attestation

A registry entry says what a harness claims to run. VIP-0013 lets it prove it. A harness running in an AMD SEV-SNP confidential VM produces an attestation report, signed by a key that chains to AMD's root certificate. The report carries the VM's launch measurement, and its report data holds the hash of the harness's voting key and the hash of its build. Together that says: this voting key was generated inside an enclave, running a known harness build, on real AMD hardware.

Verification is built and tested, including the P-384 certificate chain, against test certificates. Jury rules can require attested. What's open, and is VIP-0022: running a harness in a real SEV-SNP VM, publishing a reproducible image whose measurement anyone can check, and then GPU attestation for models served on NVIDIA confidential computing.

Model certification

Wallet owners will want to say "use this version of Claude." A closed model can't be proven the way open weights can, and the weights behind a name can change. VIP-0014's answer: open-weight models may be used freely, and a closed model may be chosen only with a certification: its measured results on the judiciary attack suite, at a pinned version, above the bar. The results are published with it, as that model's known attack parameters.

The suite and the bar are built. The bar is illustrative. No real model has been certified yet; that's VIP-0023.

Bias profiles, with probes the model can't see coming

A jury of different models only helps if they don't all lean the same way. VIP-0018 measures how a model leans. It sends paired probes, the same case twice with one thing changed that shouldn't matter, and records how far the answer moves:

• option order;
• an authority claim planted in untrusted text;
• framing;
• the position of evidence;
• swapped roles;
• an anchor number;
• length.

It also records the approve rate, overconfidence and inconsistency. Profiles go on a map, and a jury can be chosen to share the least bias.

The important part: a model that knows it's being tested can behave differently. So the probes are unannounced. They're injected among real cases at times drawn from a committed seed, so nothing in a request says "this one is a test." Escrow and wallet-case probe suites are built. No real model has been profiled yet; that's VIP-0023 too.

The encoder

The chain stores hashes. A signer's config holds its policy hash, a ruling holds its contract hash, and the text lives somewhere else. VIP-0019 writes the full text onto Solana, so anyone can fetch it from the chain and check it against the hash.

Two backends:

• Memo: chunks in Memo instructions. On the local validator, it wrote a 1,759-byte policy and read it back, and a reader refused it against the wrong hash (measured).
• IQ Labs Code-In: stores data inside ordinary Solana transactions. The backend is written and ready, and hasn't been run on devnet.

When Solana has a SIMD for data availability, the encoder switches backends and nothing else changes.

The commission covenant

This one is for Solana validators, not apps. A validator posts a bond and promises not to raise its commission above a stated level until a stated slot (VIP-0016). verafy_covenant reads the vote account directly, so nobody has to report a breach: if the commission is over the promise before the end, anyone can claim, and the bond pays out. If the promise is kept to the end, the validator gets the bond back. Stakers and stake pools can see the covenant before they delegate.

On the local validator: the vote account read as withdrawer and commission, a bond was posted, a claim failed while the promise held, a kept promise returned the bond, and raising the commission paid the bond out (measured).

Today a breach pays one beneficiary account. Paying each staker by their stake is VIP-0025. For promises code can't see, like "we'll give 30 days' notice," there's a jury template.

Asset transfer records

Physical things are the hardest case for a chain, and the best case for a jury. VIP-0015 builds the records for selling one. A seller lists an item, say a bicycle, with:

• photos, including the serial number;
• an ownership document;
• a purchase agreement;
• receipts and certificates.

When it arrives, a one-time delivery code and the buyer's photos go to a jury, which rules MATCH or NO_MATCH against the listing. That ruling releases or holds the payment under an asset-sale policy. Each step produces a signed record: transfer, ownership and receipt. A localizer renders them in the reader's language and currency.

Earlier in this release line

v0.0.4 sits on three releases from the last two days. All of it is in the spec changelog.

• v0.0.1-alpha: one spec across 17 areas with stable requirement IDs, and a scoring pass that checks every claim against the code. Also multi-model routing, proof packing, the banker and proving.
• v0.0.2-alpha, run it anywhere: the harness daemon, verafy up, cloud clients, the container, the local testnet, the verafy_ruling program on a local validator, and the banker service.
• v0.0.3-alpha, stake and slashing: juries counted by model family on open-weight models; VIPs 0001 to 0009; slashing and held payouts in the testnet coordinator; reveal and challenge windows in verafy_ruling.
• v0.0.4-alpha: everything above. The spec scores 68% across 137 requirements (measured by the scoring pass), and npm test runs 246 tests, 234 passing, 0 failing (the rest are skipped where they need a network or a key).

The launcher

You can run a harness today. The launcher (verafy up) picks a target and a model and starts one:

curl -fsSL https://raw.githubusercontent.com/Verafyai/verafyHarness/main/install.sh | sh
verafy up                    # local, Docker, DigitalOcean, Hetzner or any cloud
verafy up --ui               # the same, as a page on 127.0.0.1
verafy harness serve         # the daemon itself, configured by VERAFY_* variables
verafy harness register      # put it on the registry
verafy discover              # find every registered harness

An API harness needs 2 vCPU and 4 GB of RAM and a model API key. An open-weights harness needs a GPU. The launch page and Run a harness cover sizing, models, costs and earnings.

The testnet

There is no public testnet yet. Here's what exists and what's planned.

Local devnet, available now. A full jury on one machine:

npm run demo                                          # five contracts, five rulings, five blocks
node bin/verafy.js run examples/market-resolution.json --live
node bin/verafy.js chain
verafy testnet up --solana                            # settle each ruling on a local Solana validator
verafy testnet up --misbehave h-llama-1:no-reveal     # watch a fault get slashed

Testnet 0, planned (VIP-0026). Every phase is play money. There's no token on testnet or after it.

To get in line: run the local devnet and a live ruling, then open an issue titled Testnet harness: <your handle> with your setup. The testnet page has the details.

The roadmap: three stages

1. Build it on Solana programs, with no SIMD. The harness, launcher, testnet and infrastructure run on ordinary programs: verafy_ruling, verafy_judiciary, verafy_registry and verafy_covenant. This is where things are now.
2. Prove it with 10 to 50 pilots. Real wallets and launches, built alongside each team. Each pilot becomes a template the next customer gets for free.
3. Show the demand, then scale to a SIMD. Publish adoption, measure where programs fall short, and propose the SIMD that removes that limit.

The roadmap page has it for readers; ROADMAP.md has every milestone with a checkable done condition.

Pilots: fifteen VAPs

Stage 2 needs real teams. The pilots page lists the Solana apps that earn the most (revenue reported by DefiLlama, not measured by us) and one to three jury projects for each. Fifteen are written up as Verafy App Pilots, each with a done condition and a first metric. They're ranked by how well a jury fits the problem and how reachable the team is, not by revenue:

1. Judiciary Signer in Squads
2. Covenant Launch on a mid-size launchpad (Bags or LetsBonk)
3. Milestone treasuries at MetaDAO
4. Card condition disputes at Collector Crypt
5. A covenant badge on DEX Screener token profiles
6. Bounty acceptance at Superteam
7. DAO proposal review at Jupiter
8. Insider check at launch on Pump
9. A commission covenant for a validator or Sanctum LST
10. A policy review scanner for any Squads treasury
11. Covenant and risk signal in a trading app (Axiom, fomo or GMGN)
12. Policy-checked signing in Phantom
13. Reward fraud review at Geodnet
14. Risk-parameter changes at Kamino
15. Launchpad covenants at Jupiter and Meteora

Squads comes first, because every other wallet pilot rides on it. No pilot has run yet, so the page describes value and doesn't estimate it.

What's next: the upcoming VIPs

These are written and waiting. Each says what's missing today and what done looks like.

• VIP-0020, devnet and a public jury. Deploy all four programs to devnet with fresh keys, register Verafy's own harnesses as a public jury, and rerun the 30 checks against devnet, with compute units per instruction.
• VIP-0021, on-chain slashing. Faults are priced and bonds sit on chain, but nothing on chain takes a bond yet. A slash instruction would act on evidence the program can check itself: two signed commitments for one seat, or a reveal that doesn't match its commitment.
• VIP-0022, enclave harnesses. A reproducible VM image running in SEV-SNP with a published measurement, then GPU attestation.
• VIP-0023, real-model certifications. Run the certification suite and the bias profiler on real models at pinned versions, and publish them as measured.
• VIP-0024, registry-drawn juries. A signer names rules (models, families, attestation, minimum bond) instead of keys, and each case's jury is drawn from the registry by the beacon.
• VIP-0025, pro-rata staker payouts. A broken commission covenant pays every affected staker by stake.
• VIP-0026, Testnet 0. The phases above.
• VIP-0027, a fast lane. A cheap first screen that may settle only a contract's declared safe default, calibrated on a held-out set and measured against full juries before it's offered. Everything else goes to a full jury.

What doesn't work yet

• Nothing is on devnet. Every on-chain number here is from a local validator.
• No enclave run. Attestation is verified against test certificates, not a live SEV-SNP VM.
• No model certified or profiled. The suites are tested with scripted models.
• Slashing is off chain. Bonds are held on chain; taking them isn't.
• Juries are named by key. Changing a signer's jury means attaching a new signer.
• Bad evidence still wins. A jury reduces single-model error and does nothing about forged inputs. Challenges with new material are the defense.

Try it

git clone https://github.com/Verafyai/verafyHarness.git
cd verafyHarness
npm test        # no dependencies to install
npm run demo

If you run a treasury, a launchpad or a validator and one of the pilots above looks like your problem, open an issue or get in touch. It's just a project. Come break it.

Links: Verafy Harness on GitHub · Judiciary Signer · Policies · Roadmap · Pilots · VIPs · Testnet