Overview – Regent Protocol

Regent’s on-chain footprint is three Anchor programs deployed to Solana devnet. Each program is non-upgradeable and authored to be minimal — they store hashes and status, not application logic.

The three programs

Program	Devnet ID	Purpose
`agent-registry`	`5jBmqyeo1vUAjHbEFuY59NMGTQR8cEe9Jvz2uCwCjp3L`	Agent identity registration, revocation, status transitions
`mandate-registry`	`8HAzw3UFGmabsHJkAsuGLfBZG8djYQ3J1FRNUVjkseMr`	Mandate registration and revocation
`audit-anchor`	`8N1PpbJZKmvJjG86XWpP82XrWzp8HY5FHZuzyQTgjJas`	Merkle batch root storage for audit events

All three programs accept signed instructions from the blockchain-worker service, which holds the protocol authority keypair. End users never call these programs directly — the protocol mediates all writes.

Why on-chain at all

Regent’s PostgreSQL stores the authoritative state. The on-chain programs serve as a second, independent source of truth that:

Cannot be silently modified, even by Regent itself
Is publicly observable without trust assumptions
Outlives any single service or deployment

This is the foundation for credibility with regulators and counterparties. An auditor can verify what Regent claims by reading Solana, without trusting Regent’s database.

Why Solana

Property	Why it matters for Regent
Sub-second finality	Agent state changes (registration, revocation) need to take effect immediately, not minutes later
Low fees	Frequent anchoring (every audit batch) would be prohibitive on slower L1s
Native programmability	Anchor framework lets us write tight, audited Rust programs rather than generic EVM contracts
Standard tooling	`@solana/web3.js`, Phantom, Solana Explorer — judges and partners can verify without bespoke tools

Account model

Each program writes structured accounts (PDAs) keyed by the relevant identifier:

AgentRegistry:
  PDA = derive(["agent", agent_id_hash])
  Account = { agent_id_hash, did_hash, responsible_party_hash, status, registered_at, revoked_at }

MandateRegistry:
  PDA = derive(["mandate", mandate_id])
  Account = { mandate_id, agent_id_hash, per_tx, daily, monthly, currency, status }

AuditAnchor:
  PDA = derive(["batch", batch_id])
  Account = { batch_id, merkle_root, event_count, sealed_at }

Off-chain components (the SDK, the dashboard) can re-derive any PDA from public data and read the account state directly via standard RPC.

Verifying on-chain

Every API response that has an on-chain component carries a solana_tx field — the transaction signature. Drop it into explorer.solana.com and you’ll see:

The instruction that was executed (register_agent, revoke_agent, register_mandate, seal_batch, etc.)
The PDA account written
The protocol authority signature
The block time and slot

For programmatic verification, see Verifying on-chain.

Source

The Anchor programs live in packages/contracts-solana/ of the regent-protocol repo.

packages/contracts-solana/
├── Anchor.toml
└── programs/
    ├── agent-registry/src/lib.rs
    ├── mandate-registry/src/lib.rs
    └── audit-anchor/src/lib.rs

Build and test locally:

cd packages/contracts-solana
anchor build
anchor test
anchor deploy --provider.cluster devnet

Authentication AgentRegistry