The allocator's dilemma: transparency or opacity, never assurance

TL;DR

• Allocators need assurance that autonomous agents follow mandates, but traditional verification can expose positions, transaction amounts, and trading strategies.

• State privacy hides balances, identities, or orders. Conduct assurance proves that a specific action satisfied a defined policy before execution.

• Inherence’s “proof of conduct for the agent economy” uses zero-knowledge receipts so third parties can verify policy compliance without seeing the underlying transaction data.

• Inherence Labs provides the pre-execution enforcement and verification layer. AML, sanctions screening, custody, and other privacy tools still address separate requirements.

The allocator’s dilemma: transparency or opacity, never assurance

Traditional finance gives institutions bilateral privacy during execution and selective disclosure to auditors afterward. Nearly half of institutional trading flows through dark pools because visible order size, direction, and timing let other traders react. Public chains reverse that default. Anyone can monitor transactions, positions, liquidation thresholds, and linked addresses in real time.

Public visibility creates direct loss channels. Bots can place transactions around a visible swap and profit from the resulting price movement. Ethereum recorded about 95,000 sandwich attacks in the year through October 2025, with estimated losses of about $60 million. Tagged wallets can reveal pending token sales. Public vault positions also let competitors copy strategies until the original advantage weakens.

Opacity protects sensitive positions, but concealment alone gives an allocator no assurance about how an autonomous agent behaves. A private venue can hide an order without proving that the agent respected an exposure ceiling. An encrypted position can conceal holdings without proving that the agent checked its counterparty or obtained the required approvals before execution.

Transparency lets an allocator reconstruct actions afterward, but market participants receive the same information soon enough to exploit it. Opacity limits information leakage, but the allocator must trust the operator’s internal controls and records. What evidence could prove that each action followed its mandate before execution without revealing the sensitive position used to establish compliance?

State versus conduct: the distinction that defines this category

State privacy hides sensitive facts such as a balance, position, identity, transaction amount, or private key. A system can conceal those facts while still proving basic validity, such as confirming that a transfer did not spend the same funds twice.

Conduct assurance answers a different question. It proves that a specific action satisfied a defined mandate when the actor took it. For example, an agent could prove that a trade stayed below an exposure limit and used an approved counterparty without revealing the trade size or the approved list.

Independent verification separates conduct assurance from an internal compliance record. A counterparty or allocator must be able to check the guarantee without trusting the operator’s database, audit log, or confidential computing environment. The guarantee must also bind the action to the policy version applied before execution.

State privacy and conduct assurance can work together, but one does not establish the other. Hidden balances do not prove that an agent respected its mandate. Likewise, a compliant action may reveal sensitive state unless the verification method protects the underlying inputs.

The survey below therefore evaluates each privacy approach against two separate tests. The first asks what information the approach conceals. The second asks whether an outside party can verify per-action mandate compliance without receiving that information or trusting the operator.

How the industry has tried to solve institutional privacy

• Private-by-design chains. Zcash hides senders, recipients, and amounts in shielded transactions, while Monero applies transaction privacy by default. Canton shares ledger data only with authorized participants. These designs protect transaction state, but they do not prove that a transaction complied with an external investment or compliance mandate when executed. Canton also trades permissionless participation for controlled access, while Monero does not support general smart contracts. IOSG Ventures describes these design differences.

• Bolt-on privacy. Tornado Cash obscures the connection between deposits and withdrawals, but funds cannot interact with applications while shielded. Railgun lets shielded assets reach decentralized finance, although transaction values can become visible during execution. Zama uses fully homomorphic encryption to keep token balances and amounts encrypted during computation. Each approach conceals selected data without proving that an action satisfied a separate mandate.

• Trusted execution environments. Oasis and Phala run sensitive calculations inside hardware-isolated environments and reveal only an attested output. An enclave can evaluate screening rules or match private orders without publishing the inputs. However, an allocator must trust the hardware vendor, the enclave’s integrity, and the code running inside it. Messari notes that zero-knowledge proofs can supplement TEEs when users need stronger evidence that the enclave behaved as claimed.

• MPC custody. Multi-party computation divides signing authority among several parties so that no participant controls the full private key. MPC can prevent one compromised custodian from moving assets alone, but it proves who authorized a signature rather than whether the signed transaction complied with a mandate.

• Proof of reserves. Exchanges and stablecoin issuers use reserve attestations to show that specified assets cover reported liabilities at a particular time. Zero-knowledge variants can hide exact balances while proving a coverage threshold. However, a reserve snapshot does not establish how assets were used between attestations or reveal every off-chain obligation. Agio Ratings explains these limits.

• Confidential trading venues. Aster, Paradex, and Hibachi conceal information such as order size or open positions within their venues. Venue privacy reduces information leakage around execution, but it does not give an allocator continuous evidence that a manager or autonomous agent followed exposure limits and counterparty rules.

All six approaches hide some form of state, including balances, positions, identities, keys, or computations. None independently verifies that a specific action stayed within a defined mandate at the moment the actor took it.

What a zero-knowledge proof actually lets you demonstrate

A zero-knowledge proof lets an operator prove that a defined statement is true without revealing the private data used to evaluate it. A verifier checks the cryptographic proof instead of inspecting transaction amounts, account positions, or proprietary policy inputs.

For an exposure limit, the proof can confirm that a proposed trade keeps total exposure below a threshold without disclosing the portfolio or threshold. For an approved-counterparty rule, it can confirm membership without publishing the full list. The same method can prove that required parties approved an action or that balances remain within specified bounds after execution.

A useful proof provides three guarantees. A compliant action can produce an accepted proof. A noncompliant action cannot produce one under the proof system’s security assumptions. The verifier learns whether the rule held and learns no additional information encoded as private input.

Zero-knowledge proofs target conduct when you connect them to an inline policy check. The proof certifies that a particular action satisfied a particular mandate using committed inputs. Hiding state protects balances, identities, and positions. Proving conduct gives an allocator evidence that the agent followed its mandate before the action proceeded.

The guarantee remains bounded by the encoded policy and the quality of its inputs. A proof can verify that an address appeared on an approved list, but it cannot establish that the list itself was accurate or current. Identity, sanctions, and transaction-risk systems still supply those external facts.

Comparing the approaches on mandate assurance

Institutional privacy tools protect different forms of sensitive state, but most do not prove that each action followed an allocator’s mandate. The comparison treats TEEs, MPC, and state-private ZK systems as complementary controls rather than substitutes.

Approach	State hidden	Per-action mandate adherence proven	Independent verification without operator or enclave trust	Fitness for continuous allocator oversight
Private-by-design chains	Sender, receiver, amount, or ledger activity, depending on the design	No. They prove transaction validity.	Varies by network design	Low
Bolt-on privacy and ZK state privacy	Transaction parties, amounts, balances, or history	No, unless the mandate forms part of the proved statement	Yes for the specific validity claim	Low by itself
Trusted execution environments	Inputs and computation inside the enclave	Partly. An attestation can report that policy code ran.	No. The allocator trusts hardware and attested code.	Medium
MPC custody	Signing-key shares	No. MPC proves that the required parties authorized a signature.	No. Assurance depends on the MPC participants and implementation.	Low
Proof of reserves	Exact holdings or liabilities in ZK variants	No. It proves a snapshot rather than conduct between attestations.	Sometimes, for the stated snapshot	Low
Confidential trading venues	Orders, positions, or trade details	No. Venue privacy does not establish mandate adherence.	Usually platform-dependent	Low
ZK-verified pre-execution enforcement. Inherence, proof of conduct for the agent economy.	Amounts, thresholds, positions, and policy details	Yes, within the encoded mandate	Yes. The allocator checks a cryptographic receipt.	High when every action receives a receipt

Why audit logs and post-hoc disclosure can’t close this gap

Richer audit logs help investigators reconstruct events, but they cannot prove that an agent satisfied a mandate before executing a transaction. Standard logs record API calls and outputs while often losing the intent, delegated authority, and policy that governed them. Dynamic execution paths also make some agent actions difficult to reproduce after an incident, a limitation described as an observability gap.

Retrospective evidence also depends on infrastructure controlled by the operator. The operator manages log access, retention, timestamps, service accounts, and policy records. An allocator must therefore trust that those records remain complete and unaltered. Adding more telemetry later cannot recover evidence that the execution architecture never generated, which is why audit trails cannot be retrofitted.

Post-hoc disclosure creates a separate problem for private portfolios. An allocator may need to inspect raw amounts, counterparties, positions, or strategy logic to determine whether a trade stayed within its mandate. Repeating that review across thousands of autonomous transactions raises operational costs and exposes information that the allocator may have no business reason to receive.

Regulators are increasing traceability expectations while leaving the technical proof model unsettled. The EU AI Act requires logging for covered high-risk systems, while SR 26-2 directs banks to govern agentic AI outside the formal model-risk framework. Neither requirement turns an operator-controlled record into independent evidence.

An inline cryptographic receipt serves a different purpose. The receipt binds an action to the applicable mandate at execution time and lets an allocator verify compliance without trusting the operator’s logs or viewing the underlying position.

Inherence Labs’ approach to proof-of-conduct

Inherence Labs applies the conduct guarantee directly to an AI agent’s transaction path. An allocator defines the agent’s mandate, including limits, approved counterparties, approval requirements, and exposure rules. Inherence translates that mandate into machine-enforced controls that evaluate each proposed action before execution.

The inline enforcer blocks actions that violate the mandate. For each compliant action, the system produces a cryptographic receipt of roughly 128 bytes. The allocator or counterparty can verify that receipt independently without relying on the agent operator’s logs or viewing confidential transaction details.

Inherence reports that an enforcement decision takes roughly 27 to 250 nanoseconds and that receipt verification takes about one millisecond. Those vendor-reported figures suggest that policy enforcement can operate inside a high-volume transaction path. Buyers should still test latency against their own policies, infrastructure, and transaction patterns because independent production benchmarks for these figures are not publicly available.

The approach remains young and patent-pending rather than a settled technical or regulatory standard. It also complements existing privacy and security methods. Trusted execution environments protect computation within isolated hardware, while multi-party computation distributes control over sensitive operations. State-focused zero-knowledge tools conceal balances or positions. Inherence adds pre-execution mandate enforcement and an independently verifiable receipt for each permitted action.

How proof-of-conduct relates to AML/KYC and adjacent enforcement tools

AML and KYC products answer questions that a mandate proof assumes have already been resolved. ComplyAdvantage screens identities and counterparties against sanctions data, then monitors transactions for financial crime risk. Such screening remains necessary because a policy enforcer needs reliable inputs about who may transact. Industry guidance describes these tools as producing internal decision records and case files for compliance review rather than privacy-preserving proofs of each action’s adherence to an operator mandate (Sanction Scanner).

Bretton addresses another part of compliance operations. Its agents support case review, due diligence, and alert handling, while its audit records preserve reasoning and evidence for later examination. Those records help compliance staff explain a decision, but the reviewer still depends on Bretton and the institution’s internal data trail.

Newton Protocol comes closer to pre-execution enforcement. Newton evaluates policies before onchain settlement and backs each decision with a cryptographic signature from a decentralized operator network (Newton documentation). A verifier can validate the signature, but the verifier relies on that network to have evaluated the rule correctly.

A self-contained zero-knowledge proof uses a different trust model. The verifier checks mathematical evidence that a specified policy held without relying on an internal log or validator network, and without seeing the protected transaction data. Inherence uses the branded phrase “proof of conduct for the agent economy” for this enforcement and verification layer. ComplyAdvantage, Bretton, and similar products can still supply screening decisions and investigation workflows around it.

FAQ

What does proof of conduct mean?

Inherence Labs uses “proof of conduct” to describe cryptographic evidence that an action satisfied a defined policy before execution. Inherence pairs pre-execution enforcement with an independently verifiable receipt for each compliant action. You can verify mandate adherence without viewing sensitive transaction details.

How does it differ from proof of reserves?

Proof of reserves shows that an institution held enough assets at a particular time, but it does not prove ongoing compliance with a mandate. Inherence instead verifies individual actions against policy as they occur. You gain continuous assurance rather than relying on periodic balance snapshots.

Are zero-knowledge proofs fast enough for real-time transactions?

Zero-knowledge proofs conceal underlying data, although proof generation and verification speed depend on the implementation. Inherence reports enforcement decisions within roughly 27 to 250 nanoseconds and verification in about one millisecond. Those speeds can support inline checks for high-volume transaction systems.

Does this replace AML and KYC screening?

AML and KYC screening identify customers, check sanctions exposure, and assess transaction risk. Inherence enforces the policies that govern an agent’s actions after screening tools supply relevant decisions or data. You still need screening software alongside pre-execution policy enforcement.

Where this leaves allocators today

Compliance and engineering leaders should evaluate mandate assurance now if autonomous agents will soon initiate financial transactions. Cryptographic enforcement can prove that an action followed policy without revealing positions, amounts, or strategy, but the market has not settled on common receipt formats or verification standards.

Organizations running limited pilots can continue watching until agents receive transaction authority or counterparties require independent evidence. Organizations approaching production should test policy coverage, verification latency, privacy guarantees, and integration requirements before deployment.

Leaders assessing agent-driven transaction infrastructure can contact Inherence Labs to evaluate the approach against their mandates and disclosure constraints.