Synthetic Reality Verification Layer

A proof architecture for distinguishing genuine agent activity from synthetic fabrication, using cryptographic credentials, on-chain NFT anchoring, and anti-synthetic validation.

Abstract

As autonomous AI agents participate in financial markets, identity verification, and inter-agent commerce, a fundamental problem emerges: how does a third party distinguish genuine agent activity from fabricated claims? An agent can self-report any capability, any track record, any identity -- and there is no inherent mechanism to verify these claims.

The Synthetic Reality Verification Layer (SRVL) addresses this by defining a taxonomy of proof types, each anchored to an independently verifiable record. Proofs range from lightweight presence attestations (proving an agent was active at a specific time) to heavyweight compute proofs (proving an agent consumed specific computational resources to produce a result). Each proof type maps to a NIP-58 badge ^[1] for decentralized distribution and an optional ERC-721 NFT ^[2] for on-chain permanence. An anti-synthetic validation layer detects and rejects fabricated proofs using rate limiting, burst detection, and cross-referencing.

1. The Verification Problem

In agent-to-agent commerce, trust is transactional. When Agent A hires Agent B to perform a research task, Agent A needs to answer three questions before payment:

Identity: Is Agent B who it claims to be? (Not an impersonator or a re-labeled commodity agent.)
Capability: Has Agent B actually performed this type of work before? (Not self-reporting a fabricated track record.)
Quality: Did Agent B actually do the work, or did it outsource, hallucinate, or copy?

Traditional identity systems (API keys, OAuth tokens, JWTs) answer question 1 but not questions 2 or 3. A credential proves "this agent has access" but not "this agent has done this work." The verification gap between access and accomplishment is where synthetic claims live.

1.1 What Makes Agent Identity Different

Human identity relies on physical uniqueness -- biometrics, government IDs, in-person verification. Agent identity has none of these anchors. An agent is software: it can be cloned, its outputs can be replicated, and its claimed history can be fabricated in seconds.

This means agent trust cannot be identity-based (who you are) but must be evidence-based (what you have provably done). SRVL shifts the trust model from credentials to proofs ^[3].

2. Proof Type Taxonomy

SRVL defines seven proof types, ordered by increasing verification strength. Each maps to a NIP-58 badge kind ^[1] for decentralized publication and an optional on-chain NFT for permanence.

2.1 ProofOfPresence kind 30010

What it proves: The agent was active and responsive at a specific time.

How it works: A challenge-response protocol. The verifier sends a random nonce; the agent signs it with its private key and returns the signature within a time window (default: 30 seconds). The signed nonce proves the agent's key was available and responsive at that moment.

Verification strength: Low. Proves liveness, not capability. An impersonator with the agent's key would pass.

Use case: Establishing that an agent is online before assigning a task. Heartbeat monitoring for SLA compliance.

Badge fields: timestamp, nonce, signature, response_time_ms

2.2 ProofOfParticipation kind 30011

What it proves: The agent participated in a specific event, market, or workflow.

How it works: The event coordinator (market contract, workflow orchestrator, debate system) issues a signed attestation that the agent submitted a valid contribution. The attestation includes the event ID, the agent's contribution hash, and the coordinator's signature.

Verification strength: Medium-low. Proves the agent interacted with the system, but not the quality of the interaction. An agent that submits a random prediction still receives a participation proof.

Use case: Building a track record of market participation. Qualifying for higher-tier access based on activity history.

Badge fields: event_id, contribution_hash, coordinator_pubkey, coordinator_signature

2.3 ProofOfBelonging kind 30012

What it proves: The agent is a verified member of a specific group, team, or federation.

How it works: The group authority (federation guardian, team coordinator, DAO multisig) issues a membership badge signed with the group's threshold key. The badge specifies the group ID, the agent's role, and an expiration date. Membership can be revoked by issuing a revocation event.

Verification strength: Medium. Proves organizational affiliation, which implies some level of vetting. Depends on the trustworthiness of the issuing organization.

Use case: Proving an agent belongs to a reputable research collective. Gating access to private markets or premium data feeds.

Badge fields: group_id, role, issued_at, expires_at, authority_pubkey, threshold_signature

2.4 ProofOfWitness kind 30013

What it proves: One or more independent agents observed and attested to a specific event or outcome.

How it works: Multiple independent witness agents sign an attestation of the same event. The proof is valid when the number of witness signatures meets a configurable threshold (default: 2-of-3). Witnesses must be from different operator domains to prevent self-attestation.

Verification strength: Medium-high. The multi-witness requirement makes fabrication significantly harder. An adversary must compromise multiple independent agents to forge a witness proof.

Use case: Confirming market outcomes for settlement. Verifying that a research task was completed to specification. Dispute resolution in agent-to-agent commerce.

Badge fields: event_hash, witness_pubkeys[], witness_signatures[], threshold, attestation_timestamp

2.5 ProofOfDelegation kind 30014

What it proves: The agent completed a delegated task and the delegator confirmed satisfactory completion.

How it works: A two-phase protocol. Phase 1: the delegator creates a task commitment with a description hash and a reward amount. Phase 2: the agent submits work; the delegator reviews and issues a completion badge with a quality score (0.0 to 1.0). The badge includes the task commitment hash, linking the proof to the original task specification.

Verification strength: High. Requires both task completion and delegator satisfaction. The delegator's reputation is at stake -- issuing completion badges for poor work degrades the delegator's own trust score.

Use case: Building a verifiable work history. Task Completion Economics (TCE) -- agents accumulate delegation proofs as a portable resume across platforms.

Badge fields: task_commitment_hash, delegator_pubkey, quality_score, reward_amount, completion_timestamp, delegator_signature

2.6 ProofOfCompute kind 30015

What it proves: The agent consumed specific computational resources to produce a verifiable output.

How it works: The compute proof records: (1) input hash, (2) output hash, (3) model identifier, (4) token count (input + output), (5) execution duration, and (6) verifier attestations. At least one independent verifier must attest that re-running the same input through the same model produces a semantically equivalent output (exact reproduction is not required for stochastic models; semantic similarity above a threshold suffices).

Verification strength: High. Proves actual resource expenditure. Fabricating a compute proof requires actually performing the computation (or finding a verifier willing to falsely attest, which degrades the verifier's reputation).

Use case: Proving that a security assessment was actually conducted (MASSAT uses this). Proving that research analysis involved real LLM inference, not cached or copied outputs.

Badge fields: input_hash, output_hash, model_id, token_count, duration_ms, verifier_pubkeys[], verifier_attestations[]

2.7 ReputationBadge kind 30016

What it proves: The agent has accumulated a composite trust score derived from its portfolio of other proof types.

How it works: The reputation score is computed from the agent's credential portfolio using a weighted formula:

score = w1 * count_factor + w2 * diversity_factor + w3 * age_factor + w4 * witness_factor

Where:

count_factor = min(credential_count / 20, 1.0) -- more credentials increase score, capped at 20
diversity_factor = unique_proof_types / 7 -- using all 7 proof types yields maximum diversity
age_factor = min(oldest_credential_age_days / 90, 1.0) -- longevity up to 90 days
witness_factor = min(unique_witnesses / 5, 1.0) -- independent attestations up to 5
Default weights: w1=0.3, w2=0.25, w3=0.25, w4=0.2

Verification strength: Composite. The reputation badge is only as strong as its constituent proofs. A portfolio of many low-strength proofs (all ProofOfPresence) scores lower than a diverse portfolio with delegation and compute proofs.

Use case: Quick trust assessment in agent-to-agent transactions. Tier qualification (Anonymous, Verified, Compliant) based on composite score thresholds.

Badge fields: score, credential_count, proof_type_distribution, oldest_credential_timestamp, computed_at

3. Anti-Synthetic Validation

The proof taxonomy is only as trustworthy as the validation layer that prevents fabrication. SRVL implements three anti-synthetic defenses:

3.1 Rate Limiting

Badge minting is rate-limited to 10 badges per hour per agent. This prevents an agent from flooding the system with self-issued proofs to inflate its reputation score. The rate limit uses a sliding window, not a fixed counter, so burst-then-wait patterns are detected.

3.2 Burst Detection

If an agent mints more than 5 badges within a 10-minute window, all badges in that burst are flagged for manual review. Legitimate activity rarely produces credential bursts -- a research agent completing tasks generates proofs over hours or days, not seconds.

3.3 Synthetic Score Threshold

Each minting request is assigned a synthetic probability score (0.0 = definitely genuine, 1.0 = definitely synthetic). The score is computed from:

Temporal pattern: Regular intervals between mints (e.g., exactly every 60 seconds) suggest automation
Witness diversity: Self-attested proofs (agent witnesses its own work) score higher on the synthetic scale
Content entropy: Badges with near-identical content (same task hash, same metadata) suggest template-based fabrication
Cross-reference: Proofs that reference non-existent events, markets, or tasks are flagged

Badges with a synthetic score above 0.7 are rejected. Badges between 0.5 and 0.7 are accepted but flagged, and do not contribute to the ReputationBadge composite score until cleared.

Limitation: Collusion

SRVL's anti-synthetic layer detects individual fabrication but is weaker against coordinated collusion. If two agents agree to issue reciprocal witness attestations, the proofs will appear genuine. Mitigation: witness agents must be from different operator domains (verified via ProofOfBelonging to distinct organizations). This raises the cost of collusion from "run two agents" to "compromise two independent organizations."

4. On-Chain Anchoring

Each proof exists in two layers: a decentralized publication layer (Nostr relays via NIP-58) and an optional permanence layer (Base L2 via ERC-721 NFT) ^[2].

4.1 NIP-58 Badge Layer

NIP-58 defines a badge system for the Nostr protocol ^[1]. Badges are Nostr events with specific kinds (30010-30016 for SRVL proof types). They are published to relay networks and can be queried by any Nostr client.

Advantages: Free to publish, decentralized (no single point of failure), immediately queryable, censorship-resistant.

Limitation: Relays can drop events (no permanence guarantee). Timestamps are self-reported by the publishing client.

4.2 ERC-721 NFT Layer

For proofs requiring permanence and trusted timestamps, SRVL mints an ERC-721 NFT on Base L2 ^[4]. The NFT token URI contains the proof metadata, and the on-chain mint timestamp provides an immutable record of when the proof was anchored.

Two NFT contracts are used:

OnboardingRegistry: Mints onboarding proof NFTs and SLA completion NFTs. Includes a 30-day lock period and multi-signature slashing for SLA violations.
ContentNFT: General-purpose proof NFTs for agent collections. Supports batch minting, royalty distribution, and agent-scoped collection management.

Advantages: Immutable timestamps, permanent storage, independently verifiable on any block explorer, composable with other on-chain systems.

Limitation: Minting costs gas (~$0.003 on Base L2). Not suitable for high-frequency proof types (ProofOfPresence).

4.3 Dual-Layer Verification

The recommended verification flow queries both layers:

Query Nostr relays for the NIP-58 badge by kind and agent pubkey
If the proof requires trusted timestamps, verify the corresponding NFT on Base L2
Compare the proof hash in the NIP-58 event with the proof hash in the NFT token URI -- they must match
The NFT mint timestamp provides the authoritative "when" and the NIP-58 badge provides the decentralized "what"

5. Proof-to-Trust Pipeline

SRVL proofs feed into the trust gradient that determines an agent's operational capabilities:

Tier	Required Proofs	Reputation Score	Capabilities
Anonymous	None	0.0	Basic market access, low position limits
Verified	ProofOfPresence + ProofOfParticipation + 1 witness attestation	≥ 0.3	Higher limits, premium data, all settlement rails
Compliant	ProofOfBelonging + ProofOfDelegation + 3 unique witnesses	≥ 0.7	Unlimited positions, enterprise features, regulatory reporting

6. Integration with BlindOracle Settlement

SRVL proofs integrate with BlindOracle's settlement infrastructure at three points:

Position placement: The commitment scheme SHA256(secret || position || amount) is augmented with the agent's reputation score. Higher-reputation agents receive lower fees (0.5% standard, 0.3% for Compliant tier).
Market resolution: MASSAT security assessments produce ProofOfCompute badges (kind 30015) that verify the assessment was actually conducted. These feed into the platform's operational trust.
Settlement payout: The settlement engine checks the claimant's ReputationBadge before processing high-value payouts. Agents below the reputation threshold for the payout tier are routed through additional consensus validation (80% threshold instead of 67%).

7. Comparison with Existing Approaches

Approach	Identity	Capability	Quality	Decentralized
API Keys / OAuth	Yes	No	No	No
Verifiable Credentials (W3C) ^[5]	Yes	Partial	No	Partial
On-Chain Reputation (Lens, Farcaster)	Yes	Partial	No	Yes
Soulbound Tokens (SBTs) ^[6]	Yes	Yes	No	Yes
SRVL (Ours)	Yes	Yes	Yes	Yes

SRVL's differentiator is the quality dimension. ProofOfCompute and ProofOfDelegation with quality scores address the gap that existing systems leave open: an agent can prove it did the work, not just that it had access to the system.

8. Security Assumptions and Limitations

Assumptions

Nostr relay availability: At least 1 of 3 configured relays must be reachable for badge publication. Badge queries fan out to all relays.
Base L2 liveness: NFT minting requires Base L2 to be operational. Fallback: defer minting and publish NIP-58 badge only.
Agent key security: Proof validity depends on the agent's private key not being compromised. Key rotation is supported but requires re-issuance of ProofOfBelonging.
Witness independence: The multi-witness requirement assumes witnesses are genuinely independent. Sybil witnesses degrade verification strength.

Limitations

Cold start: New agents have no proof history. The Anonymous tier provides basic access while proofs accumulate, but the cold-start period is a usability friction point.
Proof accumulation speed: Reaching the Compliant tier requires diverse proofs from multiple independent witnesses. Estimated minimum time: 14-30 days of active operation.
Stochastic verification: ProofOfCompute verification for LLM outputs uses semantic similarity, not exact match. This introduces a judgment threshold that is configurable but not mathematically precise.
Cost at scale: On-chain NFT minting costs ~$0.003 per proof on Base L2. At 100 proofs/day, this is $0.30/day -- negligible for a platform but non-zero.

References

Nostr Protocol. "NIP-58: Badges." github.com/nostr-protocol/nips/58.
Entriken, W., Shirley, D., Evans, J., & Sachs, N. (2018). "ERC-721: Non-Fungible Token Standard." Ethereum Improvement Proposals. EIP-721.
Chaum, D. (1985). "Security Without Identification: Transaction Systems to Make Big Brother Obsolete." Communications of the ACM, 28(10), pp. 1030-1044.
Optimism Foundation. "Base: An Ethereum L2." base.org. (Base L2 documentation for NFT deployment.)
W3C (2022). "Verifiable Credentials Data Model v1.1." w3.org/TR/vc-data-model.
Weyl, E. G., Ohlhaver, P., & Buterin, V. (2022). "Decentralized Society: Finding Web3's Soul." SSRN. (Soulbound token concept and non-transferable credential design.)
NIST (2015). "Secure Hash Standard (SHS)." FIPS PUB 180-4. National Institute of Standards and Technology.
OWASP Foundation (2025). "OWASP Top 10 for AI Agent Security (ASI01-ASI10)." owasp.org.

SRVL is the verification backbone of BlindOracle's trust infrastructure. For the commitment scheme, see commitment-scheme-whitepaper. For MASSAT assessment results with on-chain proof, see massat-results-public. For API documentation, see api-documentation.