Obscurate Architecture

1. Executive Summary

The Agentic Economy is currently fragmented between intent and execution. Google’s Universal Commerce Protocol (UCP) has standardized how AI agents discover services and negotiate intent ("The Handshake"), while the x402 standard handles the payment settlement ("The Wallet").

However, connecting these two layers on public rails creates a "Transparency Tax": broadcasting a purchase intent alongside a settlement transaction exposes the agent’s strategy, solvency, and alpha to front-runners.

Obscurate is the Privacy Execution Layer for the A2A (Agent-to-Agent) economy. It functions as the cryptographic bridge that allows UCP logic to trigger x402 settlement without revealing the link between the two. By wrapping the a2a-x402 settlement flow in a Zero-Knowledge execution layer, Obscurate enables the first true Private A2A Loop: Discovery without exposure, Settlement without tracking.

2. Architectural Positioning

Obscurate is not a standalone payment standard; it is an infrastructure layer that harmonizes existing and emerging standards into a private execution environment.

2.1 The Stack

The architecture is best understood as a three-layer stack:

Transport Layer: x402 (Payment Signaling)
Role: Defines the mechanism for resource gating (HTTP 402 "Payment Required").
Function: Signals cost and destination. It tells the agent what to pay and where.
Limitation: In its native state, x402 relies on direct wallet-to-merchant transactions, creating a deterministic link between identity and consumption.
Logic Layer: UCP (Authorization & Delegation)
Role: Defines the consent model.
Function: Specifies who is authorized to act, on whose behalf, and within what constraints (e.g., "Agent B can spend up to 50 USDC on Inference API X").
Relevance: UCP abstracts permission from possession.
Execution Layer: Obscurate (Privacy Enforcement)
Role: The cryptographic enforcer.
Function: Ingests x402 requirements and UCP permissions to execute the transaction without revealing the origin of funds.
Mechanism: Uses Zero-Knowledge Proofs (ZKPs) to validate that a UCP permission exists and is funded, without linking the execution to the depositor’s history.

2.2 The A2A Bridge: Integrating x402

Authentic Agent-to-Agent commerce requires a seamless transition from Negotiation (Logic) to Settlement (Value). We leverage the industry-standard a2a-x402 binding for compatibility, while introducing a private execution layer around it.

The Standard Flow (Public)

Agent A finds a service via UCP (HTTP/402 requirement).
Service sends a payment request (Invoice).
Agent A pays on-chain via x402.

Risk: The on-chain payment is permanently linked to the UCP request. The strategy is leaked.

The Obscurate Flow (Private Wrapper)

UCP Intent: The agent negotiates the service off-chain or via encrypted transport.
The "Anonymize" Function: Instead of paying directly, the agent routes the x402 settlement through the Obscurate Shielding Contract.
Atomic Execution: The payment is verified via ZK-Proof and released to the Service Provider.

Result: The Service Provider receives the funds (x402 satisfied) without knowing the original wallet of Agent A. The execution gap is closed without compromising privacy.

3. Core Mechanics & Protocol Primitives

We have abstracted the complexity of the privacy chain into a single primitive compatible with agent frameworks (LangChain, Eliza).

The "Anonymize" function acts as a wrapper around the standard settlement triggers:

Input: A UCP-compliant invoice (x402 challenge).
Process: Shielding → Shadow ID Generation → A2A Facilitator Routing.
Output: Validated Settlement Hash (Proof of Payment).

This architecture ensures that Obscurate is not just a mixer, but a functional payment rail designed specifically for the high-frequency, automated nature of the google-agentic-commerce ecosystem.

Obscurate operates through three primary primitives: The Shield, The Anonymity Set, and The Execution Relayer.

3.1 Primitive A: The Shield (Deposit & Committal)

Entry into the Obscurate ecosystem occurs via the Shielding contract.

Commitment Scheme: Agents deposit supported assets (e.g., USDC, SOL) into the protocol. The protocol generates a cryptographic commitment representing the asset and ownership rights.
Cryptographic Specification: The Shielding process constructs a commitment $C$ derived from the asset value $v$ and a high-entropy blinding factor $r$ (randomness), hashed via the Poseidon circuit for ZK-efficiency:

$C = Poseidon(v, s, r)$

Where:

$v$ : The denomination (e.g., 100 USDC).
$s$ : The secret spending key (held by the agent).
$r$ : The blinding factor ensuring two identical deposits result in distinct on-chain hashes.

Standardization: To maximize the entropy of the anonymity set, deposits are normalized into fixed denominations $V$ .

Output: The depositor receives a Private Note — a bearer instrument containing the secret key required to prove ownership of the commitment in the Merkle tree.

3.2 Primitive B: The Anonymity Set (State)

The core privacy guarantee is derived from the Obscurate Privacy Pool.

Topology: A Merkle tree structure where leaves represent unspent commitments $C$ .
Set Membership: An agent proves membership in the set (i.e., "I own a leaf in this tree") without revealing the specific index of the leaf.
Nullifiers: To prevent double-spending, every spend generates a unique deterministic Nullifier derived from the private note. The protocol tracks used nullifiers to reject replay attacks while maintaining zero-knowledge of the note's identity.

Nullifier Derivation: To prevent double-spending without revealing $s$ , the protocol derives a deterministic Nullifier $N$ :

$N = Poseidon(s)$

3.3 Primitive C: The Execution Relayer (Action)

Obscurate differs from mixer architectures by enabling direct execution rather than just withdrawal.

Proof Generation: The agent constructs a ZK-SNARK locally. The circuit proves:

Membership: The agent holds a valid, unspent note in the Merkle tree.
Consent: The execution adheres to a specific UCP policy.
Solvency: The note covers the payment amount + relayer fees.

The Packet: The proof, nullifier, and encrypted payload (the API request) are wrapped in an Obscurate Protocol Packet.

Table 1: UCP Wire Packet Specification

Field	Type	Size (Bytes)	Description
`proto_ver`	`uint8`	1	Protocol version (current: 0x01).
`target_addr`	`bytes32`	32	The destination address (Service/Contract).
`relayer_fee`	`uint64`	8	The gas reimbursement offered to the Relayer.
`nullifier`	`bytes32`	32	The unique hash preventing replay attacks.
`zk_proof`	`Groth16`	128	The compressed zero-knowledge proof (π).
`payload_hash`	`bytes32`	32	Integrity check of the executed instruction.
`policy_root`	`bytes32`	32	(Optional) Merkle root of the compliance policy.

Gas Abstraction: The packet is broadcast to a Relayer Network. Relayers validate the proof and submit the transaction.
Economic Flow: The Relayer pays network gas (SOL). The Relayer is reimbursed in the shielded asset (USDC) atomically within the transaction. The agent requires no native gas tokens.

The Closed-Loop Lifecycle: Unlike traditional privacy tools where funds must eventually exit to a clean wallet to be useful, Obscurate allows for a complete economic lifecycle within the shielded pool. An autonomous agent can be instantiated, trade assets, pay for compute, generate revenue, and eventually decommission itself — all without its capital ever leaving the Obscurate execution environment.

While payments are the immediate utility, Obscurate is architected to support the complex delegation patterns required by autonomous systems. Obscurate implements UCP as a reference execution model, not as a finalized standard.

4.1 Delegated Execution

An autonomous agent (Master) typically spins up sub-agents (Workers) for specific tasks. The Master should not need to fund a hot wallet for every Worker, nor should it give Workers unlimited access to the treasury.

UCP Implementation: The Master creates a UCP policy: "Key Pair B (Worker) is authorized to spend up to 100 USDC from Note A, but only for interaction with Contract Z."
Obscurate Enforcement: The Worker generates a proof satisfying this policy. Obscurate validates the delegation without revealing the link between Master and Worker.

4.2 Scoped Permissions

Privacy is often binary in legacy systems. Obscurate, leveraging UCP, allows for granular, scoped permissions.

Time-Bound: Funds can be valid only within a specific block range.
Rate-Limited: A note can be configured to allow only $X spend per hour.
Whitelisted Targets: A note can be restricted to interact only with specific verified contracts or payment addresses.

4.3 View Keys & Auditability

Obscurate adheres to the principle of "Privacy by Default, Transparency by Consent."

View Keys: Every note has an associated View Key. This key allows the holder to decrypt the transaction history of that specific note.
Use Case: An agent can share its View Key with an auditor, compliance officer, or DAO to prove it is operating within its mandate, without making its history public to the entire network.

5. Security & Compliance Interface

Obscurate rejects the concept of global surveillance but acknowledges the need for compliance interfaces in regulated environments.

5.1 Modular Privacy

The protocol is designed to support modular proof systems. While the reference implementation utilizes Groth16 with Poseidon hashing for efficiency, the architecture allows for pluggable verification keys to support upgraded schemes or specific compliance circuits.

5.2 Sovereign Compliance Interface

Obscurate architecture rejects protocol-level censorship but acknowledges the necessity of regulatory alignment for enterprise adoption. We implement Client-Side Compliance Hooks:

Relayer Sovereignty: Relayers are independent operators. The protocol provides them with cryptographic primitives to define their own risk ingress policies (e.g., a US-based Relayer may choose to reject proofs from OFAC-sanctioned addresses via a ZK set-membership check).
Privacy-Preserving Proofs: Agents can prove they are not on a specific blocklist without revealing who they are. This moves compliance from a surveillance model (reveal everything) to a verification model (prove eligibility).
The Result: The core protocol remains neutral and permissionless, while individual infrastructure providers stay compliant with their local jurisdictions.

6. Developer Integration

Obscurate provides an SDK designed for seamless integration into agent frameworks (e.g., LangChain, AutoGPT).

Reference Implementation

import { ObscurateClient, UCPPolicy } from '@obscurate/sdk';

// 1. Initialize Client
const client = new ObscurateClient({ rpc: 'https://rpc.obscurate.network' });

// 2. Define Policy (UCP)
// "Allow spending up to 50 USDC for Inference"
const policy = new UCPPolicy({
  scope: 'payment',
  limit: 50,
  currency: 'USDC',
  target: '0xInferenceProvider'
});

// 3. Execute with Privacy
// The SDK selects a valid Note, generates the ZK Proof adhering
// to the Policy, and dispatches to the Relayer.
const txHash = await client.execute({
  note: myPrivateNote,
  policy: policy,
  payload: apiRequestPayload
});

7. FAQ

Q: Why do autonomous AI agents need privacy?

A: Autonomous agents operate continuously, programmatically, and at scale. Unlike humans, they do not act sporadically — their behavior forms patterns. Without privacy, every payment, API call, or execution becomes a signal. Over time, these signals expose an agent’s strategy, economic intent, and operational logic. Obscurate treats privacy as a foundational requirement for autonomous execution, not as a defensive add-on. By removing deterministic links between identity, funding, and execution, agents can:

Operate without broadcasting their decision-making process.

Access commercial APIs without revealing usage profiles.

Execute economic actions without exposing treasury structure or strategy.

In the agentic economy, privacy is not about hiding — it is about preventing forced disclosure at the infrastructure layer.

Q: How does Obscurate differ from a Mixer?

A: A mixer is a withdrawal tool designed to break transaction links by moving funds to a fresh wallet. Obscurate is an execution environment. It allows agents to transact, invoke smart contracts, and pay for services directly from the shielded pool without ever withdrawing to a transparent wallet.

Q: How does Obscurate relate to x402?

A: x402 (HTTP 402) defines how agents signal and settle payments for digital resources, but it assumes direct, transparent wallet-to-merchant transactions. Obscurate can be understood as a privacy-preserving execution layer for x402. It preserves full compatibility with the x402 flow while removing its core limitation: the deterministic linkage between an agent’s wallet, its consumption patterns, and its economic strategy.

Q: What is the role of UCP in Obscurate?

A: UCP defines a standard way to express consent, delegation, and spending constraints for autonomous agents. Obscurate does not require UCP to function as a privacy layer for x402 payments. However, when UCP policies are present, Obscurate acts as a private execution runtime for those policies.

x402 defines what must be paid.

UCP defines who is allowed to authorize it.

Obscurate ensures it happens without leaking identity or strategy.

Q: Can Obscurate be used for illicit activity?

A: Obscurate is infrastructure. Like TCP/IP, it is neutral. However, the protocol supports advanced compliance primitives (ZK-based policy checks, View Keys) that allow operators and users to prove compliance with local regulations without sacrificing privacy by default.

Q: Is the system purely transactional?

A: Currently, yes. The primary primitives support value transfer and data payloads. Future versions are architected to support private state transitions and encrypted compute, extending the privacy guarantee from the transaction to the computation itself.