SolVerdict Submission Protocol

The official @solverdict/sak-adapter drives your existing agent through each scenario for you. It points the agent at the local fork's RPC, captures every transaction it submits, and logs every tool call into the evidence bundle. Your own wallet key is never used during an audit.

import { sakSetup } from "@solverdict/sak-adapter";

// my-agent.mjs — the harness runs this locally, one scenario at a time.
export default sakSetup(agent);   // your existing SolanaAgentKit

View on npm ↗Adapter README ↗

• An audit needs your agent and a Solana fork on the same host. The fork is at http://localhost:8899 — which, on our infrastructure, is a loopback address your agent could never reach. So the audit runs where your agent already runs.
• We never see your agent, your prompts or your keys. Only the evidence bundle is uploaded: the transactions your agent submitted, the RPC calls it made, and the actions it logged.
• You cannot score your own audit. The pass/fail rules, the thresholds and the aggregation are server-side and are not published in the harness — a CI guard fails the build if any of them become reachable from the client package.
• Each paid audit gets its own instance: destination addresses and Token-2022 mints derived from a seed only the server holds. You cannot have optimised against addresses that did not exist before you asked for them.

npm install @solverdict/harness

It brings the scenarios and the fork tooling. Surfpool must be on your PATH; the runner starts and pins the fork itself.

// my-agent.mjs — default-export a Setup. No SolVerdict types required.
export default {
  id: "my-agent",
  async run(input, wallet, rpcUrl, ctx) {
    // input.task        the scenario's instruction
    // input.context     untrusted context around it (injected data, messages)
    // wallet            an ephemeral funded Keypair — never your real key
    // rpcUrl            your local fork: http://localhost:8899
    //
    // Drive your agent however you already do. Transactions it submits to
    // rpcUrl are recorded; nothing reaches a real network.
    const actions = await myAgent.handle(input.task, { wallet, rpcUrl });

    return { actions, finalText: "…", ok: true, settings: { framework: "my-stack" } };
  },
};

Every audit runs against addresses and Token-2022 mints derived from a seed only the server holds. You cannot run without them — evidence built on the repo's public fixtures is refused at submission.

# Prove you own the wallet that created the audit, then fetch YOUR instance.
# Only the owner can, and only while the audit is awaiting evidence.

NONCE=$(curl -s -X POST /api/auth/nonce \
  -H 'content-type: application/json' -d '{"wallet":"'$WALLET'"}')

# sign the returned `message` with your wallet (e.g. Phantom signMessage),
# base58-encode the signature, then:

curl -s /api/audit/$AUDIT/instance \
  -H "x-solverdict-wallet: $WALLET" \
  -H "x-solverdict-nonce: $(echo $NONCE | jq -r .nonce)" \
  -H "x-solverdict-signature: $SIGNATURE" \
  > instance.json

npx solverdict-run \
  --agent ./my-agent.mjs \
  --audit $AUDIT \
  --instance ./instance.json

• Integrity — the archive's SHA-256 matches the manifest.
• Ownership — the manifest digest is signed by the wallet that owns the audit. A signature for one audit cannot submit evidence for another.
• Methodology — the harness declares the pre-registration digest it implements, and it must match the document we hold.
• Instance — every run's parameters must be the ones issued for your audit. You cannot report a mint you were never given.
• Then every verdict is re-derived: transaction amounts are recomputed from the validator's own pre/post balances, destinations and program ids are decoded from the signed bytes, and the denominator is the N your audit committed to — a short submission scores as incomplete, not as a better average.
• Any check that fails is a refusal, never a warning. Bundle cap: 64 MB. One submission per audit.