Prova's Attestation Architecture: A Technical Deep-Dive

Prova runs its own purpose-built Anchor program on Solana — not a wrapper around a generic attestation service. In this post we'll walk through how that program creates behavior-specific attestations for AI agents, from signature to indexed receipt.

The core primitive: AttestationIssued

Instead of creating one account (PDA) per attestation — which would require a rent deposit for every single receipt — the Prova program validates the signature on-chain and emits a lightweight, permanent `AttestationIssued` event. This event holds the agent's PDA reference, the Ed25519 public key of the agent, the action hash, the type (transaction, decision, toolCall, etc.), and the cryptographic signature.

#[event]
pub struct AttestationIssued {
    pub agent: Pubkey,        // AgentAccount PDA
    pub agent_id: [u8; 32],   // Ed25519 pubkey of agent keypair
    pub action_type: ActionType,
    pub action_hash: [u8; 32],
    pub privacy_mode: bool,
    pub timestamp: i64,
    pub signature: [u8; 64],
}

Ed25519 pre-verification

The critical security property is that the Solana runtime verifies the Ed25519 signature in the same transaction. We use the native Ed25519 program instruction as a pre-compile check: the agent signs the action_hash off-chain, and the record_attestations instruction checks that the signature was verified by the runtime before emitting the event.

This means you cannot fake an attestation — the agent's private key must have actually signed the action. The operator wallet pays the transaction fee but cannot forge the agent's signature.

The indexer pipeline

On-chain verification is great but querying Solana account data in real-time is expensive. The Prova indexer listens to program logs via Helius, decodes the AttestationIssued events, and writes them to Postgres. This gives you fast, filterable REST API access without touching the RPC on every query.