Psy Protocol: a recursive-ZK chain looking for an economic gravity well.

Psy is one of the few new L1s that treats recursive zero-knowledge proofs as the substrate of execution itself, not a bolt-on optimization. Most of what is interesting — and most of what is risky — flows from that one choice.

• Architecture. A coordinator orchestrates a fleet of realm shards (128 at testnet, designed for 1,000+) running a Gather → Update → Test → Aggregate pipeline. Workers mine Plonky2 proofs for transactions; the coordinator finalizes by recursively folding realm proofs into a single block proof.
• Cryptography. Plonky2 over the Goldilocks field (p = 2⁶⁴ − 2³² + 1), Poseidon hashing, Merkle trees of height 32. Browser-side proving via a ~6 MB WASM prover.
• Privacy. A shielded UTXO pool sits alongside the transparent ledger. Notes are Poseidon commitments; spends are nullifier-based; transfers are Plonky2-proven. USDT_P is the in-network form of bridged USDT.
• Bridge. Two-way deposits/withdrawals against TRON and EVM, with M-of-N relayers, on-chain checkpoint roots, and force-withdraw as a censorship escape hatch. SP1 (EVM) and Groth16 (TRON) circuits adapt the recursive Plonky2 proof for cheap L1 verification.
• Distribution thesis. Psy is betting that HTTP-native, agent-mediated payments — the x402 protocol — become the dominant payment surface of the AI era, and that private x402 is a unique slot only a ZK chain can occupy.
• Where it is, honestly. Compiler, node, prover, wallet, IDE, explorer are 80–90% built. The bridge is the bottleneck (~15% coded against a complete spec). Privacy is ~30%. x402 and the agent tower are 0% but well-scoped. Mainnet target is 2027 H1–H2.

This brief argues that Psy is technically credible and structurally distinctive, but that its commercial future depends almost entirely on closing two gaps: bridge liquidity (no users without it) and a believable agent-economy wedge (no growth without it). Everything else is downstream of those two.

The 2024–2026 L1/L2 wave produced four broad families of new chains. Psy reads cleanly against the taxonomy:

Family	Examples	Bet	Where Psy diverges
EVM L2s	Arbitrum, Base, Optimism	Cheaper Ethereum.	Psy is not Ethereum and not EVM. Its security model is recursive ZK over its own state, not an Ethereum settlement attestation.
ZK L2s	zkSync, Linea, Scroll	Cheaper Ethereum + ZK roll-up.	Psy uses ZK to shard execution, not to compress an EVM trace.
Alt-L1s	Solana, Aptos, Sui, Monad	New consensus + new VM = throughput.	Psy's TPS argument is structural (recursion), not parallel-runtime micro-optimization.
Privacy chains	Aztec, Penumbra, Aleo	Private state by default.	Psy is closer in spirit, but separates a transparent rail (for ordinary payments and dApps) from a shielded pool (for private flows). Both share one prover and one block.

The single sentence that best captures the design: Psy uses recursive zero-knowledge proofs to make verification cost asymptotically flat as execution scales horizontally. Nodes don't re-execute transactions; they verify a recursively-folded proof that the right execution happened, somewhere, against the right state. Throughput scales by adding realms; verification cost stays roughly constant.

That puts Psy in conversation with recursive-proof rollup substrates (Polygon zkEVM, RISC Zero's Boundless, Succinct's SP1 prover network) more than with bespoke "ZK chains" that mostly use ZK for privacy and transparency for everything else. The lineage is visible in the codebase: a psy_sp1_plonky2_adapter crate converts Plonky2 proofs into SP1-shaped Groth16 proofs for cheap L1 verification on EVM — i.e. Psy is happy to compose with the broader recursive-proof economy rather than reinvent it end-to-end.

What makes the design idiosyncratic

• Own VM, own language. Not EVM, not Move, not WASM. Psy-lang is a domain-specific language that compiles directly to Plonky2 circuit constraints — every contract is, by construction, ZK-friendly.
• Goldilocks-native state. The state Merkle tree, the hash function (Poseidon), the prover, the language, and the wallet all speak the same field. There is no "translate from EVM to ZK" step; the chain is field-native end to end.
• Coordinator + realms ≠ classic sharding. Cross-realm composition is mediated by ZK proofs of state transitions, not by an asynchronous message-passing fabric. This is closer in spirit to a fleet of independent rollups settling to a shared coordinator than to traditional sharded BFT.
• Browser-side proving as a first-class feature. The WASM prover is ~6 MB and ships in the wallet. Users prove their own transactions; relayers mostly carry bits, not trust.

Psy is opinionated about its cryptographic primitives in a way most chains aren't. The whole stack speaks one prover, one field, one hash:

Layer	Choice	Why
Proof system	Plonky2 (recursive)	Sub-second prover, recursion-friendly, no trusted setup, designed for the Goldilocks field.
Field	Goldilocks p = 2⁶⁴ − 2³² + 1	64-bit, FFT-friendly, with cheap modular reduction on commodity CPUs. Native fit for Plonky2.
Hash	Poseidon	Algebraic hash with low circuit complexity. Used for Merkle tree, commitments, signatures.
Merkle tree	height 32, Poseidon-hashed	4 B leaf capacity; logarithmic membership proofs.
Browser prover	WASM (~6 MB binary)	Users generate their own UPS proofs locally, before submitting to the realm.
EVM-side adapter	SP1 → Groth16	For L1 bridge verification, a Plonky2 proof is wrapped through SP1 and emitted as a Groth16 proof cheap enough for the EVM to verify (~250K gas).
TRON-side adapter	Groth16 via gnark-plonky2-verifier	Direct Groth16 verifier for TVM-compatible verification.

UPS and DPN circuits

Two circuit families do most of the work:

• UPS (User Proving Session). Proves that a user authorized a sequence of operations against their account state. Lives in the wallet's WASM prover. Inputs: signature, current state root, operation list. Output: a UPS proof the realm can consume without re-checking the signature on chain.
• DPN circuits. Per-contract execution circuits. The compiler emits one DPN circuit per Psy-lang contract. Inputs: contract storage commitments, call args. Output: a proof of correct contract execution and a post-state commitment.

A complete block proof is, schematically:

// pseudo-recursion at the realm level
RealmProof := recursive_aggregate(
  [ UPS(txi) ⊕ DPN(contract, argsi) for txi in block ]
)

// and at the coordinator level
BlockProof := recursive_aggregate(
  [ RealmProofr for r in active_realms ]
)

The interesting property: a verifier (a light client, a bridge contract, a coordinator) only ever checks the outermost proof. The recursive structure compresses an arbitrary number of underlying executions into a constant-size verification cost.

The cost reality

The trade is real and worth being honest about. Plonky2 proof generation is slow compared to executing an EVM transaction — testnet block times observed in this codebase are ~10–30 seconds when real proofs are produced, versus ~8 seconds in the older JTMB (just-trust-me-bro) mock prover. That is the cost of moving from "execute and replay" to "execute, prove, recursively fold." It is also why the design needs aggressive worker parallelism and why the team is explicit that GPU-accelerated proving is on the post-mainnet roadmap.

A custom language is usually a yellow flag in a new chain. The reasonable question is "why didn't you just take EVM or Move?" Psy's answer is structural: because every contract must compile to a Plonky2 circuit, and bolting a circuit backend onto a general-purpose VM is a worse engineering problem than designing the surface language around the constraints from the start.

The psy-compiler repo bears this out. It is a complete, production-shaped toolchain across twelve crates: psy-lexer, psy-parser (LALRPOP-driven), psy-ast, psy-sema, psy-interpreter, psy-abi, psy-fmt, psy-lsp-server, psy-precompiles, psy-std, psy-package, and the psy-dargo-cli entry point. There is a 60+ test integration suite. There is an LSP. There is a formatter. There is a package manager scaffold.

Two design choices stand out:

1 · The compiler produces circuits, not bytecode.

A Psy-lang function does not lower to a stack-machine opcode stream; it lowers to a set of arithmetic constraints over the Goldilocks field. The "VM" is therefore a circuit-execution environment: psy_vm takes a contract circuit and runs it as a constraint system whose satisfaction is the proof of correct execution. This is structurally close to how Aleo's Leo and Aztec's Noir work, and structurally far from how Solidity-on-zkEVM works.

2 · The package manager and the wallet share an ABI.

The psy-abi crate is the single source of truth for typed contract interfaces. The wallet, the IDE, the explorer, and the TS SDK all consume ABIs emitted by the compiler, which means a deployed contract is auto-introspectable across the full stack — the explorer can list its methods, the wallet can build typed transactions, the IDE's "deploy and interact" panel can call it without code generation per project.

The DX surface

$ dargo new my_payment_app
  $ dargo build         # lex → parse → sema → circuit-gen
  $ dargo test          # run unit tests via the interpreter
  $ dargo deploy        # upload circuit + ABI to a realm
  $ dargo fmt           # canonicalize style

The flow is intentionally a Rust-shaped clone — cargo with the letters rotated — because the assumed user is a Solana / Aptos / Aleo developer who already lives in that ergonomic.

Privacy is implemented as a second rail, not as a default. The transparent ledger handles ordinary payments, contract calls, deposits, and withdrawals. A shielded pool sits next to it for users who want their balances, recipients, and amounts hidden. Both rails share one prover, one block, and one bridge.

The shielded pool, mechanically

The shielded pool is a UTXO system on top of an account-model chain — a design choice familiar from Tornado, Aztec, and Penumbra:

• Notes are Poseidon commitments of (amount, owner_pk, blinding_factor, nonce). They live in a single global Merkle tree of height 32.
• Spends are nullifiers — deterministic Poseidon hashes of (note_secret, position) — and are recorded on chain so the same note cannot be spent twice. Nullifiers reveal nothing about which note they correspond to.
• Transfers are Plonky2 proofs that some unspent note exists in the tree, that the spender knows its secret, and that the output notes preserve the conservation invariant sum(in) = sum(out) + fee.

The three primitive operations

shield(amount, recipient_pk)   // transparent → shielded
private_transfer(in_notes, out_notes, proof)
unshield(notes, transparent_recipient, proof)

The implementation lives across three repos: private-payments/ (cryptographic spec and TS reference client), the privacy circuits inside psy_plonky2_circuits, and the privacy-bridge-demo/ UI that exercises the full deposit → shield → private-transfer → unshield → withdraw path on the testnet.

What's worth pulling out, against the privacy-chain peer set:

Property	Tornado Cash	Aztec	Penumbra	Psy
Architecture	Mixer contract on Ethereum	Private L2 on Ethereum	Native private L1	Native private rail on a ZK L1
Transfers in shielded pool	No (single in/out only)	Yes	Yes	Yes
Selective disclosure	None	Note-level (view keys)	Yes (view keys, FCD)	Note-level (view keys planned)
Public + private in one tx	No	Yes	No (shielded-only)	Yes (cross-rail)
Mainnet status2	Sanctioned	Live	Live	Pre-mainnet

2. The Tornado entry is included for taxonomic completeness; this brief does not endorse circumventing the OFAC SDN listing of the Tornado contracts.

The structural advantage of Psy's design over its closest comparable (Aztec) is that the same chain hosts both rails and the same prover handles both proofs. The structural disadvantage is that the user has to opt in — privacy is not the default — which means an empty shielded set is a real adoption risk early on.

Naming convention worth pinning down

USDT bridged onto Psy is called USDT_P. The "_P" is the in-network privacy-capable form, not a "Psy token." There is no PSY stablecoin. This is a common source of confusion in third-party writeups; the design intent is that the bridged asset retains its origin's denomination but acquires Psy's privacy and proof properties.

The bridge is the most important and least-finished part of the stack. The specification (v0.4.3, in psy-bridge-contracts/BRIDGE_SPEC.md) is complete and unambiguous; the code is at roughly 15% of the implementation surface. Treat this section as a faithful read of the spec, not a description of what's live.

The four primary flows

DEPOSIT  (L1 → Psy)
  user → lock(USDT) on L1 Bridge contract
       ← deposit_id event
  relayers (M-of-N) observe and co-sign
  user (or anyone) calls claim_deposit on Psy with the signed receipt
  Psy contract mints USDT_P to recipient

WITHDRAWAL  (Psy → L1)
  user → burn(USDT_P) on Psy bridge contract
  Psy emits a withdrawal commitment, included in a coordinator checkpoint
  prover service generates a ZK proof of inclusion + correct burn
  user submits proof to L1 Bridge contract
  L1 verifies the recursive proof (via SP1/Groth16 adapter) and releases USDT

FORCE WITHDRAWAL  (escape hatch)
  if the relayer fleet stalls for > 2h
  user generates the inclusion proof themselves (public prover service)
  same on-chain verification path; no relayer signatures required

DEPOSIT CANCEL  (uncommitted funds)
  if a deposit is not claimed within 24h
  user reclaims the locked USDT on L1 directly

Security model

• Checkpoint Root Registry. An on-chain L1 contract that stores periodic state-root checkpoints from Psy. Withdrawals must reference a checkpoint that the L1 has accepted; this makes L1 an independent state oracle for Psy and removes the need to trust relayers for the cryptographic step.
• M-of-N relayer signatures. The fast path uses an off-chain relayer set, but no single relayer can forge a deposit credit; the threshold M is configurable per-asset.
• Nullifier scheme on L1. Withdrawals carry a unique nullifier that the L1 records, preventing the same Psy-side burn from being replayed against L1.
• Public prover service. Crucially, the proof generation for withdrawals is permissionless. If the operator-run prover service disappears, anyone can run the same code and produce a valid withdrawal proof. This is the censorship-resistance property that distinguishes a real ZK bridge from a multisig.

Why this is the bottleneck

Without the bridge, Psy has a sophisticated execution layer for assets that don't exist on it. The TRON path is the priority leg — TRON dominates global USDT settlement volume and Psy's positioning explicitly targets that flow. The EVM path is the broader integration point. Both legs need:

1. L1 Solidity (and TVM-equivalent) bridge contracts with verifiers.
2. SP1 / Groth16 circuit adapters wrapping Plonky2 withdrawal proofs.
3. A bot fleet for event listening, relaying, and checkpoint submission.
4. A public prover service for force-withdrawal.

The team's roadmap aligns bridge completion with Q2–Q3 2026. Everything downstream — privacy adoption, x402, the agent tower — is gated on it.

The most distinctive product bet in the Psy roadmap is the x402 layer and the agent-economy stack built on it. To evaluate the bet, the protocol is worth understanding briefly:

x402 is an open payment protocol from Coinbase (with Cloudflare as co-founder of the x402 Foundation) that repurposes the HTTP 402 Payment Required status code into a functional, machine-mediated payment layer. A server returns 402 with a payment requirement in a header; the client signs an authorization; a facilitator service verifies and settles on chain. By early 2026 over 75 M x402 settlements have cleared on Base and Solana, with Google A2A, AWS, and Vercel among the adopters.x402 Foundation, public adoption telemetry, Q1 2026

x402 is interesting because it is the first credible standard for machine-to-machine HTTP payments. The relevant question for Psy is: what does adding a Psy facilitator give the protocol that no other network gives it?

The Psy x402 wedge

Three payment schemes are planned:

Scheme	What it does	Where Psy is differentiated
exact	Sign a fixed-amount transfer authorization.	Comparable to Base/Solana implementations; faster finality than L1 EVM.
upto	Authorize a maximum; settle for metered usage.	Natural fit for AI inference billing, token-priced APIs.
private	Settle via the shielded pool with a ZK proof of solvency.	Unique to Psy. No other x402-compatible network can offer a payment where the recipient learns the amount but not the payer's identity or balance.

This is the cleanest product slot in the entire roadmap. It's a concrete, narrowly-defined capability — "x402, but anonymous" — that maps to a real, growing surface (agent-mediated payments) and that no incumbent network can match without a comparable shielded execution layer. Whether the slot is commercially large enough to anchor an L1 is a separate question; in the medium term the team's bet is that the AI agent economy generates payment volumes large enough that even a single-digit-percent share is meaningful.

The AI tower

Built above x402, the planned stack is:

• Agent Wallet SDK. Spending limits, allowlists, autonomous signing within budget, multi-sig fallback for large payments. The human owner sets the rules; the agent operates inside them.
• MCP Payment Server. An MCP-compatible bridge that lets any MCP-aware AI (Claude, GPT, etc.) consume paid tools via x402 negotiated transparently to the underlying model.
• Agent Marketplace. An on-chain registry of agent services with reputation scoring and ZK proof-of-delivery for dispute resolution.
• Automaton runtime. An autonomous agent execution environment (the existing repo of the same name) ported from EVM/USDC plumbing to Psy-native rails.

Honest read: this is the most aspirational part of the roadmap. The implementation is currently 0%; the spec quality is high. The strongest version of the argument is that Psy doesn't need to build the agent ecosystem itself — it needs to be the network that already has the right primitives the moment third parties start building agent products that need private settlement.

Why the privacy property matters here, specifically

An agent transacting on a transparent chain leaks:

• Its balance, which lets counterparties price-discriminate.
• Its revenue stream, which lets competitors target its suppliers.
• Its principal, since address re-use is the norm.
• Its spending patterns, which leak strategy.

None of these are theoretical — they are the exact privacy properties that financial institutions spend large sums to preserve in human-mediated commerce. The thesis is that whatever fraction of commerce moves to agents will demand the same properties as soon as the volumes matter.

Psy's public-facing performance posture, articulated by founder Carter Feldman in a 2025 Cointelegraph interview and echoed in the Chinese-language introduction in psy-v3, is unusually careful:

TPS is the second benchmark of blockchain performance, not the first. The first benchmark is economic — transaction fees, real demand, network health. A high TPS measured on a single node or on a testnet doesn't say anything about a chain's behavior in production, where transactions must be relayed and verified by many independent nodes. Capacity claims should follow demand evidence, not precede it.Carter Feldman / Psy team, public statements

This is a more defensible posture than the headline-TPS marketing common to alt-L1s, but it has rhetorical costs. The team is explicitly choosing not to publish a "we did 1 M TPS in testnet" number — even though the architecture is the kind that could plausibly produce one — because they regard the number as misleading without the multi-node verification context.

The architectural argument for why the design is fast remains:

• Verification cost is O(1) in transactions per block, by recursion. Nodes do not re-execute.
• Execution cost is horizontally parallel across realms. Each realm scales independently.
• Proving cost is parallel across workers, and is the rate-limiting step. GPU-accelerated proving moves the limit by a meaningful constant.
• Network cost dominates at very large realm counts, but is mediated by NATS JetStream pub/sub rather than by mesh gossip.

The honest read: the design plausibly delivers extreme throughput at the system level (realm × users-per-realm × ops-per-user), but block latency is set by proof generation time and is meaningfully higher than EVM L1 or BFT alt-L1s — testnet observations of 10–30s blocks under real proof load. This is fine for payments and contract execution; it is not where Psy will win against low-latency trading venues.

Psy Protocol is the most fully-realized small-team implementation of a recursive-ZK execution layer this brief has examined. The cryptographic taste is consistent; the architectural choices are coherent; the codebase is large, working, and unusually self-contained for a project at this stage.

The strategic question is not whether the protocol is sound — it appears to be — but whether the team can translate technical credibility into economic gravity in the 12–18 months between bridge launch and mainnet. The base requirements are clear:

1. Ship the bridge. TRON first, EVM second. Until USDT_P exists on Psy with credible cross-chain liquidity, nothing else matters commercially.
2. Get one privacy product to volume. A single high-volume application of the shielded pool — agent payments, professional services, anonymous content monetization — is worth more than a roadmap of ten.
3. Land an x402 facilitator with one anchor customer. The unique slot Psy occupies in the x402 ecosystem is the "private" scheme. Securing one substantial counterparty — an AI inference provider, an MCP server operator, an agent platform — would convert the architectural argument into a distribution argument.

If the first happens, Psy becomes a real chain. If the first two happen, Psy becomes a differentiated chain. If all three happen, Psy is in the small set of ZK-native networks with both technical depth and a defensible product wedge in the AI-era payment surface.

The work between now and mainnet is large but legible. This is, in the end, a constructive read: the bets are well-chosen, the team has shipped a remarkable amount of infrastructure, and the parts that are missing are the parts a competent team can build. The next eighteen months are the test.

— Psyverse Brief, 16 May 2026. This document is an independent third-party reading based on publicly available repositories, specifications, and team statements. It is not an endorsement, investment advice, or an official statement of the Psy team. The author has no position in any token associated with the protocol.