How the On-Chain Audit Trail Works

Every agent action in Operator Uplift is hashed, logged, and eventually published on-chain. Here is the exact pipeline.

Step 1 — SHA-256 hash on the client. When an agent emits a tool_use block and the user approves it, we compute a SHA-256 digest of the action payload using the Web Crypto API. The hash covers: tool name, action, params, user ID, timestamp, outcome. This is the "leaf" of the audit tree.

Step 2 — Dual write. The leaf hash plus the full action details are written to two places: localStorage for fast client-side lookup, and a server-side Supabase table (audit_entries) via an authenticated POST. Supabase is the source of truth. localStorage is a cache.

Step 3 — Merkle root every N actions. On every 5th action, the server computes a Merkle root over all leaf hashes since the last publication. This collapses an arbitrary number of actions into a single 32-byte commitment.

Step 4 — Publish on-chain. The Merkle root is passed to the Anchor publish_root instruction on our program (deployed to Solana devnet, program ID LeHntjrypUvoedo4DHdBXUNyC2gKxnRH7wzp2UE2w1P). The server wallet signs the tx. The tx signature is stored in the audit_roots Supabase table.

Step 5 — Verify anywhere. To prove any single action was logged at time T, you fetch the leaf from Supabase, reconstruct the Merkle proof, and check the root matches what is on-chain. The on-chain commitment makes it impossible for us to quietly rewrite history.

The devnet deployment is the research-grade version. Mainnet is on the roadmap once the program is audited.