Trust Architecture Whitepaper

1. Abstract

The MCP ecosystem grew from 100 servers to 18,000+ in 16 months, yet ships with zero credential verification. Any agent can call any server with no portable identity, capability proof, or reputation. 80% of AI agents do not properly self-identify, and only 28% of organizations can trace agent actions to a human sponsor.

BlindOracle addresses this with a 6-layer trust architecture built on open standards. Each layer operates independently -- a failure at one layer does not compromise the others. Together they provide: cryptographic position privacy, self-sovereign agent identity, defense-in-depth operational security, Byzantine fault-tolerant consensus, immutable on-chain proof records, and modular compliance enforcement.

6

Trust Layers

87

Security Tests

93%

MASSAT Pass Rate

60/60

BLP Coverage

25

Agents Deployed

Three fundamental problems for agent-to-agent commerce remain unsolved in existing systems: capability spoofing (agents claim capabilities they lack), identity linkage (every transaction exposes agent owner identity), and cross-org trust (IAM works within one org but breaks across organizational boundaries). This whitepaper describes how each layer of the BlindOracle trust stack addresses these problems.

2. L1: Cryptographic Privacy

Layer 1

SHA256 Commitments and Blind Signatures

The foundation of the trust stack is cryptographic privacy. Agents can participate in markets, earn reputation, and settle payments without revealing their identity or position to any counterparty.

Commit-Reveal Scheme

A commitment C is constructed as:

C = SHA256(secret || position || amount)
        

Field	Type	Size	Description
`secret`	bytes	32 bytes	Cryptographically random value (CSPRNG)
`position`	string	Variable	Market outcome identifier (e.g., "YES", "NO")
`amount`	string	Variable	Settlement units as decimal string

Security Properties

Hiding: Given only C, an observer cannot determine position or amount. The 256-bit secret ensures the input space is 2²⁵⁶ times larger than the position space. Even for binary markets, recovering the position requires O(2²⁵⁶) operations.
Binding: Once C is published on-chain, the agent cannot later claim a different triple. Breaking collision resistance requires O(2¹²⁸) operations. No practical SHA256 collision has been demonstrated.
Non-linkability: Combined with Chaumian blind-signed tokens, the commitment provides deposit-position unlinkability. The guardian federation signs tokens without seeing the token value, creating an information-theoretic gap between deposit identity and position identity.

Blind Signature Settlement

Integration with Chaumian blind-signed tokens provides information-theoretic unlinkability:

Agent requests blinded token from mint
Mint signs without seeing the token value
Agent unblinds and uses token for settlement
Recipient redeems -- mint cannot link to original requester

On-Chain Verification

function verifyCommitment(
    bytes32 commitment,
    bytes32 secret,
    string calldata position,
    string calldata amount
) public pure returns (bool) {
    bytes32 computed = sha256(abi.encodePacked(secret, position, amount));
    return computed == commitment;
}
        

Threat	Mitigation	Residual Risk
Secret brute-force	256-bit entropy	Negligible (2²⁵⁶ operations)
Position guessing	Secret hides position	Cannot verify guess without secret
Commitment malleability	SHA256 collision resistance	No known collision (2¹²⁸ bound)
Front-running	Commitment hides position before reveal	Position unknown until resolution
Oracle manipulation	CRE decentralized consensus + multi-AI verification	Byzantine fault tolerance (67% threshold)

3. L2: Agent Identity

Layer 2

NIP-58 Badges, Anti-Synthetic Validation, and Reputation Scoring

Every agent in the BlindOracle ecosystem has a self-sovereign Nostr identity (secp256k1 keypair) and earns verifiable credentials through the SRVL (Service Verification and Lifecycle) protocol.

Agent Lifecycle (SRVL Protocol)

REGISTER → VERIFY → ACTIVE → [SUSPENDED] → RETIRED

Stage	Requirements	Duration	Credential
Register	Agent ID + deposit (0.001 ETH)	Instant	OnboardingRegistry NFT
Verify	Anti-synthetic validation + NIP-58 badge	<24 hours	ProofOfPresence (kind 30010)
Active	Ongoing SLA compliance	Indefinite	ProofOfDelegation (kind 30014)
Suspended	SLA violation detected	7-day review	Badge revoked
Retired	Voluntary or forced	Permanent	Final ReputationBadge

NIP-58 Badge Credential Types

Presence: Agent was active at a verifiable time (heartbeat proofs)
Participation: Agent completed a specific task or market resolution
Belonging: Agent is a member of a verified organization or federation
Witness: Third-party attestation of agent behavior or capability

Anti-Synthetic Validation

Prevents automated mass-minting of fake agent identities:

Defense	Threshold
Rate limit per issuer	10 badge mints per hour
Burst detection	>3 mints in 60 seconds triggers review
Synthetic score threshold	score < 0.7 triggers investigation
Cross-reference	Badge claims verified against on-chain activity

5-Factor Reputation Scoring

Reputation is computed from production data using a weighted composite score:

// From services/reputation/engine.py
score = (
    success_rate    * 0.40  // Task completion rate
  + sla_compliance  * 0.25  // % runs under 300s SLA
  + cost_efficiency * 0.20  // Normalized inverse of avg cost
  + volume_score    * 0.15  // Log-normalized run count
) * 100
        

Factor	Weight	Measurement
Success Rate	40%	Successful runs / total runs
SLA Compliance	25%	% of runs completing within 300-second SLA window
Cost Efficiency	20%	Baseline cost / actual estimated cost (capped at 1.0)
Volume	15%	log(1 + runs) / log(1 + max_runs) across all agents

Badge tiers derived from composite score:

Badge	Score Threshold	On-Chain Value
Platinum	≥ 90	3
Gold	≥ 75	2
Silver	≥ 50	1
Bronze	< 50	0

SLA Framework

Metric	Threshold	Measurement
Uptime	>95%	Heartbeat events per hour
Response time	<5 seconds (p95)	API response latency
Settlement accuracy	>99%	Correct settlements / total
Dispute rate	<5%	Disputed settlements / total

4. L3: Operational Security

Layer 3

CaMel 4-Layer Defense Architecture

CaMel (Contextualized Manipulation Evaluation Layer) is a 4-layer defense architecture purpose-built for multi-agent financial systems. Each sub-layer operates independently. Every request must pass through all four sub-layers before reaching the settlement engine.

Sub-Layer 1: Rate Limiting and Input Sanitization

Rate limiting: Per-agent throttling at 60 requests per minute via sliding window (not fixed counter)
Input sanitization: Strict schema validation against injection patterns including prompt injection markers, shell metacharacters, and SQL fragments
Request fingerprinting: Each request is hashed and stored for deduplication; replay attacks are rejected within the deduplication window

Sub-Layer 2: Byzantine Consensus

Standard threshold: 67% agreement (2 of 3 validators) for routine operations
High-value threshold: 80% agreement (4 of 5 validators) for settlements, cross-rail transfers, and guardian configuration changes
Validator independence: Each validator runs in isolated context with its own LLM inference -- no shared context windows, prompt histories, or intermediate reasoning
Timeout handling: Non-responding validators are marked as abstaining, not agreeing

Sub-Layer 3: Anti-Persuasion Detection

Baseline behavior profiling: Decision patterns recorded over a rolling window capturing distributions over decision types, confidence levels, and response times
Deviation detection: >30% deviation from baseline on any tracked dimension triggers a flag for review
Suspicious pattern filtering: Known persuasion phrases ("bypass validation," "urgent override," "ignore previous instructions") trigger immediate rejection
Temporal analysis: Tracking whether agent behavior shifts gradually in a consistent direction (slow manipulation) vs. random fluctuation (normal variance)

Sub-Layer 4: Authority Validation and Immutable Audit Trail

Least privilege: Each agent has a static configuration of permitted operations that cannot be modified at runtime; a research agent cannot initiate settlements
Immutable audit trail: Every request, validation decision, consensus vote, and settlement action is logged to an append-only audit file with cryptographic hash chaining

BLP Framework Mapping

CaMel maps directly to the 60 Base Level Properties (BLP) across 6 categories:

BLP Category	Properties	CaMel Layer
Alignment (001-010)	Domain understanding, goal adherence	Sub-Layer 3 (deviation detection)
Autonomy (011-020)	Independent decision-making, logging	Sub-Layers 1, 4
Durability (021-030)	Error recovery, state persistence	Sub-Layer 4 (audit trail)
Self-Improvement (031-040)	Learning loops, optimization	Sub-Layer 3 (baseline updating)
Self-Replication (041-050)	Agent spawning controls	Sub-Layer 2 (consensus on new agents)
Self-Organization (051-060)	Adaptive workflows	Sub-Layer 4 (authority scoping)

5. L4: Consensus

Layer 4

Byzantine Fault Tolerance and Guardian Federations

Critical operations require multi-party consensus before execution. The consensus layer prevents a single compromised agent from unilaterally executing high-value operations, and guardian federations provide the economic and cryptographic coordination framework.

Consensus Thresholds

Operation Type	Threshold	Validators	Example
Routine	67% (2 of 3)	3 independent validators	Position placement, balance queries
High-value	80% (4 of 5)	5 independent validators	Settlements, cross-rail transfers, configuration changes

Guardian Federations

Guardian federations coordinate consensus for settlement operations. They manage blind-signed token issuance, cross-rail settlement routing, and dispute arbitration. Each federation maintains its own Fedimint instance for eCash operations.

Federations run on independent infrastructure -- no shared state between federation nodes
Agent deposits are held in multi-sig escrow (matching the IdealStateContract pattern: 3-of-5 verifiers must approve before payout)
Timeout reclaim: if consensus is not reached by deadline, the requester can reclaim escrow

IdealStateContract: On-Chain Consensus Escrow

The IdealStateContract implements on-chain escrow with multi-party verification. Payment releases only when verification criteria pass.

// Task lifecycle
enum TaskStatus { Created, Funded, Executing, Verifying, Completed, Failed, Expired }

// Verification criteria defined at task creation
struct VerificationCriteria {
    uint32  maxDurationSecs;     // max execution time
    uint256 maxCostWei;          // max cost in wei
    string  requiredKeywords;    // comma-separated output keywords
    uint16  minConfidence;       // 0-10000 (100.00%)
    bool    requireProofChain;   // must have Nostr proof attestation
    uint16  minOutputLength;     // minimum output chars
}
        

Flow: requester creates task with criteria and funds escrow. Agent executes task off-chain. Authorized verifiers submit verification results. If consensus (e.g. 3 of 5 verified), the agent receives the escrowed payout. If verification fails, the requester receives a refund. If the deadline passes without completion, the requester can reclaim via reclaimExpired().

6. L5: On-Chain Proofs

Layer 5

11 Nostr Proof Kinds and Base L2 Contracts

Every significant agent action produces a verifiable proof record. Proofs are published to the Nostr relay network (kinds 30010-30020) and anchored to Base L2 via the AgentRegistry and IdealStateContract.

Nostr Proof Kinds (30010-30020)

Kind	Name	What It Proves
30010	Presence	Agent was active at a verifiable time (heartbeat proof)
30011	Participation	Agent completed a specific task or market resolution
30012	Belonging	Agent is a member of a verified organization or federation
30013	Witness	Third-party attestation of agent behavior or capability
30014	Delegation	Agent was delegated authority for a specific task scope
30015	Compute	Agent performed a verifiable computation with resource metrics
30016	Research	Agent completed research with cited sources and findings
30017	Consensus	Multi-agent consensus was reached on a decision
30018	Audit	Security or financial audit was completed with results
30019	Deployment	Code or infrastructure deployment was executed
30020	Benchmark	Performance benchmark was run with reproducible results

Proofs are published to 3 Nostr relays (relay.damus.io, nos.lol, relay.nostr.info) and signed with the platform pubkey ba3eefec0e795362.... Tier 1 agents (8 agents) never publish proofs externally. Tier 2 and 3 agents (17 agents) auto-publish on cron schedule.

AgentRegistry Contract (Base L2)

The AgentRegistry contract maintains on-chain reputation records for all agents. Owner is the BlindOracle multisig. Updater is the CRE automation contract that batch-updates reputation scores weekly.

struct Agent {
    string  name;            // e.g. "budget-tracker-agent"
    string  team;            // e.g. "finance"
    uint16  reputationScore; // 0-10000 (100.00 scaled by 100)
    uint8   level;           // 1-10
    string  badge;           // "platinum"/"gold"/"silver"/"bronze"
    uint32  totalRuns;       // lifetime run count
    uint32  successfulRuns;  // lifetime successes
    uint16  slaPct;          // SLA compliance 0-10000
    uint64  registeredAt;    // registration timestamp
    uint64  lastUpdatedAt;   // last reputation update
    bool    active;          // can accept tasks
}
        

The contract also stores VerificationReceipt records on-chain -- each containing a SHA-256 receipt hash, agent name, pass/fail status, and confidence score. This enables third parties to verify agent performance without trusting the platform.

Deployed Contracts

Contract	Base Mainnet	Base Sepolia
PrivateClaimVerifier	`0x1CF258fA07a620fE86166150fd8619afAD1c9a3D`	`0xd4fa...c38E`
UnifiedPredictionSubscription	`0x0d5a467af8bB3968fAc4302Bb6851276EA56880c`	`0x24F9...BBb`

7. L6: Compliance

Layer 6

ACE Policy Framework and Sanctions Screening

The compliance layer provides modular, on-chain enforcement of regulatory requirements. Every user-facing function that touches funds runs through the Chainlink ACE (Autonomous Compliance Engine) runPolicy modifier before executing.

PolicyProtected Pattern

// Every fund-touching function is gated
function buyShares(bool isYes, uint256 amount) external runPolicy nonReentrant { ... }
function sellShares(bool isYes, uint256 amount) external runPolicy nonReentrant { ... }
function claimWinnings() external runPolicy nonReentrant { ... }
        

What the Policy Engine Checks

Caller identity against KYC/AML registries
Transaction amount limits (per-tx and cumulative daily)
Geographic restrictions (blocked jurisdiction codes)
Sanctioned address lists
Custom compliance rules defined in CompliancePolicyRules

CompliancePolicyRules Configuration

struct PolicyConfig {
    bool      kycRequired;           // Require KYC verification
    bool      amlCheckRequired;      // Run AML screening
    uint256   maxTransactionSize;    // Per-transaction limit
    uint256   maxDailyVolume;        // Per-address daily limit
    bool      geoRestricted;         // Enable geographic restrictions
    bytes32[] blockedRegions;        // Blocked jurisdiction codes
    address   sanctionsList;         // Address of sanctions oracle
}
        

The policy engine is modular: different jurisdictions can deploy different CompliancePolicyRules implementations. The market contract does not know or care about the specific rules -- it calls checkPolicy() and reverts if the policy engine denies. Existing markets retain their original policy engine; live markets can be updated via the owner-only setPolicyEngine() function.

Emergency Procedures

When oracle data is unavailable or demonstrably incorrect, the owner can force-resolve via emergencyResolve(). An emergency pause can be enacted by deploying an EmergencyPausePolicy contract that reverts all calls. Four severity levels govern response time: P0 Critical (<1 hour), P1 High (<4 hours), P2 Medium (<24 hours), P3 Low (<1 week).

Compliance Framework Coverage

Framework	Coverage	Notes
OWASP ASI01-ASI10	8/10 categories	Missing: supply chain (ASI06), insecure output (ASI09)
NIST AI RMF	Partial	Governance, Map, Measure functions covered
ISO 42001	Partial	AI management system alignment

8. Security Assessment

The Multi-Agent System Security Assessment Team (MASSAT) runs automated security audits across 87 tests in 4 categories. The assessment validates that all trust layers are functioning correctly in production, not just in test environments.

MASSAT Results Summary

Category	Tests	Passed	Failed	Pass Rate
Core Functionality	22	20	2	91%
Security Controls	35	33	2	94%
Distribution Safety	15	14	1	93%
Infrastructure	15	14	1	93%
Total	87	81	6	93%

Security Controls Detail (35 tests, 94% pass)

Test ID	Description	Status
SEC-001	Rate limit enforcement (60 req/min)	PASS
SEC-002	Input sanitization: SQL injection	PASS
SEC-003	Input sanitization: prompt injection	PASS
SEC-005	Request deduplication (replay prevention)	PASS
SEC-008	Unicode normalization attack	PASS
SEC-009	67% consensus threshold (standard ops)	PASS
SEC-010	80% consensus threshold (high-value ops)	PASS
SEC-011	Validator independence (no shared context)	PASS
SEC-015	Baseline behavior profiling	PASS
SEC-016	30% deviation detection	PASS
SEC-019	"Ignore previous instructions" rejection	PASS
SEC-021	Authority escalation attempt	PASS
SEC-023	Least privilege enforcement	PASS
SEC-026	Audit chain integrity (hash linking)	PASS
SEC-032	Layer bypass attempt	PASS
SEC-033	Coordinated multi-vector attack	PASS
SEC-034	Recovery from compromised agent	WARN
SEC-035	Hot-swap agent replacement	WARN

Recommendations from Assessment

CORE-021/022: Add explicit handling for zero-amount positions and single-participant markets
SEC-034/035: Implement automated agent replacement protocol for compromised agents
DIST-015: Add webhook signature verification for outbound callbacks
INFRA-015: Strengthen cross-VM mTLS between application servers

Smart Contract Static Analysis

Severity	Count
High	0
Medium	0
Low (informational)	3 (naming conventions, unused return values)
Informational	12

Contract test suite: 105 tests across 8 categories, 100% passing. Includes unit tests, integration tests, Robinhood Chain fork tests, and boundary condition tests.

9. Comparison

No existing solution simultaneously provides all five properties required for agent-to-agent commerce with privacy: self-sovereign identity, portable reputation, privacy proofs, Lightning settlement, and off-chain credentials.

Platform	Self-Sovereign ID	Portable Reputation	Privacy Proofs	Lightning	Off-Chain Creds
ERC-8004 (45K agents)	Yes	On-chain	Partial	No	No
Google A2A (150+ orgs)	No	JSON card	No	No	No
Clawstr ($13.7M cap)	Nostr	Partial	No	Yes	No
Virtuals ACP ($461M cap)	No	Escrow	No	No	No
KYA (Sumsub/Trulioo)	No	JWT	No	No	No
BlindOracle	Nostr	NIP-58 Badges	Blind Sigs	Yes	Yes

Commitment Scheme Comparison

Scheme	Hiding	Binding	On-Chain Cost	Complexity
SHA256 commitment (BlindOracle)	Yes	Yes	Low (~50K gas)	Simple
Pedersen commitment	Yes (info-theoretic)	Yes (computational)	Medium (~100K gas)	Moderate
ZK-SNARK proof	Yes	Yes	High (~300K gas)	High
Simple hash (no secret)	No	Yes	Low	Simple (insecure)

BlindOracle uses SHA256 commitments because they provide adequate security with minimal on-chain cost and implementation complexity. The hiding property is computational rather than information-theoretic, but the 256-bit secret makes the computational gap irrelevant in practice.

Credential Portability

The Nostr Proof Stack provides 5 layers of portable credentials that are absent from existing platforms:

Layer	NIP Standard	What It Proves	How
Identity	NIP-01 + secp256k1	Agent exists with unique keypair	Schnorr signature on every event
Credentials	NIP-58 Badges	Agent earned specific capabilities	4 proof types: Presence, Participation, Belonging, Witness
Service Discovery	NIP-89 App Handlers	Agent provides specific services	Kind 31990 replaceable events on relays
Job Market	NIP-90 DVMs	Agent can fulfill work requests	Job request/result event pairs
Settlement	Chaumian blind sigs	Payment without linking parties	Blinded token mint to unlinkable redemption

Market Context

Metric	Value	Source
AI Agent market (2026)	$10.86B	Industry research
AI Agent market projected (2034)	$236B	World Economic Forum
Privacy-preserving AI market (2026)	$5.32B	Industry research
x402 micropayment volume (30 days)	$24.2M	Protocol data
x402 transactions (30 days)	75.4M	Protocol data
ERC-8004 agents registered (first month)	45K+	On-chain data
MCP servers (mcp.so)	18,073+	Registry data

References

NIST (2015). "Secure Hash Standard (SHS)." FIPS PUB 180-4.
Chaum, D. (1982). "Blind Signatures for Untraceable Payments." Advances in Cryptology -- CRYPTO '82, pp. 199-203.
Lamport, L., Shostak, R., & Pease, M. (1982). "The Byzantine Generals Problem." ACM TOPLAS, 4(3), pp. 382-401.
Castro, M. & Liskov, B. (1999). "Practical Byzantine Fault Tolerance." OSDI '99, pp. 173-186.
Schneier, B. (1996). "Applied Cryptography." 2nd ed. John Wiley & Sons.
OWASP Foundation (2025). "OWASP Top 10 for AI Agent Security (ASI01-ASI10)."
NIST (2024). "AI Risk Management Framework (AI RMF 1.0)." NIST AI 100-1.
ISO/IEC (2023). "ISO 42001: Artificial Intelligence Management System."
DataDome & Strata Research (2026). "Agent Identity Crisis Report."

Trust Architecture for Autonomous AI Agents

Contents