Privacy
Verifiable privacy on Maroo — the shielded-pool privacy precompile, the EIP-712 authorized-relay domain, PCL policy enforcement on every privacy call, and the selective-disclosure model compatible with regulator audits.
Privacy
The *WithAuthorization entry points on IPrivacy accept a signature that authorizes a specific executor to run a specific privacy action on behalf of an effective sender. That signature covers an EIP-712 digest whose domain and struct type are fixed by the precompile — the domain is EIP712Domain(name="Maroo Privacy Precompile", version="1", chainId=<EVM chainId>, verifyingContract=<IPrivacy address>), and the primary type is PrivacyActionAuthorization. Both the EVM chain ID (as a uint256) and the Cosmos chain ID (hashed into the struct) are bound into the digest, so a signature produced against one network cannot be replayed on another. Off-chain signers must reconstruct the same domain and struct fields exactly, or the precompile rejects the call with an EOA/ERC-1271/EIP-7702 signer-mismatch string revert.
Most contract-scope PCL enforcement runs through a PCL-wrapped proxy: the proxy's preCall / postCall hooks evaluate the ContractPolicyConfig bound to the proxy address. A policy-aware precompile is different — it is a binary-supported precompile whose code evaluates PCL policy internally at its own precompile boundary. Currently the only policy-aware precompile is the Privacy precompile at 0x100000000000000000000000000000000000000b. Because a precompile is not a deployed contract, it cannot be registered as a PCL proxy and does not go through the proxy hook path; instead its address is bound directly to a ContractPolicyConfig through IPcl.changeContractPolicies, and the precompile reads that configuration on every state-changing call.
The Privacy precompile at 0x100000000000000000000000000000000000000b implements a shielded pool for OKRW. Callers deposit transparent OKRW to commit a note, transfer notes to other recipients under a Groth16 proof, or withdraw a note back to a transparent EOA — each with an EIP-712 *WithAuthorization relay variant and a batch form. Every state-changing call passes PCL policy evaluation at the precompile boundary, so shielded flows respect the same compliance rules as transparent ones. Failures now revert with typed custom errors declared on IPrivacy — the ambient shared errors from IPrecompile, the request-lifecycle family (PrivacyNonPayable, PrivacyRequestExpired, PrivacyBatchSizeOutOfRange, PrivacyNativeDenomMismatch), the authorization family (PrivacyInvalidAuthorizationField, PrivacyAuthorizationExpired, PrivacyAuthorizationNonceUsed, PrivacyAuthorizationSignerMismatch, PrivacyAuthorizationRejected, PrivacyInvalidAuthorizationMagic), and the shielded-state family (PrivacyDuplicateNullifier, PrivacyNullifierAlreadySpent, PrivacyDuplicateCommitment, PrivacyCommitmentAlreadyExists, PrivacyMerkleCapacityExceeded, PrivacyTxLimitExceeded, PrivacySenderTxLimitExceeded).
Users control what to reveal (counterparties, amounts, asset types) on a per-transaction basis, and regulators access data within limits defined by law — a design that satisfies privacy and compliance at once.
The execution layer of this model is live on chain: the privacy precompile at 0x1000…000b handles shielded-pool deposits, transfers, and withdrawals verified by zero-knowledge proofs, and every state-changing privacy call passes PCL policy evaluation. The concrete mechanisms are documented in this section's concept pages and the IPrivacy API reference.