Confidential · Compliant · For regulated institutions only

Prove everything. Reveal nothing.

In plain terms: a family office, crypto-native fund or on-chain treasury holds serious money on a public blockchain, where anyone can watch every move. PROVA is a confidential vault that keeps their holdings hidden from competitors and bots, while still letting them prove to a regulator that the vault admits no listed counterparty to its perimeter — without handing anyone a key to their book. Built for the desks that actually hold crypto on-chain — family offices, crypto-native hedge funds and trading desks, large swing traders who move size a few times a year and sit on the position in between, DAO and protocol treasuries, and tokenization / RWA issuers. These holders don't keep everything in one place: their assets live on different blockchains — strkBTC on Starknet, wstETH on Ethereum and Arbitrum, tokenized US Treasuries and RWAs wherever they're issued — and they answer to different regulators in different countries. PROVA is built to meet each asset where it already lives: the same vault runs on Starknet and Arbitrum today, with Solana on the way, and screens against whichever sanctions list a given jurisdiction requires. One product, every chain the client's money is on — no bridges, no moving assets around. How the compliance boundary works, in one breath: only addresses the client approves can deposit (the client runs the guest list — no stranger can drop assets into the vault), every deposit and every withdrawal is checked against the sanctions list — both on the way in and on the way out (screening on entry is something almost nobody in crypto does, yet it's exactly what tokenized Treasuries and RWAs require), and each holding carries a certificate of provenance — proof that it derives from the institution's own declared association set, settled on-chain. No listed counterparty is admitted to the perimeter, and every holding carries provenance anyone can verify. And to an observer watching the chain, a withdrawal can't be tied back to any particular deposit — who exited, when and to where doesn't read off the public trail. But this is privacy inside an already-screened perimeter: both entry and exit passed the sanctions check and provenance is proven by certificate, so breaking the trail isn't a way to hide sanctioned value — it's how a screened holder's strategy stays shielded from onlookers.

PROVA is a confidential, compliant treasury-vault for regulated institutions — built on a first-rank zero-knowledge stack: STARK-secured Starknet, settled to Ethereum, UltraHonk proofs verified on-chain. Your treasury stays sealed from the market, with a sanctions boundary that is cryptographically provable to a regulator. Asset-agnostic by design — tokenized treasuries, yield-bearing wrappers, near any count-preserving token. Custody never leaves your keys. One audited-once ZK core, portable to the chain your assets already live on — the same circuits and verification keys deploy natively on any EVM chain, so PROVA comes to the asset instead of bridging the asset to PROVA.

Your book is sealed from —
front-running bots competitors' trading desks chain-analysis & flow-data vendors MEV searchers counterparties pricing against you never from the law — the sanctions boundary is proven to it, on-chain ✓
Every claim on this page settles to a public transaction. The vault is deployed and verified on two testnets — Starknet Sepolia and Arbitrum Sepolia. Open the contracts, read the getters, re-run the adversarial checks yourself.
290 contract tests
23 circuit tests
111 E2E cycles settled

Deposit → hold → withdraw, live

Two views of one vault. Only one of them can read it.

Below is a working model of the PROVA vault, computed right now in your browser. Deposit seals an amount into a note — the chain records the commitment and its denomination, never who can spend it or where it will exit. Withdraw proves the note and releases funds without ever linking exit to entry. Switch to the chain observer to see exactly what a competitor sees.

Merkle root computing…
— notes held
Your desk sees amounts, dates, status — and can act.
Compliance gate · contract-enforced
idle — every deposit and withdrawal below runs the same gates the contract enforces on-chain
Public nullifier feed — what exits look like on-chain
No withdrawals yet. When one settles, only a nullifier hash appears here — unlinkable to any commitment above.
Sample notes — amounts and dates are illustrative. In the production vault a note's secret and nullifier never exist on-chain; its denomination is intentionally public — part of the compliance-visible boundary — and standardized denominations keep the visible data structureless. SHA-256 in your browser, for illustration — the production vault commits with Poseidon-BN254 and verifies UltraHonk proofs inside the transaction. Verify the live vault → root consistent

The problem

A public chain shows your competitors everything. The usual fixes make it worse.

Why now · the cost of the status quo

Transparency is not neutral. On a public chain it is a standing tax on every position you hold.

The question is not whether confidentiality is nice to have. It is what a transparent, retrospective-compliance treasury already costs you — today, on every deposit, every exit, every audit cycle. Three costs, each of which compounds.

Cost 01 · information leakage

Your book is priced against you

A transparent ledger publishes size, timing and counterparties to anyone with a block explorer. Every large position becomes a signal — front-run by bots, faded by counterparties, mapped by chain-analysis desks. This is not a breach; it is the default behaviour of the chain. It shows up as worse fills and eroded edge on every move, and it scales with the size of your book.

Cost 02 · strict-liability sanctions risk

Detection cannot un-accept a dirty deposit

Sanctions liability is strict — intent is not a defence. Viewing keys and monitoring answer who may look at what already happened; they cannot stop tainted value from entering or leaving in the first place. Once a bad deposit settles, the exposure is booked. Detection is not prevention — and supervisors increasingly expect the latter, at the gate, not in the quarterly report.

Cost 03 · the window

Regulated capital is arriving on-chain — unsolved

Tokenized treasuries, money-market wrappers and institutional stablecoins are moving on-chain now. The piece still missing is a way to hold them that is confidential to the market and provable to the regulator at once. The desks that solve this first hold their positions without publishing them — while the rest are still choosing between disclosure and compliance.

Every day on a transparent vault is a day your strategy is public and your compliance is retrospective. PROVA closes both — at the gate, inside the same transaction.

What is PROVA

Seven deliberate choices — each removes a problem instead of adding a feature.

A regulated institution holds its on-chain treasury inside its own isolated vault — confidential from the market, provable to a regulator, never handed to a custodian. The design is defined by what it refuses as much as by what it does.

CHOICE 01

Confidential, not private

PROVA protects what and how much — balances, counterparties, flows — from external observers. It does not chase a large anonymity set hiding who participates. The threat model is the competitor and the front-running bot, not the state. That is the confidentiality a treasury needs — and the axis on which anonymity-set size is simply not the game.

CHOICE 02

Compliant

Entry is restricted to counterparties the institution approves — a controlled, provable perimeter, never an open pool. On EVM deployments, where depositor and recipient share OFAC's address space, this is reinforced by an on-chain zero-knowledge OFAC non-membership check on entry and exit. On Starknet, where account addresses fall outside that designation space, compliance is enforced at the perimeter and made auditable through selective disclosure. No listed counterparty is admitted, and a regulator can verify the boundary without a standing audit key. This is not a mixer.

CHOICE 03

Treasury-vault

A place to hold, not a venue to trade through. The product is a vault assets rest in between moves — you keep trading wherever you already do, and hold the position here, sealed from the market.

CHOICE 04

Yield-bearing assets

Yield accrues inside the asset — accruing-in-price wrappers, tokenized treasuries whose value rises in the token's own rate — so capital is not idle while held. No external contract call, no DeFi integration, no composability required.

CHOICE 05

Held-only

Deposit → hold → withdraw. No internal transfer graph, no swaps. The smallest sufficient surface — which is also the smallest surface to leak, and to audit.

CHOICE 06

No composability — by design

Wiring the held asset into external DeFi costs the confidentiality of amounts: swap sizes hit public AMM state — precisely the property the institution is paying to protect. PROVA declines that trade: the vault is where a position rests between moves, not the venue you execute through. Trade wherever you already do — hold the resulting position here, sealed.

CHOICE 07 — THE ONE THAT ADDS

With zkSoF — an affirmative proof of source of funds

Provenance from a declared association set, bound to a specific note. Six choices subtract risk; this one adds a property no blacklist can give: the proof attests which declared set the funds derive from, not merely that an address is absent from a list. It is cryptographic evidence for a source-of-funds file — timestamped and independently checkable — not a substitute for the AML judgment itself.

The protocol

Deposit. Hold. Withdraw.

STEP 01 — ENTRY, GATED

Deposit

Before any token moves, the contract enforces three checks: membership in your own whitelist — the operator is the client, so only addresses you approve can ever deposit (a random passer-by cannot put anything into your perimeter, so tainted assets never appear inside it in the first place); an OFAC non-membership proof bound to the caller's address — sanctions screening enforced on the way in, which almost nothing in the industry does, yet is exactly what a tokenized-Treasury or RWA program needs; and a proof that the note's commitment opens to exactly the deposited amount. A deposit claiming a different amount is structurally impossible.

STEP 02 — SEALED, EARNING

Hold

The note rests in your own vault. Yield accrues inside the asset itself — no DeFi calls, no rebalancing, no oracle. Balances, counterparties and flows are invisible to observers; only commitments touch the chain.

STEP 03 — EXIT, SOVEREIGN

Withdraw

A zero-knowledge proof — verified by the contract inside the transaction — authorizes exit. The nullifier prevents replay; the recipient is sanctions-screened in the same atomic transaction. Exit never waits on any third-party compliance service.

What defines the design

Three properties you can check in the contracts — not a brochure.

zkSoF · outside the money path

Affirmative source of funds

AML asks "prove the source of these funds." A blacklist answers only "not on this list." PROVA's zkSoF is a positive proof that a note derives from an approved association set — and it runs as a parallel attestation, never as a withdrawal gate: the money path never waits on a compliance operator. The attestation settles on-chain as a certificateProvenanceAttested, timestamped, bound to the note — and anyone can confirm it via is_sof_attested. The set is the institution's own, committed on-chain: the proof establishes derivation from a declared set, not a legality verdict — evidence inside your compliance program, not a replacement for it.

Per-transaction disclosure

No standing audit key required

Prove a specific fact about a specific transaction when lawfully requested — liability assessed by knowledge at the time of the transaction, as in ordinary law. And where a client's supervisory relationship calls for viewing-key disclosure, it layers cleanly on top: disclosure is policy; prevention stays at the gate.

Sovereign by construction

Physical single-tenant isolation

Each client deploys and owns its own vault — a separate sovereign audit domain, not a logical partition in a commingled pool. No neighbour-reputation risk. The vendor holds no privileged key over a deployed instance: read owner on-chain and confirm it is yours.

Positioning in the Starknet stack

Prevention at the gate. Disclosure on request. Two layers of one compliance stack.

Starknet's ecosystem is building a viewing-key standard for confidential assets — and it answers a real need. PROVA does not compete with it: the two answer different questions, and a regulated institution needs both answered.

"Who may look at what happened?"
Disclosure — the viewing-key layer

An auditor or supervisor granted a key can read flows after the fact. This is the right tool for audit and supervisory relationships — accountability for what has already settled. PROVA composes with it: a client that adopts the ecosystem's viewing-key standard simply layers it on top of its vault, as policy.

"What may pass at all?"
Prevention — PROVA's gate layer

Before value moves, the contract itself enforces an OFAC non-membership proof on the depositor at entry and on the recipient at exit. This is what makes an institution certain that no listed address either enters or exits — a guarantee no amount of after-the-fact viewing can provide, because visibility cannot un-accept a deposit that should have been refused at the gate. In parallel — never as a brake on exit — each note earns a zkSoF provenance attestation that settles on-chain as a certificate, bound to that note and checkable by anyone. The order matters: a blocked recipient is turned away at this compliance gate before any proof is even checked — which is what separates PROVA from a privacy mixer with screening bolted on. Confidentiality lives inside the compliance perimeter, not beside it.

Disclosure is a policy an institution chooses. Prevention is a property the contract enforces. PROVA adds the layer the stack was missing — and composes with the one it has.

Your jurisdiction, your list. PROVA screens against the sanctions regime you are actually accountable to — not a one-size-fits-all blacklist. The U.S. OFAC SDN List is live on the current deployments, and because the list is a pluggable input rather than a hard-wired assumption, your vault can be stood up quickly against the regime your regulator expects: the EU Consolidated Financial Sanctions List (European Commission), the UK Consolidated List of Financial Sanctions Targets (OFSI, HM Treasury), the United Nations Security Council Consolidated List, the Swiss SECO sanctions list (State Secretariat for Economic Affairs) — or several at once, one reproducible tree per jurisdiction. Same contracts, same proofs, your rules — a configuration of the pipeline, not a rebuild.

Roadmap: BTC-origin screening for strkBTC. A bridged asset has one moment when its origin exists as a screenable subject — before the bridge. On the roadmap, BTC deposit addresses are screened against the SDN's XBT entries (520 designated Bitcoin addresses on the current list) at the custody/bridge boundary, before strkBTC is minted — with a proof-carrying attestation of that screening to follow on the same attestor rail that governs the sanctions root today. Stated as roadmap, not as shipped: the gate lives where the subject lives, and for a bridged asset that is the mint boundary, not the vault.

The trust boundary

What PROVA proves — and what it does not.

Stated plainly · no asterisks
Proven, on a public network
That the vault verifies both money-path proofs on-chain — deposit amount-binding and withdrawal. That a borrowed-address proof, a fabricated sanctions root, and a replayed nullifier each revert. That the full deposit→withdraw cycle has settled 111 automated runs with deterministic, bit-identical gas. Every claim maps to a transaction you can open.
Not claimed — yet
Mainnet operation and live yield-bearing assets are go-to-market scope, not a current claim: today's vault runs on Sepolia against a mock ERC-20 standing in for the production asset. PROVA is a pre-market MVP, and this page will never say otherwise.

The difference between PROVA and a pitch deck is that PROVA's claims come with transaction hashes.

Trust transferred from a name to a proof.

The vault is non-custodial and trust-minimized: PROVA never holds the asset and holds no privileged key over a deployed instance. Confidentiality rests on a zero-knowledge proof verified on-chain — not on trust in a hardware enclave, and not on trust in the vendor. A reviewer does not have to trust the founder's reputation: they read the source-verified contracts and re-run the adversarial checks themselves.

The capital here is verifiability, not a custodian's brand — don't trust, verify, applied to the business model, not only to the code.

Pure infrastructure: no token, no protocol fees, no custody. Each licensed institution deploys and owns its own vault, verifier, and compliance policy — B2B annual licensing.

Attack surface

What PROVA does not do — and why that is your security.

Read the post-mortem of almost any nine-figure protocol loss and you find the same precondition: the protocol was doing something with the money. Lending it, pricing it, swapping it, quoting it against an oracle, pooling it with strangers. Exploits need a moving mechanism to attack. A vault at rest does not offer one — because a vault at rest is not a mechanism. Confidentiality is what PROVA sells; a smaller attack surface is what the design costs you nothing to receive.

No yield engine
Your capital is never deployed into a strategy, never lent, never rehypothecated. Strategy risk cannot exist inside a perimeter that runs no strategy. Yield that is embedded in the asset itself — a value-accruing token such as wstETH — accrues untouched: the vault adds no return and subtracts no basis point.
No oracle
The contract never reads an external price. There is nothing to manipulate, no stale feed to exploit, no flash-loan path that moves a number the vault depends on — because the vault depends on no number.
No bridge
The vault is deployed on the chain where your asset already lives. Capital never crosses a chain. What is portable is the proof artifact — the same bytes verify on Starknet and on Arbitrum — never the money. The largest loss category in this industry is one we do not build with.
No pool
Single-tenant. Your instance holds your assets and no one else's. There is no shared anonymity set to co-mingle with, no counterparty inside your perimeter, and no economic attack against a pool that does not exist.
No token, no fees
No governance token to capture, no emissions to farm, no protocol-fee accounting to drain. The vendor's revenue is an annual licence paid in fiat, entirely outside your vault.
No composability
The vault calls no external contract other than the ERC-20 of the asset it holds. It cannot be composed into someone else's leverage loop. Nothing you did not choose can reach your capital.

What is left, stated without softening.

Four things: deposit, withdraw, a commitment tree, and an on-chain proof verifier. That is the whole surface. The residual risk is real and we name it — the code may be wrong: smart-contract risk, circuit risk, prover and verifier implementation risk, and the risk of a protocol that is new. PROVA carries no external audit and no mainnet volume today, and this page will say so until the day that changes.

But notice what that risk is. A custodian carries a class of risk you cannot inspect: an insider, a compromised vendor, an operational decision, a court order, an insolvency. You close it with a contract, an insurance policy and a name. A vault carries a class of risk you can inspect: source-verified contracts, adversarial tests you re-run yourself, a verifier your engineers read line by line. Trust does not disappear here — it changes from the kind you must take on faith to the kind your diligence can actually reach.

Which is why nobody should move nine figures into an unaudited protocol, and we will never ask. The path is a pilot at a sum whose loss is immaterial, your own engineers breaking it, an external audit before real capital, and then a slice of the cold layer — not the balance sheet. Don't trust, verify is not a slogan here; it is the sequence.

Diligence · for the buying committee

The questions a compliance officer, a GC and a CIO each ask first.

Circulate this to your committee. Every answer below maps to a contract you can read or a property you can verify on-chain — not a promise, and not a claim this page can't back with a transaction hash.

Compliance & Legal
"Isn't this a mixer? What about the Tornado Cash precedent?"
No — and the distinction is structural, not cosmetic. A mixer pools strangers' funds into a shared anonymity set and removes compliance to buy privacy. PROVA is the inverse on every axis: each client holds a single-tenant vault of its own funds — there is no anonymity set of strangers to join — and sanctions screening is enforced by the contract as a precondition of every entry and exit. PROVA does not strip compliance to add privacy; it makes compliance the gate that privacy passes through. Confidential from the market, with the sanctions boundary proven to the regulator on-chain.
CIO & Procurement
"You're an early vendor. What happens to our vault if you're gone?"
It keeps running, untouched — because you own it, not us. Each vault is deployed under your owner key; read owner on-chain and confirm it is yours. The vendor holds no privileged key, and cannot pause it, rotate your roots, or move your funds — not by policy, by construction. Contracts are source-verified and source-available (BUSL-1.1, converting automatically to MIT in 2029 — a continuity guarantee that does not depend on the vendor existing), and your license covers operating your own instance — so your engineers and auditors hold everything needed to run and review it independently of whether the vendor exists. Vendor-continuity risk — the usual blocker for infrastructure from a young company — is engineered out, not underwritten.
Compliance & Legal
"What's the regulatory basis? Has a regulator blessed this?"
PROVA is infrastructure, not a legal opinion, and this page makes no claim of regulatory endorsement. What it does is align the technical control with the obligation you already carry: screen sanctioned counterparties, evidence source of funds, and disclose specific facts when lawfully compelled. Prevention sits at the gate; disclosure is per-transaction and composes with any supervisory viewing-key relationship your regulator expects. You bring the compliance policy and the jurisdiction; the contract enforces it cryptographically.
Compliance & Legal
"The operator curates the approved set. Why should I trust a list the client wrote for itself?"
Because the design separates two roots carrying two different claims. The sanctions root is not the client's opinion: it is built from the public U.S. Treasury SDN list by a deterministic, reproducible pipeline — anyone can rebuild it and confirm the on-chain value bit-for-bit — and it changes only through a two-step, 24-hour-timelocked migration, so substitution is public and detectable. Making substitution impossible rather than detectable — a contract that accepts only roots signed by a designated external attestor — is the next declared milestone, stated here as roadmap, not as shipped. The whitelist and association set are the institution's own declared perimeter — deliberately a weaker claim ("derives from the set you declared"), useful as evidence, and never presented on this page as sanctions compliance.
Compliance & Legal
"Does a ZK proof prove the funds are legal? Where do KYC, KYB, UBO, PEP and Travel Rule fit?"
No — and a vendor claiming otherwise is overselling. A zero-knowledge proof establishes set-(non-)membership; legality is a property of what the set represents and who attests it, which sits above any proof in the stack. PROVA is one enforcement primitive inside your compliance program, not the program: it makes an externally defined predicate — sanctions non-membership — cryptographically binding at the one point your off-chain program cannot reach, the contract boundary where value actually moves. KYC, KYB, UBO, PEP, adverse media, Travel Rule and ongoing monitoring remain your existing stack, above PROVA. The vault enforces the predicate; your program supplies the judgment.
Compliance & Legal
"In wording we can put in front of our head of financial monitoring, an independent auditor and a regulator: what exactly does the proof establish?"
Exactly this, and nothing broader: for every entry and exit, the contract verifies a cryptographic proof that the screened address is not a member of a specified, dated version of the OFAC SDN list, fixed on-chain as a Merkle root, at the moment of proof. The fact of the check, the list version and the result settle as on-chain events; the proofs are reproducible and independently verifiable by any third party without access to vendor infrastructure. The contract additionally enforces the funds-movement invariants — each note spends exactly once, and the exit amount is bound to the deposited amount. Three things this deliberately is not: not "full regulatory compliance of the transaction" (no technical system can prove that), not "cleanliness" in a provenance sense (the sanctions gate claims no source tracing — provenance is the separate, weaker zkSoF attestation), and not identity — the screening is address-scoped, against legally mandated lists, the only criterion that carries legal force. A narrow claim that is provable beats a broad one that is not.
Compliance & Legal
"A sanctioned actor generates a fresh address that appears on no list. It passes the check. Doesn't that break the model?"
It passes — and an honest vendor says so plainly rather than waiting for your reviewer to find it. A freshly generated address is a member of no list; every list-based screening on earth, including a bank's, passes it. A system claiming otherwise would be claiming to verify the identity behind a pseudonymous address, which no cryptography can do. What contains the scenario here is the topology, not the list: the vault is single-tenant, so the only depositor is the institution itself. "A sanctioned actor controls the secret" therefore means one of two things — your own key-holder was just listed (a KYC/offboarding event your program catches first, not a protocol property), or your secrets were stolen (an incident with an observable on-chain footprint: the attacker's address must obtain a clearance in its own prior transaction before any exit can run). And when an address is listed between root updates, two speeds of response exist: an emergency denylist that instantly blocks new clearances for that address — block-only, auto-expiring, unable to touch funds — and the timelocked root rotation that re-screens every address against the fresh list. The gate proves what a list can prove — and never claims more.
Compliance & Legal
"An address is clean today and sanctioned tomorrow. What happens to proofs already issued?"
They die with the root. The contract accepts a proof only against the currently registered sanctions root — strict equality, no history. Rotating the root through the timelocked migration is therefore an instant, global revocation: every proof generated against the previous root fails verification from the block of rotation onward — CRL semantics enforced by an assert, not by a policy document. The honest limits: revocation is global (the whole root, not per-address), in-flight proofs are invalidated by rotation, and a verifier-side freshness policy — accept no proof against a root older than N — is roadmap.
CISO & Auditors
"Has the code been audited? Why should we trust the cryptography?"
Trust is placed in verification, not in our word. The stack ships with 290 contract tests and 23 circuit tests, plus an adversarial attacker-model exercised on a public network — a borrowed-address proof, a fabricated sanctions root and a replayed nullifier each revert, with transaction hashes to open. Stated plainly: PROVA is a pre-market MVP, and a full external audit by a specialist firm is a declared gate before mainnet and live assets — not something claimed as already done. During a pilot your own team is invited to run the adversarial checks and review the circuits directly.

The right next step is not a signature — it is a pilot where your own engineers verify every claim on this page against your own instance.

On-chain, today · two chains

Don't trust the vendor. Read the chain — either chain.

The canonical M5 stack, deployed and verified on two independent testnets: Starknet Sepolia and Arbitrum Sepolia. Every wiring claim — which verifier the vault calls, which binding the compliance module routes to, which roots are registered — is confirmed by reading the deployed contracts' getters, and the adversarial checks are reproducible by any reviewer. The same Noir circuits and the same verification keys power both deployments; a single audit is designed to cover every chain. All contracts source-available under BUSL-1.1, converting to MIT on 2029-07-12.

circuitsNoir · depth 20 · BN254 verifierGaraga UltraHonk Cairoedition 2024_07 contractsOpenZeppelin tests290 snforge · 23 nargo E2E111 automated runs networkStarknet + Arbitrum Sepolia on-chain proof verificationlive on Sepolia

Starknet Sepolia

Testnet canonical M5 · STARK-secured, settled to Ethereum · Garaga UltraHonk
PrivacyVault M5 Canonical vault · amount-binding, dup-commitment rejection, two-step ownership
0x05c0dbf8…1963adfasource-verified
Withdrawal verifier Garaga UltraHonk · called inline by withdraw
0x04817808…123e35f0fsource-verified
Deposit verifier Amount-binding circuit · called by pre_prove_deposit
0x06053ab3…b42bfb4csource-verified
ComplianceModule Gates deposit caller and withdraw recipient
0x0647b7b7…970b1becsource-verified
OFAC root binding Live read path · sanctions root built from the U.S. Treasury SDN list · reproducible bit-for-bit · 24h timelock
0x0547b836…3b5629e1source-verified
OFAC root binding · M6 Next generation · attested fast-path · 2h veto · emergency denylist · deployed, read-path cutover in progress
0x02f93e53…c9d62b82source-verified
OFAC UltraHonk verifier Recipient-binding VK — a borrowed proof reverts
0x02dd5890…c2dfe77source-verified
SoF root binding Association root = the vault's live Merkle root, bit-identical
0x010ec682…29896aedsource-verified
SoF UltraHonk verifier Depth-20 source-of-funds circuit
0x005a3732…6e8aa073source-verified
Adversarial verification — attacker model, exercised on-chain
Honest proof, correct recipient — the system must accept
Borrowed-address proof — someone else's clearance, your exit
REVERTED · addr mismatch
Fabricated sanctions root — the empty-list attack
REVERTED · in verifier core
Replayed nullifier — spending the same note twice
REVERTED · already spent
577.6M
l2_gas per deposit — bit-for-bit identical across the automated run series. Deterministic, not estimated.
~785M
l2_gas per withdraw, including full UltraHonk proof verification inside the transaction.
111 / 111
automated deposit→withdraw cycles settled with status SUCCESS — each with a pre-flight root self-check before spending gas.

Arbitrum Sepolia

Testnet same core, ported to the EVM · BN254 precompiles native (EIP-196/197), no wrapping layer
PrivacyVault EVM deployment · address-space OFAC screening (EVM-native); Starknet enforces compliance at the perimeter
ComplianceModule Gates deposit caller and withdraw recipient
OFAC root binding Same production d20 sanctions root as Starknet — root continuity, bit-for-bit
Withdrawal verifier Honk · consumes the raw Barretenberg proof inline
0xdDD31b31…5A03Be60source-verified
Deposit-open verifier Amount-binding circuit · verified in pre_prove_deposit
0x002c20a5…8f40C74Bsource-verified
OFAC proof verifier Recipient-binding VK — a borrowed proof reverts
0x74e64849…C3EEeF3source-verified
Source-of-funds verifier Depth-20 SoF circuit · parallel provenance certificate
0xD7E1C006…41069901source-verified
Three attacks, three different defense layers — each killed by a live on-chain transaction
Honest proof, correct recipient — the system must accept accepted
Borrowed clearance → 0xdEaD recipient — someone else's OFAC pass, your exit compliance layer
REVERTED · recipient not cleared
Tampered proof (bit-flip) — the verifier must reject proof layer
REVERTED · revert 0x9fc3a218
Replayed nullifier — spending the same note twice nullifier layer
REVERTED · already spent
The borrowed-clearance attack is where PROVA differs from every privacy mixer. A blocked recipient is cut off at the compliance layer — before a single cryptographic byte is touched. The vault never even reaches the proof: an address without OFAC clearance is rejected at the gate. This is the institutional model working as designed — confidentiality built inside the compliance perimeter, not a privacy mixer with KYC bolted on afterward. After all three attacks, the second note's nullifier stayed unspent and the honest holder completed a full deposit→withdraw round with no state left behind.
910,937
gas per deposit on Arbitrum — the amount-binding proof is verified in a prior tx, keeping the hot path light.
3,943,929
gas for a full UltraHonk withdraw verification inside the transaction. OFAC clearance verifies at 3,938,329 gas — checkable on-chain.
2 / 2
full deposit→withdraw cycles settled on Arbitrum Sepolia, with the adversarial triad rejected on three distinct layers.
Live cycle · settled transactions The full deposit→withdraw flow, every step a public Arbitrum tx you can open
Set whitelist root
Pre-clear OFAC · 3,938,329 gas · witness regenerated, root match bit-for-bit
Pre-clear whitelist
Pre-prove deposit (amount-binding)
Deposit note #1 · 910,937 gas
Withdraw note #1 · 3,943,929 gas · full UltraHonk verify in-tx
Deposit note #2 · two-leaf root verified
Honest withdraw #2 · nullifier spent, vault → 0
One audited core, proven portable — the most direct way possible. A proof artifact generated for the Starknet pipeline was verified on Arbitrum unchanged — same circuits, same verification keys, same 8,640-byte proof, no intermediate proving layer. The sanctions root wired on Arbitrum is the identical production d20 root registered on Starknet — continuity proven by a bit-for-bit decimal match against the prover input, both built from the U.S. Treasury SDN list (93 ETH addresses). This is what "portable across the chains your assets live on" means concretely: the cryptography is audited once and re-used, not re-audited per chain. Only the sanctions root changes to match each jurisdiction's screening list.

shared sanctions root · 0x15bdf63fc7b1413813d7cbbab3112e5fce031724de214caaa9185381d3c53130

Who holds what

Treasury & finance desks

Hold on-chain without publishing your book.

Your book's structure and your counterparties stay sealed from competitors and front-running bots while yield accrues inside the asset — no DeFi wiring, no oracle, no rebalancing. Custody never leaves your keys: the vendor cannot pause your vault, rotate your roots, or move your funds. Not "agrees not to" — is technically unable to.

Compliance & legal

Certain at the gate. Accountable on request.

Sanctions screening enforced on both entry and exit — so no listed address can either come in or go out — an affirmative source-of-funds attestation for every note, and disclosure measured in single transactions, proven in zero knowledge when lawfully requested. Your compliance policy, your whitelist, your audit domain — with the ecosystem's viewing-key standard available on top where your supervisor expects it.

Noir circuits · BN254 Barretenberg UltraHonk Garaga on-chain verification Cairo · OpenZeppelin Starknet · settled to Ethereum No token. No fee. No custody.

Licensing

Annual licenses. You own the vault — we never can.

PROVA is infrastructure, not a custodian. Each licensee deploys and owns its own vault, verifiers and compliance policy — the owner key is yours, verifiable on-chain. We never hold your assets, your keys, or a privileged key over your deployment.

Pilot

Annual license · pricing on request
  • Single-tenant vault deployment on testnet
  • Full circuit set: withdrawal, OFAC, zkSoF, amount-binding
  • Compliance policy workshop — whitelist & association sets
  • Direct engineering support
Start a pilot

Standard

Annual license · pricing on request
  • Production deployment — owner key handed to you
  • Sanctions-root update service behind your 24h timelock
  • Association-set indexer & attestation tooling
  • Adversarial acceptance run on your own instance
Talk to us

Enterprise

Annual license · pricing on request
  • Multi-vault estates, custom compliance predicates
  • Legal-team integration & SLA
  • Dedicated circuit review with your auditors
  • Jurisdiction-specific disclosure support
Talk to us

Pilots run in weeks, not quarters

The treasury you seal today is the position nobody front-runs tomorrow.

Write to us with your asset, jurisdiction and compliance profile — we answer with a deployment plan and the contracts to verify before you sign anything.

[email protected]

Capital · selectively open

We are raising the way we build: verifiable first.

PROVA is opening its first outside round. The pitch is unusually short, because most of it is already on this page and on-chain: a live vault on a public network, an adversarial attacker model with settled transactions, a no-token, no-custody B2B licensing model, and a defined gate to mainnet — external audit, first pilots, first licenses. If your thesis is infrastructure where verification replaces trust — in the product and in the diligence — we should talk.

Request the investor memo

Private conversations with qualified investors. Nothing on this page is an offer of securities or a solicitation to purchase any instrument.