Ironwood might be the compliance win we haven't talked about yet

General
1

Hi everyone,
Something I keep thinking about Ironwood - we built something that quietly answers one of the biggest questions regulators and exchanges have had about Zcash, and I don’t think we’ve said it out loud yet.

Orchard had a bug where someone could theoretically have minted counterfeit ZEC without it ever showing up on chain. Ironwood (NU6.3) closed that off on July 28 at block 3,428,143 - new pool, old Orchard locked to withdrawals only, and a turnstile that makes sure nothing comes out of Orchard that wasn’t actually put in.

What I find genuinely exciting about that is the turnstile isn’t just a security patch, it’s proof. It lets anyone check that the shielded supply is sound without anyone having to reveal who sent what to who. That’s a real answer to the thing exchanges usually cite when they drop privacy coins - not “we don’t like privacy,” but “we can’t verify this is clean.” Viewing keys already helped with that for individual transactions, and now Ironwood adds the same kind of assurance at the supply level.

I think that’s worth putting in front of the people already doing policy work here, PGPZ and the folks behind the compliance-tooling grants (CompZ, Shielded Compliance Bridge). Ironwood already proves the idea they’re building toward.

Has anyone already made this case to an exchange or regulator? And would it be worth a short writeup aimed at compliance teams specifically, separate from the general Ironwood explainer we already have? Would love to hear what others think.

5 Likes
2

Hmm… :thinking: What regulators (and so anyone who wants to be compliant) don’t really want is fungibility. Paper money has serial numbers, so gold bars. Transparent ledgers have traceable history from emission to the latest address / contract. Private transactions in Zcash break the rules. View keys can show the subgraph around a node, not the whole path / network. So I don’t think Ironwood changes anything in the eyes of the regulator. Zec is like a (metal) coin, embeds features of both physical and digital worlds, and the regulator will have to reckon with them.

My 2 cents.

3

Ironic, considering cents are a form of money that fully fungible.

Seriously, though, US paper money, or for that matter, most paper money, are fundamentally bearer tokens, and thus they are not bound to any person, nor are required to be non-fungible.

In constitutional law, that’s be Miller v. Race, that ruled that you have no right to request a specific bill from someone, because legally, all bills are the same in the context of monetary transactions, establishing that bills are fundamentally completely fungible.

Due to this, 18 USC 981 allows the federal government to convict you even if they did not find the EXACT bill(s) of money in your possession, as long as they can prove beyond a reasonable doubt that the given bill(s) or token(s) are substantially equivalent to the amount in litigation and can be reasonably found that these are likely to be the same money, no matter how many times they have changed hands.

Instead, I believe the issue is not fungibility itself, it’s the fact that fungibility relies on specific media that can be guaranteed to represent value, and as such, be represented in bound assets to a specific person.

An interesting analogue will be the US Treasury bills: they used to be bearer too, but unlike paper money, whose transfers could be tangibly seen as a chain of custody in the regulations following the Bank Secrecy Acts, the transfer of a Treasury bill could be done without any record of the same because Treasury bills could be traded. You could set up a derivatives contract that paid out T-bills at some point in the future, and then transfer the contract to a third party company who would redeem the contract at some point, and distribute the T-bills, which broke the chain of custody completely as the money exited in bearer form without registration.

They solved this by requiring end-user registration for T-bills, even though they knew that the cash existed and was analogue to T-bills in the form that they could be swapped.

So the issue remains that they cannot establish a chain of custody, not that Zcash is fungible, which is why I believe IVKs serve as an adequate (for now) solution to the transparency problem. As long as regulators have a chain of legitimate IVKs or a proof of end-to-end transfer over Zcash, the fact that cash (the non-chain-of-custody) Zcash exists shouldn’t bother them.

Again, this is only what ideally should be. I, of course, cannot comment on any potentail agendas.

1 Like
4

It’s a bit early, since the high-level security properties are not rigorously proven yet (see the Guide to the Ironwood Formalization and Ledger Security Games pages of the Ironwood book for their current status). It shouldn’t be long though.

2 Likes
5

This is an interesting perspective

I think the strongest part is that supply integrity can be verified without sacrificing transaction privacy

A short document written specifically for exchanges and compliance teams could be useful because the technical explanation and the compliance explanation are probably two very different things

Would also be interesting to hear whether any exchanges have already been approached with the Ironwood changes

1 Like
6

@daira I wrote this assuming the security properties were settled since Ironwood is live on mainnet, but sounds like the formal verification is still in progress, not finished. Thanks for the links, I’ll read through the formalization guide and the ledger security games page.

7

@jenkin I hear you, but I’d push back a little on “view keys don’t matter because they’re only a subgraph.” In practice, that’s not what exchanges have actually been asking for. They’re not demanding full network traceability like a serial-numbered bill, they’re asking “can you show me the flow into and out of this specific account when we need it.” A viewing key answers exactly that question, and it’s specifically why some exchanges relisted ZEC after dropping it. So the bar in practice has been narrower than full fungibility-style traceability, and Zcash already clears it for the relationships that matter (exchange to user).

Ironwood doesn’t change that story, agreed, that’s a separate axis. What it adds is a second, independent guarantee, supply soundness, that nothing else in the ecosystem offered before. Not claiming it solves fungibility, just that between the two (viewing keys for account-level transparency, Ironwood for supply integrity) Zcash is answering more of the actual questions regulators ask in practice, even if it never satisfies the full serial-number model you’re describing.

1 Like
8

@strahncryptography This is a great breakdown, thank you. Though Miller v. Race is real and it’s exactly the right precedent for “holder in due course,” but it’s 1758 English common law, not U.S. constitutional law. It came into American law through the common-law tradition and the UCC, not the Constitution. Doesn’t change your point at all.
Everything else lines up for me, especially the T-bill example. That’s actually a really clean parallel: T-bills were bearer instruments too until the BSA-era shift to registration, and what regulators were solving for was chain-of-custody, not the fact that the instrument itself was fungible. That maps well onto Zcash. IVKs give you exactly that, a way to produce a chain-of-custody record on demand without the whole system being registered by default.
So I think we agree more than the original wording made it look like: I was calling it a “fungibility” problem, you’re right that it’s really a custody/registration problem, and IVKs are the mechanism that addresses it. Appreciate you laying out the legal reasoning, that’s a sharper way to describe what’s actually happening.

9

@CryptoEpoch Appreciate that, and agreed on the compliance-team document, though after daira’s point earlier in the thread I think that’s a “not yet” rather than a “no.” The formal verification of Ironwood’s security properties isn’t finished, so putting this in front of an exchange or regulator now would be getting ahead of the actual proof. Once that’s done I do think a short, plain-language writeup aimed at compliance teams specifically (separate from the technical explainer) would be worth doing, you’re right that those are two very different audiences with different questions.
To your last question, no, not that I’m aware of, and given the above I don’t think anyone should be yet.

1 Like
10

This reads like- are you just proxying an AI?
Because it looks like it and all it does is really add nothing to the conversation.

But yeah, it is English common law, but it is still frequently cited in US law too.

1 Like