Every meaningful action gets an audit event: hashed on receipt, Merkle-batched, and anchored on Solana. The lifecycle is visible on the record itself: received → batched → anchored.

Ingest an event

curl -X POST https://api.regentprotocol.org/v1/organizations/<org>/audit/events \
  -H "Authorization: Bearer rgnt_..." -H "content-type: application/json" \
  -d '{
    "event_id": "action-<jti>",
    "agent_id": "agent_688b10bc62aef…",
    "event_type": "action.completed",
    "payload": {"amount": "25", "currency": "USD", "authorization_jti": "…"}
  }'

• event_id — your idempotency key (≤64 chars). Re-sending the same id is safe.
• event_type — dotted, e.g. payment.authorized, action.completed.
• payload — arbitrary JSON; it is hashed (payload_hash) and stored.

Best practice: put the authorization jti into the payload — that is what ties the action to its permission when someone reconstructs the case later.

Read an event

GET /v1/organizations/<org>/audit/events/<event_id>

{
  "event_id": "action-…",
  "agent_id": "agent_688b…",
  "event_type": "action.completed",
  "payload_hash": "…",
  "status": "anchored",
  "batch_id": "…",
  "merkle_index": 3,
  "merkle_proof": ["…"],
  "received_at": "…",
  "anchored_at": "…"
}

Verify a proof

POST /v1/organizations/<org>/audit/events/<event_id>/verify
GET  /v1/organizations/<org>/audit/batches/<batch_id>

verify recomputes the event’s Merkle path against its batch root; the batch record carries the on-chain commitment. An auditor can go further and check the anchor independently against Solana — the end-to-end recipe is in Verifying on-chain. That page is the point of the whole design: the trail is checkable without trusting Regent or the operator.

On devnet, batches seal and anchor within seconds of ingestion.