Neha Narula

Neha's Writings

2026-04-20T12:40:14+00:00

I felt kind of guilty about my last post, so I have spent a bit of time thinking about post-quantum Bitcoin. This includes:

Thinking through specifically what I think a good “roadmap” would be to get Bitcoin to a place where it is secure in the presence of a CRQC
Surveying everything that has been going on in Bitcoin-post-quantum-land
Identifying the remaining open questions

I have seen a few people construct lists or summaries of (2), and then point to them like “See! Look at all that’s happening! How could you say that there’s not enough going on?!” This is true, there is something going on. Maybe even, dare I say, LOTS going on. But how much is going on is not really the relevant question. (1) and (3) are the most important parts! What is necessary, but not yet completed, to make Bitcoin PQ-safe? What are the tradeoffs of various options and how do we choose between them? We need to know the gap from here to there: What needs to be done before we can declare Bitcoin secure in the presence of a CRQC, and are we making sufficient progress towards that?¹

In this post, I’m going to argue that we should provide a one-shot way for users to make their coins safe in the presence of a CRQC with minimal tradeoffs. We should do this even if we have not yet resolved all the questions of what to do when a CRQC appears, like how to handle coins that are still not PQ-safe.

I do not think we have to have 100% of the answers immediately, nor can we. There are different mitigations that have different tradeoffs. We should make the low-harm, low-risk, high-benefit, safety-critical mitigations NOW, and save the high-harm, high-risk mitigations for LATER, when we know with more certainty a CRQC is close.

So what should we do now, in my opinion?

Design, implement, evaluate, test, and activate a soft fork for a PQ-secure output type and signature scheme(s) for Bitcoin outputs (in conversation with wallets, L2s, and Bitcoin applications to make sure it works for them)
Coordinate developers of wallets, L2s, and Bitcoin applications (who want to) to correctly support this output type
Communicate to users why they should choose wallets, etc that support this output type and should move to this output type. Make it clear how to use this output type correctly and adapt flows to it, or when necessary, develop new flows.

If this is done, it gives Bitcoin users the ability to move their coins to a safe output type immediately, having confidence their coins are safe even if a powerful CRQC appears, without worrying about future softforks.

The best candidate for this I have seen so far is P2MR (BIP 360) in conjunction with a new PQ signature opcode and cryptographic agility (multiple branches with different signature schemes). This combination gives us the ability to say: Move your coins to this output type, and as long as you do not reveal your non-PQ-safe public key (do not reuse addresses):

Your coins will be safe in the presence of a CRQC, even if there is no future soft fork to Bitcoin (for both short and long exposure attacks!)
You can continue to use small, fast Schnorr signatures to move your coins for as long as a CRQC is not on the immediate horizon (and your coins are still PQ-safe!)

This is great. The downsides are the following:

If you reveal the Schnorr public keys inside your P2MR, this does not help keep your coins safe in the presence of a CRQC unless there is a future soft fork shutting off the insecure signature schemes. Revealing public keys might be something that certain wallets/custodial flows do in order to reuse addresses. But you can’t do that. If you think all users will do that anyway, then might as well not bother and rely on a future soft fork shutting off ECC anyway. If you think everyone does address reuse, this is equivalent in security to an alternative proposal, P2TRv2.
This eliminates one of the so-called efficient privacy benefits of P2TR. Namely, this eliminates the key spend path, which previously you could use when spending the output to pretend like there weren’t other spending conditions, even if there were. Eliminating this leaks exactly 1 additional bit of information about the output (other contract paths exist or not). If you really care, you can avoid this leak in P2MR with an additional 32 bytes, but you are losing the efficiency argument, so the incentives are no longer aligned for this to be the default.

These downsides, for the ability to say that you can go away and not come back for a long time and your coins are safe in the presence of a CRQC, seem reasonable to me. The efficient privacy loss part is annoying, but maybe we can get it back later once we are all using PQ signatures.

Bitcoin security as a common good

This can help you make your coins secure. What this does not help with is making everyone else’s coins secure if they don’t use it, or use it incorrectly. Since Bitcoin is a monetary system you should probably care about this. Most of the argument on the bitcoin-dev mailing list to date seems to be about this distinction; namely, there is an argument that if too many other people’s coins are insecure, your coins are insecure.

I am not yet sure how to think about this. At the very least I’d say it depends on exact numbers – if only 0.0001% of coins are insecure, I think Bitcoin will be fine. If 20% of coins are insecure, I think things would probably get pretty chaotic if a CRQC would appear, but I’m not totally convinced there isn’t a possible path where Bitcoin might make it through. That said, I think it would be horrible, it wouldn’t really be the Bitcoin we know today, people might lose faith in it entirely, and it’s just way too high risk to bank on.² Either way, I don’t know how many coins will remain insecure. Let’s call this percentage X. I think it’s safe to say X > 0 (not all coins will move to PQ-safe outputs), and X < 100 (at least some coins will move to PQ-safe outputs).

The nice thing about this proposal is that we can give people an option to move without having an answer to what to do if X is large. AND, we will be able to get real data. We can see who moves on chain! We obviously want to design this such that we minimize X: But even if we disagree on exactly what X might be, or what to do with who doesn’t move, we can agree to do that. We can get started on giving people a way to make X small without knowing what to do yet.

Also important to note: In order to make progress on this, we do not need to answer the question of how to provide escape-hatch-like-schemes to people who didn’t move in time but show up later and want to securely move their coins, post Q-Day. STARK proofs of HD-seed, commit/reveal, whatever. Those are all far away from being needed and orthogonal, unless you believe those solutions are so great that we should make one of them the way we handle all coins, now. I completely disagree with that. Those solutions suck, a lot. So while it’s interesting that people are looking into those, they are not the imminent fixes in front of us (and I would argue spending too much time on them is confusing and distracts everyone from what are pragmatic ways to address this problem). And, what are you going to recover your escape hatch coins to? We need a PQ-safe output option no matter what.

Most importantly, we do not have to decide what to do with people who are unlikely to show up to do anything at all (Satoshi’s coins) right now in order to make progress.³ Eventually, if a CRQC seems close, we will have to make a decision one way or the other (leave the coins to potentially be taken, freeze them, repurpose them for mining rewards, give them to me, etc. What? Just saying, it’s an option). That is going to be a difficult conversation and I’m glad we are starting it now. But resolving that conversation is not needed to make useful, meaningful progress.

Proposed roadmap for mitigations. The actions in the blue dashed boxes help with the blue triangle; the actions in the purple dashed boxes are only needed for the purple trapezoid. We cannot have PQ-safe outputs until the first activation happens; we do not need to consider whether or not to freeze coins until closer to Q-Day. Even if the second soft fork doesn’t activate, or we can’t reach agreement, the blue triangle Bitcoin is PQ-safe. Inspired by a slide from Ethan Heilman’s Cryptographic Agility talk from the 2026 MIT Bitcoin Expo or 2026 OPNEXT.

Counterarguments

There are valid reasons why you might disagree with the above as a strategy, even if you want to move forward on making Bitcoin secure in a post-quantum world (If you don’t think a CRQC is a risk worth addressing see my last post). I might discuss the most reasonable ones in more detail in a future post; for now, see the recent discussion on the mailing list. I will very briefly summarize the arguments as I understand them here:

First, you might think that P2MR is going to be too difficult for wallets to implement correctly (namely because they really like reusing addresses), so even if deployed and implemented, it will be implemented incorrectly and a significant number of wallets will not truly be PQ-safe. You mostly agree with the above strategy, you just don’t think P2MR is the specific right way to go about it.

Second, you might think the blue triangle will not be large enough (wallets won’t implement it, people won’t move), so we should spend most of our time and energy on the purple trapezoid instead. In fact, you might think the purple trapezoid is going to be so large that we might as well just wait until closer to Q-Day and cram this into one soft fork.

Third, you might think that deploying a PQ-safe output type now is in some ways “giving up” because X will still be too high, and it will make it harder to motivate people to come up with better solutions. They might not appreciate the common good point raised above.

I am not sure I am best representing the counterarguments here, because quite frankly they don’t seem like good reasons to me not to proceed. Please let me know if I missed yours. Also note that these counterarguments do not have anything to do with the question of whether to freeze or not.

See the FAQ for a shorter explanation of proposals that I do not think are as interesting, but are still worth explaining since they come up a lot (please stop bringing them up).

FAQ

Why P2MR and a new PQ-safe signature opcode? What about OP_CAT?

Yes, soft-forking in OP_CAT would also enable us to implement PQ-safe signatures manually in script, or even verify STARKs (but if this is in tapscript, you’d still need a future soft fork to shut off the taproot keypath spend, or P2MR). We need to make the distinction between technically possible and pragmatically a good idea. Encouraging this technique for all users is not a good idea: scripts would be huge and gross and unwieldy. This is not a good way forward from an efficiency perspective.

What about the QSB paper? Doesn’t that make Bitcoin quantum-safe right now?

This paper does technically provide a way for people today to move their coins to an output and script that would be safe in the presence of a CRQC without any soft forks (assuming it’s correct. I haven’t evaluated it yet, so cannot vouch for that). But see above on technical possibility vs. pragmatically a good idea. Among other concerns, this technique is expensive, like hundreds of dollars per transaction, and the transactions would be non-standard so you’d have to ship them straight to a miner, bad for decentralization. As it currently exists, this is a neat research proof of existence. It is not a good solution to make Bitcoin PQ-safe for as many people as possible.

What about specific post-quantum signature schemes? You didn’t say anything about those.

Why thank you for asking. I’m trying to keep this post manageable in size. Go watch Jonas Nick’s talk from OPNEXT about OP_CHECKSHRINCS. This seems like the most likely path forward. Basically, they’ve come up with a signature scheme that is not HORRIBLY large but requires keeping track of the number of times you signed, and is still like 5X as large as Schnorr today. If you lose track you can fall back to the really horribly large one. We probably also want a block size increase unless we want to accept half as many transactions per second (best case). I know plenty of you get riled up about that sort of thing but sorry, that’s life. Things are enormous in a PQ world and we really need to consider that as PQ signatures start having to go on chain. I’m willing to go on record saying a 2-8X block size increase is probably fine from a decentralization perspective, and we can do it as a soft fork. It is no longer 2016. I think I’d rather see that than a 2X (most optimistic) reduction in throughput.

I look forward to the BIP and people banging on the new signature scheme. People who work on wallets/L2s/etc should check this out now and see how much harder this makes your life. Also, if you can come up with a post-quantum hash-based signature scheme that’s smaller, that would be really helpful for Bitcoin!

I am very angry about BIP 361

Yes. I acknowledge your anger. The one ray of hope about what I’m saying here is that there is a possible world where we never have to make the hard decision that BIP 361 attempts to address: if either 1) a CRQC never appears or 2) almost everyone moves their coins to PQ-safe outputs (including Satoshi). Unfortunately, in the long-term, I think the likelihood of those is low. So yes, I predict we will eventually have to struggle with what to do with Satoshi’s coins, but we probably have time. And the sooner we implement PQ-safe outputs, the more time people have to move! So maybe take a look at P2MR (BIP 360) and do some deep breathing.

Aren’t you just arguing we should punt on the really hard problem?

Yes. Yes indeed. This is my strategy in life as a serial procrastinator, and honestly so far it’s worked pretty well; sometimes if you just wait your problem goes away. OK but seriously, let me make a better argument: First, we need more information before we can answer the really hard problem well. I honestly just don’t know what to do with Satoshi’s coins.⁴ In order to feel more confident one way or the other, I would want to better understand the game theory around an adversary with a CRQC, especially as it applies to miner incentives. Hint hint, someone should fund this research.

Second, we should make progress as best we can on this question now, but also acknowledge that it might not be a question for us to decide. If a CRQC doesn’t appear for 100 years, then we should not prematurely make this decision for the Bitcoin users of 100 years from now. It’ll be their Bitcoin, and their choice.

Acknowledgements

Thanks to Ethan Heilman for feedback on this post. No endorsement implied, all mistakes my own.

Edit 4/21: Thanks to Antoine Poinsot for pointing out according to BIP 360, Schnorr is the only signature option since outputs are confined to tapscript. Removed references to ECDSA above.

Footnotes

Side note: I really don’t want to say negative things about people who are trying to contribute, but I have a pet peeve about this. Just “doing things” is not always helpful. First, sometimes doing things that aren’t priorities distracts valuable review and evaluation from things that are priorities. Second, there is a lot of work required to actually get something launched. Not just invention or proof-of-concept implementation, but also design, evaluation, production implementation, testing, and activation. There is this concept of cookie-licking in research, where someone kind of starts something or vaguely describes an idea, but doesn’t actually do the the rest of the hard work of getting that idea to fruition. Then no one else wants to work on it cause the idea has been claimed. This doesn’t happen all the time, obviously, there are many examples of someone coming up with an idea and someone else picking up the mantle, but it does happen sometimes. Don’t be a cookie-licker, and don’t be afraid to pick up cookies. Or whatever. I’m not the boss of you, do whatever you want, it’s a free country. ↩
Pun intended ↩
If you believe Satoshi is not going to move their coins, this puts a floor on X > 2.9. If you believe all old P2PK is probably not going to move, X > 8.1. ↩
Before you yell at me for even considering the idea of turning off ECC (which would freeze Satoshi’s coins if they’re not moved in time), please understand that it is not something I want. Among all the horrible things described in this post, it is one of the most horrible. I am not advocating for it. I would only advocate for it if I was convinced Bitcoin as a whole cannot remain secure in a world where a powerful CRQC-adversary exists and Satoshi’s coins are vulnerable on chain (my current thinking is that this might be the case due to miner incentives for reorgs to battle for the coins. I don’t give a crap about dumping a bunch of coins on the market, this is not a good reason and I am pretty sure that’s recoverable. For example, Michael Saylor might go bankrupt and sell tomorrow, and no one is going to make an argument to freeze his coins). So if the option is “no Bitcoin” or “disable ECC (which is about to be badly broken) on Bitcoin, with years of warning” I would choose the latter. But I don’t know that’s the choice in front of us to make, yet. Others might have more certainty one way or the other. ↩

Neha's Writings

2026-04-03T12:42:14+00:00

Bitcoin’s signatures are broken if a cryptographically-relevant quantum computer (CRQC) were to appear tomorrow.¹ Bitcoin requires changes both to its code and to everyone’s wallets (at least a soft fork and many users moving coins to different types of addresses) to be secure in the presence of a CRQC.²

The remaining uncertainty is in two main areas: timeline and how to address this. I will frame these two issues in the following way:

What is the likelihood of a CRQC appearing, and on what timeframe?
What are the best paths for Bitcoin successfully upgrading so that it would not be broken in the presence of a CRQC, and at what cost to Bitcoin? What is the set of tradeoffs, and how should Bitcoin navigate this space of tradeoffs?

I think the following:

The chance of (1) is non-zero for various timeframes
We do not yet know the answer to (2), we don’t know if there will be agreement on how to navigate the tradeoffs once there is a defined set of possible paths forward, and it’s not clear there is agreement to even do anything. Therefore, it is not 100% clear that Bitcoin will successfully upgrade before a CRQC appears.

An important implication if you believe the, I think, pretty reasonable previous statements is:

A CRQC is an existential threat to Bitcoin (you might believe this is very low-likehood). Your measurement of this threat should literally be:

(A) How likely you think it is a CRQC appears by a given time, multiplied by
(B) How likely it is you think Bitcoin will not successfully upgrade by that time.

Let’s put in some example numbers: Google recently introduced a timeline for moving to PQC by 2029 and a coauthor on a recent Google Quantum paper suggested he wouldn’t bet against a 10% chance of a CRQC existing by 2030 (A=.1). The last soft fork in Bitcoin (taproot) took 3 years and 10 months from proposal to activation. It was several more months (sometimes years) before wallets and large exchanges started supporting Taproot. Maybe there’s a 50% chance we could successfully roll out some as-yet-unknown PQ soft fork + wallet upgrade + migration by 2029 (B=.5).³ If you believe these numbers there is at least a 5% chance (0.1*0.5=0.05) you should expect Bitcoin to no longer work due to a CRQC in 2030.

How to think about this as an investor

I personally care more about using Bitcoin than its price, but I know many of you do care about Bitcoin’s price and this has implications on it: This probability of Bitcoin no longer working is a floor for how much you should value Bitcoin at $0. There are many additional reasons to potentially value Bitcoin at $0, which is why I say floor. This should additively combine with all the other types of uncertainty you have about Bitcoin’s continued successful operation: keys might get stolen or hacked (yours or someone else’s, like Coinbase’s), Ethereum might overtake Bitcoin’s narrative as digital gold and render it irrelevant, someone might partition the network and conduct numerous destructive double spend attacks, cryptoeconomic security might break down by 2140 when the block reward drops to 0 and we have continuous block sniping attacks, etc etc etc…

IANAI (I am not an investor, also none of this is financial advice) but my understanding is most competent investors take this sort of thing into account when evaluating assets and creating their portfolios. You can fill in whatever values for A and B you think make sense and place your bets accordingly.

How to think about this as a user

Even if you don’t really care about the Bitcoin price, a lot of the above thinking applies even if you just want to use or build on Bitcoin. Some cryptographers are already saying they won’t bother working on non post-quantum cryptography anymore. It’s hard to convince people to work on and engage with Bitcoin when it might be completely broken in a few years.

Moving forward

Assuming you think A is greater than 0, the clearest way to eliminate this existential threat is to make B zero and upgrade Bitcoin to post-quantum cryptography as soon as safely possible, specifically the supported signature schemes. The good news is PQ signature schemes exist and are usable! The bad news is there are many other valid things to worry about, so it’s not as simple as it sounds. I want to be clear that there are a few people doing important work in this area, but as far as I know it’s a very, very small number. As of today these questions remain unanswered:

Which specific signature scheme(s) should we use in Bitcoin? Unclear. Most of these schemes produce significantly larger signatures or require longer to verify. Choosing non-optimally might have downsides, like significantly increasing the cost to run a node, throttling Bitcoin’s supported number of transactions per second and available blockspace, or limiting future Bitcoin functionality like signature aggregation.
How should consensus consider transactions spending UTXOs that haven’t upgraded to PQ-schemes? Even more unclear. Choosing badly on this front might violate Bitcoin’s core principles, thereby reducing trust in Bitcoin’s narrative of self-sovereignty and scarcity, or could render the economic security of Bitcoin mining unsound.
What are the exact steps and timeline(s) to add in optionality for PQ-signature schemes, and then to presumably require them? Unclear. Do it too soon and you might accidentally pick non-optimal cryptographic primitives. Do it too late and Bitcoin is broken or it’s a mad rush.
Before it’s very close to Q-day, how do you motivate wallets to actually make the effort to implement these upgrades and support the new schemes? Not sure! It’s worth making this clearer: Bitcoin doesn’t support PQ signatures now, a soft fork is necessary to even enable that. But that’s just consensus validity on the Bitcoin network. There’s an entire ecosystem of wallets, exchanges, and custodians that need to upgrade their software and systems to support transactions and addresses using the new PQ signatures. And then people need to actually move their coins on the blockchain away from insecure signature types. Fun times.

Which makes this all frustrating, and exciting! If you think A is basically 0, I get why you don’t want to bother with all this complexity. There is real overhead and risk to switching to post-quantum cryptography that needs to be weighed against the risk of Bitcoin breaking in the future. I do not have the background or interest to evaluate A from first principles myself, and I don’t trust most people on the internet to be able to do this effectively either. I rely on the expertise of others who I know and trust. On a long enough timeframe, A gets high enough that it becomes a question of when, not if, Bitcoin should upgrade. Based on this, let me make my position clear: I think A is high enough to warrant prioritizing designing, implementing, and evaluating post-quantum signature schemes and consensus upgrades in Bitcoin now.

I think investors are also probably going to listen to the experts and price in this risk, so even if you believe A is 0, if you care about the medium-term price of Bitcoin it’s probably in your best interest to either convince the experts they are wrong (good luck!), convince all the other investors not to listen to the experts, or get onboard with getting B to 0.

Some common “counterarguments”

Q: A quantum computer destroying Bitcoin is FUD.

A: There certainly are many untrue claims out there, and it’s very frustrating to see headlines like “⚠️GOOGLE SAYS A QUANTUM ATTACK ON BITCOIN TAKES JUST 9 MINS WITH A 41% SUCCESS RATE” (this is not true. you cannot attack Bitcoin this way today).

But there’s also some truth to what’s going on. You have to filter out what’s just plain incorrect, on both sides. Calling everything FUD is lazy and unhelpful.

Q: Isn’t there a chance a CRQC might never exist?

A: Yes! Totally! But the word “might” is doing a lot of heavy lifting here. Unfortunately for Bitcoin there is also a non-trivial chance one will exist. Like I said above, according to a quantum computing researcher at Google, a 10% chance by 2030. To be clear, there will need to be a lot of work done and crazy advances made before one exists, and this is why A is not 1 for any short time frames. But I have found it’s not wise to bet against smart people figuring things out. For the reasons I described already, I think this chance is significant enough to warrant preparing for it if you still want Bitcoin to work.

Q: Yeah ok but they can’t even factor 21 yet. Why should we do anything now?

A: Sometimes your intuitions in one area don’t apply in another area. Turns out this is simply the wrong way to think about quantum computing progress. I think Scott puts it well:

Once you understand quantum fault-tolerance, asking “so when are you going to factor 35 with Shor’s algorithm?” becomes sort of like asking the Manhattan Project physicists in 1943, “so when are you going to produce at least a small nuclear explosion?”

More on why this is the wrong intuition and waiting till CRQC’s can factor larger and larger numbers might be the wrong strategy.

Q: A CRQC also breaks banking, military communications, and most of the internet today! If one appears, isn’t Bitcoin the least of our problems?

A: True! Banking software, military communications, and the internet also need to be upgraded. I have high confidence they will be, successfully (I’d put my B_{HTTPS}, the odds that HTTPS will not upgrade in time, at close to 0). Unfortunately, I have less confidence that Bitcoin will upgrade successfully since upgrading a decentralized system of honey-badger-like participants is much more challenging and people like the questioner seem to think this is a valid argument that we shouldn’t even worry about it?

If you disagree and think there will be a CRQC and the rest of the internet won’t upgrade successfully, maybe you should consider shorting the stock market and buying gold. But not Bitcoin, because if we do nothing that won’t work anymore. Not investment advice.

Q: This is probably just Google trying to destroy Bitcoin.

A: It’s possible for the following two things to both be true: “Google wants to destroy Bitcoin” AND “Google’s paper is technically sound”. The former does not negate the latter.

I personally do not think Google cares much about Bitcoin outside of thinking it’s a great use case to demonstrate quantum prowess, but if you’d like to bet both that (1) this result is a psyops by Google to take Bitcoin down, and (2) all the authors are willing to compromise their reputations by putting out a paper with no actual technical merit, you do you.

Q: Even if Google (or a nation-state) had a CRQC, why would they steal Bitcoin? Everyone would see it and it would tank the price!

A: It’s pretty hard to speculate with any level of accuracy about how exactly a CRQC adversary would or would not engage with Bitcoin. There could be many motivations for various action paths, including an incentive to keep the CRQC secret and not touch Bitcoin for a while. You should factor your beliefs about this into your A. I think the real point is that in the presence of a CRQC, Bitcoin’s signatures are broken, and we cannot rule out the worst case (or even articulate the entire adversary strategy space).

Q: Stealing is illegal, so why would anyone use a CRQC to steal Bitcoin?

A: If you truly believe this, you really should value Bitcoin at 0 – it has many unnecessary components with a lot of overhead, like proof-of-work and digital signatures.

Q: Bitcoin will figure this out. The “developers” have fixed things in the past.

A: OK, great. How? Who is doing this? What’s the plan? Which primitives? Why those over others? Where is the discussion and resolution of the tradeoffs I mention above beyond a few threads on the mailing list? Do you agree with everything in BIP 360? If not, what are your concerns and what do you propose instead? What do we do with P2PK coins that are vulnerable and probably won’t move, like Satoshi’s? Where are the designs, BIPs, implementations, and evaluations of various options?

Q: Well what are you doing about it?⁴

A: So far not much! Trying to inform myself, encouraging other people who are working on it, and writing this post to hopefully convince more people to work on it. My work on Bitcoin is through my role at MIT running DCI. Maybe we should try to work on some of the technical challenges, or fundraise and hire people to work on this specifically. Should we? Are you interested?

What are you doing about it?

Acknowledgements

Thanks to Ethan Heilman for feedback and many conversations on these topics. No endorsement implied, all mistakes are my own.

Edit 4/3/2026: A previous version of this post mistakenly cited the Google paper as saying “there is a 10% likelihood of a CRQC (can break a Bitcoin ECDSA or Schnorr key with reasonable likelihood in 9 minutes) by 2029 (A=.1).” That’s been corrected above; the Google paper did not make this claim, an author on the paper did for 2030. Thanks to @UnseenNight for pointing this out!

Edit 4/4/2026: Thanks to Troy Cross for pointing out this post made it sound like most of the time and effort in upgrading Bitcoin to be PQ is figuring out and activating a PQ soft fork. There’s still a lot to be done after that to make coins safe, like upgrading wallets and exchanges, and actually moving coins on the blockchain. Made that clearer above, though it deserves more discussion and I might update this post or write another one later.

Edit 4/9/2026: You might like this post by cryptography engineer Filippo Valsorda. There is overlap with my post, probably because we appear to be in violent agreement.

Footnotes

Though this statement is true, I’m not trying to scare you or say Bitcoin is currently broken. The likelihood of a CRQC appearing tomorrow is basically 0. Bitcoin is not currently broken. ↩
I don’t think the previous statements are controversial, but if you do disagree let me know! The rest of this post will probably not be interesting to you, but perhaps I need to write a different one explaining why they are true. ↩
Given what I’m seeing on X these days and the lack of developers working on it right now I think I’m being REALLY generous here. ↩
I think it’s totally fair to call this sort of thing out, but will also note that it doesn’t engage with or invalidate any of the actual arguments. ↩

Neha's Writings

2025-12-14T16:56:00+00:00

The following are remarks I gave at the 2025 DC Privacy Summit. TL;DR we don’t talk enough about potential dystopian outcomes for privacy tech. It’s not an answer by itself, we probably need thoughtful policy. Watch the remarks here and a fireside chat with Commissioner Peirce here. Thanks to Mike Orcutt for inviting me and writing this thoughtful summary of the event.

Here’s a scenario some of us have lived: You use Signal because it’s encrypted. You’ve turned on disappearing messages. Then someone screenshots your chat and shares it (or you accidentally add a reporter). All that encryption didn’t help at all. This illustrates something crucial we often miss in privacy conversations. When we talk about privacy today, the conversation quickly turns to technology: encryption, verifiable credentials, zero-knowledge proofs, multi-party computation, fully homomorphic encryption. I work on some of these technologies, and they are extraordinary. But we need to be precise about what they can and cannot do.

Limits

Take zero-knowledge proofs. They let you show that a computation was carried out correctly without revealing the underlying data. Yet they don’t tell you whether the data itself is accurate or complete. They don’t preclude the need for an authority to source that data, like a government indicating citizenship. The mere use of verifiable credentials cannot prevent an authoritarian government from denying some of its citizens that credential, or stop a platform from using the credential to kick certain types of people off. In blockchains, cryptographic techniques like ZKPs are uniquely powerful because consensus and computation together define ground truth, at least as it pertains to the blockchain. A proof of correct computation is definitionally always correct, no single source of authority required. But the rest of the world doesn’t work that way, and, honestly, that’s a feature, not a bug. In the real world we still depend on people and organizations, and reality to define what data is “correct.”

Privacy tech as a tool for control?

Here’s what worries me most: if used unwisely, instead of reinforcing autonomy, these cryptographic tools may help replace it with automated control.

Imagine a world where producing cryptographic proofs is easy and automatic, and so asking for them becomes routine. You need to prove you’re creditworthy to use a rideshare app. You have to prove your health status to enter a building. Prove your spending patterns to get insurance. Prove your income to access a dating platform. Services ask for proofs of income, political affiliation, or health because they can, and users might not even think about whether or not they should comply, because it’s automatic and easy to do.

The fact that these requests don’t leak specific data makes them feel more acceptable. Over time, the ability to prove becomes an expectation. A technology originally designed to help with privacy turns into continuous permissioning. We could end up in a world where constant proving replaces constant disclosure. The information is hidden, but the control remains.

Why markets won’t save us

Even if we get the technology and rules around how to use it right, technology does not operate in a vacuum. Unfortunately, markets don’t reward privacy. Individuals are often unwilling to pay for it, they favor convenience and ease of use. Platforms favor access to data so they can monetize it. And there’s a circular benefit where the more data, the better the results, and the more users prefer the less private service. So even if we have the right technology, the reality of market forces means it might not get adopted.

Where policy can help

This is why the mere existence of technology is not enough. Privacy requires not just good cryptography, but good law. We have to work within the frameworks of law and policy as well, and I think this should happen in three ways.

Stop criminalizing the creation and use of privacy-preserving technologies. There is still a belief in many circles that tools like CoinJoin and privacy coins are only for criminals, and that running software to help users unlink transactions is somehow wrong. There is a fundamental lack of understanding of how unprivate the default is.

Here’s an example: Imagine that a user gets paid by their employer on-chain in bitcoin. The employer can then directly observe how the user further spends that money on-chain, and might be able to see, for example, if a user pays to a well-known charity address or a medical professional. It makes perfect sense that users would not want this and would try to employ techniques to avoid it.

This is especially important because we need to make the use of privacy-preserving systems the norm, not the exception. It cannot be treated as a red flag.
Establish legal protections for user rights like self-custody and data portability. It is important to protect the ability to control one’s own assets and information without being forced through intermediaries who must report on them.

Right now, the default assumption in regulation is that intermediaries are necessary surveillance points. But individuals can custody their own assets and manage their own data directly, and this is important to promote competition. We should enshrine the right to self-custody without it being treated as inherently suspicious, create real data portability requirements, and not require that every participant route through a monitoring gatekeeper.
Stop mandating that private-sector intermediaries engage in specific data collection. More broadly, stop using the private sector as an extension of law enforcement. Many existing laws assume that gathering and storing personal data–often in very specific formats–is the only way to ensure accountability. This is overly prescriptive and also not true. This means revisiting laws like the Bank Secrecy Act.

This is not about rejecting oversight entirely, or ignoring risks. It is about starting from the question that should guide both technologists and regulators: what are we actually trying to achieve? If the goal is to prevent harm, detect fraud, and preserve fairness, we know there are ways to do that that do not rely on continuous data collection.

Technology can protect privacy, but only if we also carefully design our systems, markets, and laws to respect it.

Neha's Writings

2025-08-28T04:31:14+00:00

I have been doing a deep dive on how money is defined and how it works. I am more focused on fundamental definitions of money, currency, and payments, and less so on monetary policy. Here is my reading list, with some notes. This is not a thorough literature review and I am not recommending all of the ideas put forth. There are probably many important things I’m missing (I’d appreciate you pointing them out – email me at narula@gmail.com). This is what I found interesting and is helping to shape my understanding.

Brief aside on the economics definition of money and its inadequacy

As you probably know, the classical economics “definition” of money is as a medium of exchange, unit of account, and store of value.¹ This seems to have first been put forth in 1876 in Jevons’ Money and the Mechanism of Exchange. There is wide debate over which of these three functions is primary, and I put “definition” in quotes because this does not actually describe what money is or how to define money, it only describes three functions of money we have observed over time. The functions are neither exclusive nor complete, and it’s unclear why they all need to be satisfied by the same thing (money). To me this makes for a pretty weak definition, and I think we can do better.

I personally like the way Keynes seems to define money, as the most liquid asset among all assets. However from what I can tell there is a bit of a circular definition here, because liquidity is defined as the ability to convert something into the medium of exchange, which is money.

At some point, the definitions of money start to focus on the state and central banks. This puzzles me because the idea of central banking as it exists today is not that old and money obviously existed and was in wide use before the first central bank.² It seems to me quite likely that there have been and will in the future be widely-used forms of money that do not originate from the state or central banks (perhaps instead from a decentralized network of computers running common software with algorithmic issuance…).

Readings and my thoughts

This is in chronological order.

As introduced above, Jevons wrote a thorough explanation of money in Money and the Mechanism of Exchange, published in 1876. I’ve only skimmed this so I won’t say much, except he talks about both money as various commodities as well as paper money, promissory notes, and banking systems. However, he dedicates more of the book to the properties of commodity money, and he distinguishes money from credit, which he sees as a promise to pay money. I am very sympathetic to this quote remarking on the futility (and I’d add, danger!) of trying to define “money” too simply:

All such attempts at definition seem to me to involve the logical blunder of supposing that we may, by settling the meaning of a single word, avoid all the complex differences and various conditions of many things, each requiring its own definition. Bullion, standard coin, token coin, convertible and inconvertible notes, legal tender and not legal tender, cheques of several kinds, mercantile bills, exchequer bills, stock certificates, etc., are all things capable of being received in payment of a debt, if the debtor is willing to pay and the creditor to receive them; but they are, nevertheless, different kinds of things. By calling some money and some not, we do not save ourselves from the consideration of their complex legal and economical differences.

In 1892, Carl Menger wrote a very nice article “On the origin of money” where he almost defines money as the most liquid commodity, but doesn’t seem to have the word “liquidity” yet (he says “saleableness”). However, he doesn’t discuss debt (arguably the most widely used form of money today is commercial bank liabilities) and focuses on money as arising out of a set of commodities in a market. This is known as the commodity view of money. The story here goes that primitive societies were bartering but it was very annoying because maybe you had three chickens and I had two pigs and I wanted chickens but you didn’t want pigs, you wanted wheat, so we couldn’t trade. This is called the “double coincidence of wants” problem (this originates in Jevons). Those who ascribe to this theory of money think that eventually some commodity (like metal), which was scarce and easy to demarcate and store, naturally arose as the medium everyone converted to and in which they priced their goods.

While a nice story, it seems like it’s totally bunk (see Mitchell-Innes and Graeber below). Historians and anthropologists have later shown that there does not seem to be historical evidence that money arose this way in societies. It is a total fiction. For some reason economics textbooks still propagate this story (IMHO they should stop, it’s confusing).

In 1905, Knapp wrote The State Theory of Money, which I have not yet read but include because it seems influential in MMT; the general idea of Chartalism (which I’m not even sure Knapp espouses fully) is that money only arises by the decree of state authority. This seems demonstrably false to me given historical indications of the use of shells, beads, etc for money, and the way money has evolved in groups of people without states requiring payment in taxes – money does not seem to strictly require a state, even if most of the money we use today (and throughout much of history) is rooted in issuance by the state. That said, money is a social convention, and it seems inarguable that the state has a lot of power in the issuance and management of systems of money.

In 1913, A. Mitchell-Innes wrote “What is Money?”, a very nice piece which I think is the first to debunk the commodity theory of money and the idea that money arose out of barter, and propose the credit theory of money.³ If you want to continue to push for the commodity theory of money, I suggest you read this and provide a convincing argument rebutting his points. However, Mitchell-Innes also says “credit and credit alone is money” which I’m not quite convinced of yet, and he seems overly optimistic about a system of debtors and creditors being able to regulate itself without intervention. He has this somewhat spicy quote at the end: “The governments of the world have, in fact, conspired together to make a corner in gold and to hold it up at a prohibitive price, to the great profit of the mine owners and the loss of the rest of mankind”. Mitchell-Innes would probably feel similarly about Bitcoin today.

Edit: I had the wrong Keynes reference! Replaced with the correct one, and the text edited to reflect that.

In 1936, the formidable John Maynard Keynes released The General Theory of Employment, Interest, and Money. This is a tour de force which is about much more than just defining money. I am still reading this; also I originally confused it with A Treatise on Money which I believe Keynes moved beyond. The following comments apply to A Treatise on Money: there was some back-and-forth with Hayek, who was perhaps more rooted in Menger. Here we see money still being defined as a thing which has its roots in the commodity theory of money, even though Keynes goes well beyond that. He says “To-day all civilised money is, beyond the possibility of dispute, chartalist”. I think the word “civilized” is doing a lot of heavy lifting there; part of my frustration with reading about definitions of money by economists is that they seem to switch back and forth between describing a theory of money that can persist throughout circumstance and time, and merely describing some portion of the monies as they operate in their time. I am more interested in the former.

Keynes defines commodity money, fiat money, and managed money; unfortunately he describes fiat money as something in which (1) its monetary value is much higher than its intrinsic value and (2) is created and issued by the state. (1) doesn’t seem quite right to me since gold, a commodity, has a monetary value divorced from its intrinsic value. (2) doesn’t seem right either since the wide variety of cryptocurrencies seems like an existence proof of fiat not issued by a state. I think this is yet another instance of over-categorization. But perhaps this critique is nitpicky and irrelevant to his contributions, I’m still reading.

The General Theory of Employment, Interest, and Money gets at this idea of money being the most liquid asset, which seems much more reasonable to me. The demand for money is driven by the demand for liquidity, and people hold money in part because of uncertaintly about the future. This drives the interest rate, which can be seen as the price of money. An interesting conclusion of this is that money is not neutral; it affects employment. And there are situations where monetary policy is ineffective; when people are so uncertain about the future they would rather hold money than invest. I think the Monetarists, like Milton Friedman, later rejected this framing.

In 1989, John Hicks wrote A Market Theory of Money, which I have not yet read, but anecdotally heard influenced Mehrling (see below) and came highly recommended. I hope to read it and have more to say about it soon.

Kocherlakota has a really beautiful paper “Money is memory” from 1996. It shows that any allocation with money could be implemented by a system with unlimited memory. This equivalence is cool and thought-provoking.

Kahn and Roberds, in 2009, wrote a paper modeling payment systems and links to monetary systems, “Why pay? An introduction to payments economics”. I like this treatment very much because medium of exchange (payment) is a predominant function of money, payment systems are quite important to the economy, and I think the technological underpinnings of money are underdiscussed. I’m also curious about the difference between “money” and “payments” which generally in the literature seem to be distinguished as “objects” and “rails” for messaging.

They distinguish payments as a system on top of money, which arose because there might not be enough money available to immediately settle all trades, and there might be limited enforcement of pledges about future behavior (I’ll pay you later, promise). They note that payment systems might start to extend and redefine money. They distinguish between store-of-value and account-based systems (and later Kahn writes about tokens and accounts).

I’m not sure I agree with the way they define payments; I think viewing money as an object, especially digital money, is misleading. It seems to me that under their definitions, if you could have a monetary system with sufficiently high velocity (which seems doable with technology these days – what do you need, 10M TPS? 100M?), you would not need a payment system? That’s a weird conclusion. Maybe payment systems are money? If you’ve talked to me you know I also hate the terms “token” and “account” in digital currency and think they have caused a lot of confusion. We will be writing more about that later.

This paper sort of gives me the impression that the study of payments is not necessarily held in the highest esteem in economics; payments are seen as plumbing: necessary but not as interesting, as say, monetary theory. This is unfortunate!

In 2011 David Graeber published Debt: The First 5000 Years, a sweeping account of the history of money and debt. He makes the case that debt and accounting predate cash, coins, and barter (starting with the Sumer in 3500 BC). I mentioned this here because it’s widely known, but so far I think it’s sufficient to read Mitchell-Innes. I’m only about a quarter through it though.

In 2012, Mehrling proposed a very nice way of looking at current forms of money in his paper “The Inherent Hierarchy of Money”. He frames money as a hierarchy of credit/debt offered by institutions at different levels. Mehrling doesn’t cite Mitchell-Innes directly but I see this as an extension of that line of thinking. Mehrling’s structure is very elegant and makes a ton of sense to me to describe our current system for money, but I’m not sure it encompasses all forms of money. Perhaps with a slight expansion of the framework, relaxing the pyramid to a directed cyclic graph, it could. Something I’m mulling over.

I found Hull and Sattath’s 2023 article “The properties of contemporary money” useful to think about properties of money and to find older discussions on the definitions of money. They frequently quote Jevons and use his definitions.

Finally, the Bank for International Settlements seems to offer a new definition of the viability of a monetary system in Chapter 3 of their 2025 Annual Economic Report, in which they describe important properties of a monetary system as singleness, elasticity, and integrity, and make the claim that stablecoins do not have these properties. I refer you to the paper for definitions of the properties and discussion. I disagree with this framing as a definition of money (e.g., money has never historically required built-in mechanisms for enforcing integrity against financial crime, like KYC and AML. If they’d defined integrity as anti-counterfeiting mechanisms I would have been more sympathetic, but they don’t), and also with their conclusion that stablecoins lack the properties, and thus are ill-suited to be money. But that’s a longer discussion.

Interesting questions

How do mainstream economists today view Jevons? What do they still agree with, and what do they discount? For example, they seem to have moved beyond the commodity theory of money, yet they still use Jevons’ three functions to define money. Why?
Is all money credit? Why or why not?
How can there be such disagreement on the nature of money between different economists who were all educated in overlapping economics PhD programs in the United States? MMT seems fundamentally at odds with the mainstream view of central banking, which seems at odds with free banking. How can members of a purportedly scientific discipline reach such widely varying conclusions? What are the differing assumptions that cause these different conclusions? Are any of them falsifiable, and can they be tested?
Historians and anthropologists have added important ideas to the discussion of money. What might computer scientists add, if anything? Perhaps something about the operation of payment systems? We seem to be contributing to cryptocurrency. What does that say about money? Is there something more theoretical or fundamental to say about money as a networked system of information?
I am missing a more math-based treatment of money by economists. My understanding is that often money is just a variable in an equation, and perplexingly, money is not needed in some of the more interesting theories, like Arrow-Debreu. What are the right things to read here?

Finally, what did I get wrong or misunderstand? What am I missing?

Thanks to Dan Aronoff, Jon Frost, Charles Kahn, Josh Redstone, and Lana Swartz for interesting discussions and pointers to readings. I make no claim to represent their views and all mistakes are my own.

Reading list in one place

Jevons, W. Stanley. “Money and the Mechanism of Exchange.” In General Equilibrium Models of Monetary Economies, pp. 55-65. Academic Press, 1989.

Menger, Carl. “On the Origin of Money.” The Economic Journal 2, no. 6 (1892): 239-255.

Mitchell-Innes, Alfred. What is money? New York: Banking Law Journal (1913).

Knapp, Georg Friedrich. “The state theory of money.” (1924).

Keynes, John Maynard. The general theory of employment, interest, and money. Palgrave Macmillan, 1936.

Hicks, John. A market theory of money. OUP Oxford, 1989.

Kocherlakota, Narayana R. “Money is memory.” Journal of economic theory 81, no. 2 (1998): 232-251.

Kahn, Charles M., and William Roberds. “Why pay? An introduction to payments economics.” Journal of Financial Intermediation 18, no. 1 (2009): 1-23.

Graeber, David. Debt: the first 5,000 years. Melville House, 2011.

Mehrling, Perry. “The inherent hierarchy of money.” Social fairness and economics (2013): 394-404.

Hull, Isaiah, and Or Sattath. “The properties of contemporary money.” Journal of Economic Surveys 38, no. 4 (2024): 1132-1155.

BIS Annual Economic Report (2025).

Footnotes

Jevons had a fourth function, a standard of deferred payment. I’m not sure why this has been dropped over time – maybe because it is subsumed by unit of account? ↩
The oldest central bank, the Sveriges Riksbank, was founded in 1688. The Federal Reserve did not exist until 1913, though the First Bank of the United States was chartered in 1791 with various stops and restarts until the Fed. ↩
He goes so far as to say “no scientific theory has ever been put forward which was more completely lacking in foundation”. ↩

Neha's Writings

2025-05-20T11:34:14+00:00

Ark is a design to scale payments on Bitcoin. There are several explanations out there about Ark, but I couldn’t understand most of them, so I wrote my own. I also summarize how different opcode soft forks can help improve Ark properties, and compare Ark with other designs to address scalability like Lightning and rollups.

Motivation

Imagine you want to enable many users to share an on-chain UTXO, making payments with little on-chain footprint. You also want to do this in a non-custodial manner, so each user should be able to unilaterally exit from the shared UTXO to their own on-chain UTXO any time they want.

Why might you want this? Well, Lightning lets you make off-chain payments non-custodially, but it has some issues around liquidity and it still requires a UTXO per user. If successful, the UTXO set size on Bitcon nodes will be a constraint in the future: all validating nodes need to store the UTXO set in order to validate transactions. Right now there are ~170M UTXOs and the serialized size of the UTXO set is ~11GiB. Back-of-the-envelope if every person in the world had just one UTXO, the serialized size of the UTXO set size would grow to be half a terabyte, which is not awesome for something on the critical path for validation.¹

There have been designs proposing how users might share UTXOs, like coinpools, but they require all users to be online to sign to change the balances in the coinpool. Ark makes it so not all users have to be online to sign if a user wants to enter or exit the pool, or if they want to change the balances in the pool. It does so by using multiple shared UTXOs (over rounds, and in transaction trees) and creating a role for a privileged operator, S. This design enables many scalable payments by having many users working together with the same S. If S cooperates, many users can make many payments to each other in the pool, batched into only a single, small on-chain transaction every round. Even if S doesn’t cooperate, the users can exit to their own on-chain UTXO without S’s permission (assuming they can pay the appropriate fees to do so).

However, there are a few stipulations to this:

Like Lightning, there is an added liveness requirement; users need to come online every so often or they might relinquish their funds. This period can be set to a while, like a month. We call this the refresh period.
Exiting on-chain might be more expensive for the user than even a simple on-chain payment transaction, because it actually requires multiple on-chain transactions. We hope this doesn’t happen much and instead most payments are made cooperatively in the pool.
To exit non-cooperatively, the user needs to have enough UTXOs lying around to pay the fees to get their transactions onchain
S needs to be online and provide extra liquidity (in the amount of the payment volume) for as long as the refresh period. So there is a trade-off: a shorter refresh period is better for liquidity costs to the server (and thus, presumably, Ark fees which get passed on to users) but this means users have to come online more often.

S does not sequence a rollup—there is no state machine of payments in an execution of the protocol. Instead, S creates commitments to trees of exit transactions by posting the root of each tree (a shared UTXO) every so often, in rounds. One way this is unlike a rollup is because previous trees might still have valid exit paths for users.

There are many variants of Ark with different trade-offs. I describe one here, then describe another if you add CTV, which reduces interactivity, and then another with CTV and CSFS, which helps interactivity even more.²

Ark protocol

There is an Ark operator S and users A, B, C, … The pool, or Ark, has the following operations: Join, Transfer, Refresh, Exit. Users join the Ark by spending to a special transaction with S, and pay each other by interacting with S. S posts commitments to different transaction trees on-chain, and users hold off-chain transactions to unilaterally exit the Ark. Exiting can be cooperative or non-cooperative (based on S). Everything described here will maintain the following properties: 1) users don’t trust S with custody; they can always exit with their funds within the refresh period and 2) S doesn’t rely on users to get its money out eventually.

This description does not discuss what are sometimes called “Arkoor” or “out of round” payments, which have lower latency but require the recipient of a payment to assume S and the spender don’t collude. We are making no such assumptions here (this also originally confused me; I thought Ark required this assumption for any payment, making the threat model more like statechains. It does not). This means that unlike Lightning, Ark payments are pretty high latency.

I use bold to indicate Bitcoin transactions, that might be broadcast and confirmed, or might be held off chain. There are four main types of transactions: join, exit, forfeit, and round.

Joining the Ark

Alice joins the Ark by spending some of her coins to S in the following way: she asks S to co-sign an exit transaction and posts a join transaction on-chain. It works as follows: A uses her own UTXO as input (let’s say 7 BTC). The join transaction has an output with a clause requiring a signature from both A and S, which we shorthand as (A+S). Off-chain, Alice keeps an exit transaction taking this output as input and spending to the following clause: (A+S or A w/ $\delta$). Alice asks S to sign exit, then signs and posts join on-chain. See here for Second Lab’s figure showing the transactions (they call join “Onboard”):

The first time threshold is a relative time, $\delta$, using CSV. This is the time a user has to wait until they can get their money out of the Ark if S doesn’t cooperate. This is also the time in which S needs to come online in order to sweep forfeit transactions, which we’ll describe later. In the picture above, this is two days.

Once join has confirmed, Alice has joined S’s Ark and can make cheap payments:

S knows that join can only be otherwise spent by the exit transaction described above (because of the multisig in join).
Alice knows she can always broadcast the S-signed exit transaction to exit the Ark and issue another transaction getting her money back in $\delta$ time.

Ark rounds

We’ll add two more times:

An expiry time, $\Delta$. This is the required refresh period, and the amount of time S has to front liquidity for payments. After this time, S can sweep any outstanding round transactions or trees (described later). This is an absolute time, usually set to something like a month in the future. A user who has made payments needs to come back online within this time and either Transfer, Refresh, or Exit in order to prevent their money from being taken.

A round time. This is the time between on-chain round transactions by S, which ensure commitment of user payments or refreshes. This is one component of the user-perceived latency for transactions. This should be a lot less than the refresh period (maybe an hour or a day). It is not present as relative or absolute time locks in script, so I don’t bother giving it a variable.

Every round time, S makes a new on-chain transaction round handling and batching any Transfer, Refresh, and Exit operations. round commits to a new tree with the appropriate exit transactions.

If nothing happens besides Alice joining the Ark, then there don’t need to be any round transactions. Alice is in S’s Ark by herself. Let’s say Bob also joins S’s Ark with 1 BTC, and Alice wants to pay Bob.

Payments

Alice and Bob are already in an Ark, Alice with 7 BTC and Bob 1 BTC, and Alice wants to pay Bob .5 BTC.

Alice and Bob agree to terms for some sort of payment, and Bob shares his public key with Alice.
Alice tells S about this request for payment, sharing her and Bob’s public keys
Time passes. S waits until it is ready to make the next round transaction, collecting many of these requests into a batch
Once ready, S creates a new round transaction, the structure of which is described below. S needs to include its own new inputs to fully fund this transaction.
S shows the relevant branches of the transaction tree to Alice and Bob (and every user in this batch), and asks Alice and Bob (and each user) to sign the appropriate transactions in their branch of the tree and forfeit transactions (described below). These forfeits apply to the exit transactions Alice and Bob have for their respective 7 BTC and 1 BTC in the Ark, from previous joins (or rounds).
Once S received all appropriate signatures, S broadcasts the root transaction round to get it confirmed in a Bitcoin block, keeping the rest of the tree off chain.
round’s confirmation is the commit point for Alice’s payment to Bob – at this point Alice no longer has 7 BTC in the Ark, she has 6.5 BTC, and Bob no longer has 1 BTC—he has 1.5 BTC.

Round transaction tree and forfeits

round is a transaction with inputs supplied by S and two outputs, each a shared UTXO, with one output committing to the left side of the transaction tree and one committing to the right (you could imagine a k-way tree with k outputs instead of a binary tree). Each shared UTXO output’s clause is of the form (u+v+w…+S or S after $\Delta$) for the users in that shared UTXO, dividing the users in half (or by k) each level down. There is a leaf output in the tree for each user u whose balance has changed or who is refreshing in this round. Each leaf output has clause (u+S or S after $\Delta$), and an exit transaction which spends this output; recall, for a user like Alice her exit is a transaction spending to an output with a clause (A+S or A w/ $\delta$).

See this picture from Second Lab’s documentation for a visualization of a tree with users A, B, C, and D and 10 BTC.³

A forfeit transaction essentially cancels a user’s exit path in a round. It spends from the multisig clause of the exit transaction in the previous relevant round, to S, with no delays.

There is also a Refresh operation so a user can reset their expiry time. This is just like a user is making a payment to themselves. They relinquish their exit path in the previous (soon to expire) round transaction, and get a new one in a round transaction that expires later.

Atomicity

What I’ve described above is actually not safe.

Once S has a signed forfeit transaction from Alice, it could just never put the new round on chain, and it could broadcast the forfeit if Alice tries to exit a previous round, taking her money. This means Alice has no way to unilaterally exit! What we want is for forfeit to only be valid if the new round is on chain. This is done using connector outputs: Each forfeit should take as an additional input a dust-value output that is only created in the new round. So we add a bunch of connector outputs to the round transaction (one per forfeit).

Once a round transaction is on-chain, S has what it needs (connector outputs) to complete the input set for signed forfeits it holds from Transfers, Refreshes, and Exits from previous rounds, and it has effectively “canceled” those exit transactions.

A few things to note here:

First, annoyingly, Alice and Bob have to wait for a while between when they ask to make a payment until the transaction tree is actually constructed, and they need to be back online later right before the round is broadcast in order to sign the tree and forfeit, and give the signatures to S. Not only is it pretty interactive to make a payment, the users have to be online for the whole duration of the round. And to get the most batching benefit, S probably wants to wait a while to collect as many payments as possible. So users need to be online for a while.

Second, as you might have noticed, if even one user doesn’t show up to sign, S has to reconstruct the transaction tree for round to leave them out and get new signatures from everyone else. This is pretty bad, just one user each round can keep S from making progress. CTV helps by making it so only the spenders have to be online, and CTV+CSFS help remove this requirement entirely.

Exiting the Ark

To cooperatively exit, a user signs a forfeit depending upon an output paying them in the next round instead of a connector output.

To non-cooperatively exit, a user broadcasts the transactions that have not yet been confirmed in the path from their relevant transaction tree root round to their exit transaction. They might have to add fees. Some of these transactions might already be on chain if other users have exited. They will also have to wait a relative amount of time from when the exit is confirmed ($\delta$) to then spend the output. What prevents a user from broadcasting an old, out of date exit path? This $\delta$ and the forfeit transaction! If a user broadcasts an old exit path, they will have to wait $\delta$ for the clause where they can unilaterally spend the funds. S can immediately broadcast the relevant forfeit transaction and claim the output, without waiting $\delta$.

In most of the articles describing Ark, they call the exit (and the path to it from round) a VTXO, or Virtual UTXO, and say a user “holds” VTXOs. I find this sort of confusing, honestly, because in the optimistic case a user doesn’t really spend their VTXOs the way they do actual UTXOs in transactions. Instead they forfeit them and get new ones.

S sweeping funds

S can immediately get all of the money it fronted for a round back in one transaction after $\Delta$ (spending back to itself), as long as there have been no non-cooperative exits. If even one user has exited the round non-cooperatively (broadcasting their exit path on-chain) then S can only get the non-exited funds back, by opening up the rest of the transaction tree and putting siblings on-chain.

Adding Assumptions for Better Properties

CTV

If we had CTV, we can replace the multisigs with CTVs for the child transactions. This changes interactivity in the following places:

Joining the Ark: Alice doesn’t have to get S to co-sign the exit, A+S in join can be a CTV to exit
Users don’t have to sign the relevant paths in the transaction tree, but it doesn’t help interactivity that much because they still have to get the paths from S (after it has constructed the whole tree) before signing their forfeit transactions.⁴

One could do an Ark variant where Bob, the recipient, does not need to be online to receive a payment, because he doesn’t have to be in the multisig. Bob shouldn’t consider the payment complete (release any goods to Alice) until he knows he can exit the Ark: He needs to know about the structure of round and have the appropriate exit transaction for himself, but he doesn’t need to acknowledge anything to securely commit the payment. We change the steps from before as follows:

Reminder, Alice and Bob are already in an Ark, Alice with 7 BTC and Bob 1 BTC, and Alice wants to pay Bob .5 BTC.

Alice and Bob agree to terms for the payment, and Bob shares his public key with Alice. This could happen at any point in the past, and then Bob can go offline.
Alice tells S about this request for payment, sharing her and Bob’s public keys.
Time passes. S waits until it is ready to make the next round transaction, collecting many of these requests into a batch
Once ready, S creates a new round transaction. S needs to include its own new inputs to fully fund this transaction.
S shows the relevant branches of the transaction tree to Alice (and every spender in this batch), and asks Alice (and each spender) to sign a forfeit transaction (they don’t have to sign anything in the branches because of CTV). Alice’s forfeit applies to the exit transaction Alice has for her 7 BTC in the Ark. THIS IS DIFFERENT FROM BEFORE: Bob is not going to forfeit his previous 1 BTC balance. He is going to keep that, and gain a new exit path for an incremental 0.5 BTC that Alice is paying him. Because he doesn’t forfeit anything he doesn’t need to be online for this part.
Once S receives all appropriate signatures, S broadcasts the root transaction round to get it confirmed in a Bitcoin block, keeping the rest of the tree off chain. round’s confirmation is the commit point for Alice’s payment to Bob—at this point Alice no longer has 7 BTC in the Ark, she has 6.5 BTC.
Bob shouldn’t release the goods to Alice until Alice both points to this transaction on chain and shares with him his branch (exit path) to his additional 0.5 BTC in the Ark.

Note that this is nicer than before because Bob doesn’t have to be online to get paid, and we’ve removed the recipients from the set of users who can keep a round from progressing (by not showing up at the end of the round to sign forfeit transactions).

CTV and CSFS

Adding CTV and CSFS enables rebindable signatures, which one can use to implement a variation called Erk. The general idea is that it’s safe for users to sign a variation on the forfeit transaction (called refund transactions in that post) before seeing the transaction tree because they know they’ll get paid back one way or the other. This changes the interactivity requirements a lot—users don’t have to stick around for the duration of the round.

Assuming S and the spender don’t collude

This enables Ark out-of-round, or Arkoor transactions, which are “instant”. I’m not interested in this assumption so I’m not going to go into detail on how this works, you can read about them here.

Note that Second Labs currently only implements Arkoor transactions for payments. If you don’t want to add this assumption as a recipient, you should come online and refresh in the next round before you consider yourself paid. I originally thought this was a bigger deal than it is; it’s really just an implementation detail.

How Ark compares

Lightning

Benefits of Ark:

A really nice property of Ark is that Bob doesn’t need to have any liquidity in order to receive a payment! In contrast, in Lightning, if Bob doesn’t already have a funded channel, someone would need to front Bob liquidity to create a payment channel where Bob can receive.
Another nice property is that Bob doesn’t have to be online to receive a payment (in the CTV variant). He just needs to come online before the refresh period.
Another nice property of Ark is that we don’t have to worry at all about channel balances and routing. All that complexity goes away. This means I’d expect to see a much higher rate of successful payments in Ark than in Lightning.

Benefits of Lightning:

In Lightning, if you can’t come online in time but you’ve only been spending, you’re fine (all previous states show you having more money than the current state). In Ark, if you can’t come online in time you could lose all your money.
Ark doesn’t have the same low latency as Lightning with the same security assumptions.
Unlike Lightning, Bob and Alice cannot transact peer-to-peer. They require S’s cooperation to make an off-chain payment. It’s kind of like if all users in an Ark are connected through a single Lightning hub, and not with each other.

Incomparable:

The more users in an Ark, the more likely a payment can be satisfied off-chain, and the better scalability improvement. These payments have no additional on-chain footprint! But more users in one Ark probably makes it more likely a user might fail and S has to recompute a round.

Also something important to note is that it seems like designs for multiparty channels in Lightning (another way for multiple users to share a UTXO) are sort of “running into” incremental design changes to Ark. One way to think of this is imagine that the round transaction tree in Ark contained Lightning channel opens at the leaves. This is interesting and I’d like to understand this better but thus far I find the Lightning multi-party channels designs inscrutable.

Rollups on Bitcoin

This is a lot fuzzier to me because I haven’t read detailed rollup designs yet. Future post. Here are some speculative thoughts:

Benefits of Ark:

Ark has way less data posted on-chai —rollup on-chain data is proportional to off-chain payments (specifically, state diffs). Ark and Lightning on-chain data are not.
Ark doesn’t require a soft fork to be fully non-custodial. Current rollup designs require that at least one out of n operators is honest.⁵

Benefits of rollups:

Less interactivity. The rollup operator doesn’t have to talk to all the users making payments multiple times to get them to sign things. Without a soft fork, Ark requires multiple rounds of interactivity with all the users who are transferring, refreshing, or exiting every round (not all the users in the Ark, at least)
Rollups can have a totally different transaction model and virtual machine, so they can offer new functionality like privacy-preserving payments (zkCoins) or smart contracts.
Ark relies on users to hold their exit paths (if they lose this data, then they can’t exit the Ark non-cooperatively). Bitcoin rollups pay higher on-chain storage costs so users don’t have to do this.

Not sure / TBD:

Non-cooperative exit costs, and how this amortizes across users. In Ark if S totally fails multiple transaction trees need to go on-chain so users can exit. Not sure what happens if in a (non-custodial, so assume a future with CAT) rollup the sequencer fails (current rollups have a one-honest-operator requirement and cannot tolerate all operators failing)—since all data is on-chain, presumably someone else could just step in? Also, rollups can be designed so that if a challenger is doing an “honest” non-cooperative exit, the operator has to pay the on-chain assertion costs. But still, it takes up chain space, and I’m not clear on how much that is compared to Ark trees.
I’d like to better understand the liquidity requirements of S in Ark vs. the rollup operators. Not entirely clear on that. Also unclear to me how the liquidity needs might be split between multiple operators.

Acknowledgements

Thanks to Antoine Poinsot for very helpfully whiteboarding Ark with me, Greg Sanders for explaining Ark in a Bitcoin scalability working group, and Antoine Poinsot, Jose Storopoli, Ethan Heilman, and Armin Sabouri for feedback on this post (no endorsement implied). All mistakes are my own.

References I found helpful:

Footnotes

You can’t currently prune this like you can the blockchain, but maybe ideas like Utreexo could help by changing the storage and lookup costs for validation in the future (by making other tradeoffs). That’s a different post. ↩
I describe CTV and CSFS here, since they are (imho) the most straightforward. APO can simulate CTV and CTV and CSFS. ↩
I think the BTC values are incorrect for A, B, C and D in the exit transactions, they should be swapped ↩
Side note: I wonder if there is a way to incrementally build the tree so users don’t have to stick around the whole round, with just CTV? ↩
Or crazy things like functional encryption covenants or ColliderScript. ↩

Neha's Writings

2025-05-15T16:00:00+00:00

Gold vaults

A year ago I toured the gold vault beneath the New York Fed. You might recall it from the classic 1995 movie Die Hard with a Vengeance, but in case you aren’t familiar: It’s the world’s largest depository of monetary gold, storing over 6,000 tons 80 feet below Manhattan and protected by airtight vaults and its own police force.

The first thing I thought when I was down there was wow, gold is very shiny. The second was wow, gold bars are surprisingly heavy, in part because of its density (bars are 28 pounds). They make you wear metal shoe covers to hold one in case you drop it on your foot. But the third thing I thought is “THIS is what the global monetary system rests on? This is just so antiquated.”

The New York Fed gold vault has some surprising similarities to Bitcoin:

Pseudonymity: Each country’s holdings of gold are held in separate compartments that are identified by numbers, not names.
Multisig: Each compartment is secured by a padlock, two combination locks and an auditor’s seal, each under the control of someone different so multiple people have to come together to open the compartment.
Transaction fee model: Storage is free, but you pay to move gold bars in and out or between compartments. So HODLers free ride, which honestly makes me worry about its long-term sustainability.
Vaults: It has multi-layered vault technology with timelocks! There is a 90 ton steel cylinder door, and once closed, it locks the vault till the next business day. And it’s an airtight and watertight seal.

But there’s a really important difference between the gold vault and Bitcoin. The gold vault is only available to governments, central banks, and official international institutions. Bitcoin is for anyone. We’re not just trying to digitize the gold vault. We’re trying to build something better.

Sometimes, though, we get distracted along the way. We get distracted by CEOs of $10 trillion+ asset managers name-dropping “Bitcoin” on CNBC or billionaires taking on debt to hoard coins or nation-state strategic reserves, we mistake all that for progress. But it’s not. Those things are second-order effects of progress. First-order progress is, and always was, USERS. Providing real value to real people. All the financialization, all the follow-on by institutions, it’s a side-effect, it’s not the real goal. Too often we forget that and chase the mirage.

Reflecting on MIT

Universities and academia are in a bit of a strange place right now. I am not really sure they’ll all survive (nor that they all should). But MIT is unique and well-positioned to weather the uncertainty facing higher education. The motto of MIT is “mens et manus”, or mind and hand. It signifies the fusion of the pursuit of academic knowledge with practical purpose. I feel grateful to have been trained here in graduate school, and I am so grateful for all the wonderful students, researchers, and staff I’ve gotten to work with at the Digital Currency Initiative. We all chose to be part of this quirky, earnest group trying to make a better financial system for everyone. Because of how special it is, I think MIT is in a unique place to contribute to this field, even more so than other schools.

Our field could use a little more mens et manus. Yes, the theory and protocol design are incredibly important. There is still so much to figure out and do. But the users are the real point. We have to solve real problems for real users.

If what we have in 50 years is the New York Fed Bitcoin vault, but users can’t easily and safely self-custody—we failed. If we build only for traders and whales and ignore those who need privacy, autonomy, and access—we failed. Also, quite frankly, it’s uninteresting: We’d just be replicating the existing structure of the financial system we’re trying to fix.

I don’t know if whatever we’re seeking is possible to achieve at scale, but I don’t know that it’s impossible either, and I’m not willing to give up yet.

The DCI has been steadily supporting senior Bitcoin developers for 10 years. The people who worked here have been quietly, but measurably, improving the Bitcoin network’s stability, scalability, and security. I hope the DCI is still at MIT in another 10 years—doing work that improves strong self-custody, privacy, and security, but also helps improve access to Bitcoin and other digital currencies as part of an open, permissionless financial system, a platform on which application developers can build services and applications that give users the tools they need to financially flourish.

If this mission resonates with you, reach out. We’re always looking for collaborators. And if you have the means, consider supporting our work—we raise all our own funding.

Neha's Writings

2021-09-23T13:52:14+00:00

The term “stablecoin” typically refers to tokens issued on a blockchain which are designed to maintain a stable value with respect to an existing currency, for example the dollar. The largest stablecoins currently are Tether and USDC, with total token values of $69B and $30B, respectively.¹

There is generally a reasonable understanding of the financial risks involved in stablecoins, particularly around whether the stablecoin is fully backed, and the liquidity of those assets backing it. What I have not heard discussed are the technical risks associated with stablecoins, which is what this post covers. I specifically focus on stablecoins issued by centralized entities who custody backing assets, not algorithmic stablecoins (such as Dai, issued by MakerDAO), though some of these issues apply to those stablecoins as well.

Even centralized stablecoins operate as software running on decentralized blockchains, and it’s important to keep in mind that stablecoins involve layers of software that are not used in traditional financial institution activity. If this software doesn’t operate safely and securely, or if the decentralized networks don’t operate as expected, there could be a loss of confidence in the stablecoin or even outright theft. As it stands now, regulators, issuers, and users of a stablecoin need to understand stablecoin software and the underlying blockchain platforms they run on in order to accurately measure technical and operational risk.

Three important parts of the system to consider are the underlying blockchain, the stablecoin smart contract, and the stablecoin provider’s minting and redemption process.

The underlying blockchain

Stablecoins run as smart contracts on blockchains. In many cases what we call one stablecoin (for example, Tether or USDC) runs on multiple different blockchains, as entirely separate tokens sharing a single backing. Users can choose which token on which blockchain to obtain, but some might be easier to obtain or use than others, as the tokens are accepted in smart contracts or as payment individually. Each blockchain is used as an accounting of who currently controls a stablecoin token. For example, USDC runs on five different chains: Ethereum (27.5B USDC), Algorand (345M USDC), Solana (2.9B USDC), Stellar (161M USDC), and Tron (206M USDC), with the intention of adding ten more.² There is no “universal” USDC token—each USDC token is specific to one of these chains. This is often a point of confusion; for example CoinMarketcap mistakenly says that “All of the USDCs in circulation are actually ERC-20 tokens, which can be found on the Ethereum blockchain.”³ This could be because Coinbase, one of the largest US cryptocurrency exchanges, currently only sells USDC issued on the Ethereum blockchain. However, Centre’s own website says that “USD Coin is an ERC-20 stablecoin,” which is not true of USDC issued on other chains.⁴

The choice of blockchain is not a mere implementation detail. These chains have vastly different architectures, languages, dependencies, cryptography, miners or validator sets, and fees. As described below, the operation of the blockchain can affect a user’s ability to use the stablecoin effectively. It is unclear whether enough information is always conveyed to the user to distinguish between the individual features and risks these different blockchain technologies introduce as the user engages with different stablecoin tokens built on top of the blockchain networks.

Security guarantees. Each blockchain makes different assumptions about the miners and/or validators. For example, Tron relies on 27 rotating validators who “are entrusted to become the next block validators and maintain the blockchain history.”⁵ Unfortunately, in some cases the chain’s correctness (there is always one chain and everyone sees it) and liveness (one can get a transaction processed in a reasonable amount of time) guarantees will no longer hold if even a minority (one third) of validators collude.

This, and other factors, can affect the ability to even get a stablecoin transaction onto the chain. Miners or validators might collude to actively censor or prevent certain transactions, for example, one that is issued to upgrade the software of the smart contract to fix bugs. Or, miners or validators could prevent specific issuance, transfer, or withdrawal transactions. This doesn’t necessarily affect the stablecoin reserves, or backing, but could cause disruption and confusion about token ownership and prevent the stablecoin from operating effectively.

Bugs. All software has bugs. As a recent example, the blockchain Solana was down for 17 hours due to exploit of a resource exhaustion bug,⁶ meaning that for that period of time no one could settle any transactions on Solana, including Solana-issued stablecoin transactions (such as USDC). We wrote recently about addressing bugs and vulnerabilities in blockchain ecosystems.⁷ It is unclear whether users understand how to evaluate different blockchain developer communities for development best practices (including testing, detecting bugs, and deploying fixes).

Fees. Decentralized blockchain networks charge transaction fees, which float according to market prices for blockchain space. The fee on Ethereum for a USDT ERC-20 transfer is currently $9.75 and for a USDC ERC-20 transfer is $10.25.⁸ Note that fees are paid in the native blockchain medium (in this case, ETH) though when using a service they might quote fees in other tokens or even USD (as we did here). Fees will rise if overall transaction volume on Ethereum grows—whether related to stablecoins or via other tokens or contracts—without a corresponding increase in transaction capacity.⁹ This might even unexpectedly render some stablecoin token accounts as unusable “dust”–of a value where it is no longer economically viable to transfer them, given the fees on the blockchain to do so. Fees also can spike temporarily, which might make it hard for users to predict when they will be able to afford to transfer their tokens.¹⁰

Stablecoin smart contracts

On Ethereum and some other blockchains, each stablecoin has its own set of smart contracts. These contracts control the issuance, redemption, transfer, and blacklisting (for example, due to sanctions compliance) of the stablecoin tokens issued on this blockchain. These smart contracts are critical to tracking stablecoin ownership. There have been many cases of funds being frozen or hacked in smart contracts;¹¹ as such there needs to be processes in place for auditing this software and understanding the upgrade and deployment process (note that this is a completely different task from auditing the existence or composition of the backing reserves). There should be a recovery process plan in place for if the contract is hacked.

Minting and redemption

Stablecoin providers need to have a process for minting and redeeming stablecoins, usually connected to functionality in the smart contract, but requiring sensitive private keys. There are several risks and questions to address around the minting and redemption procedures, and the threat model behind them:

Where are keys stored and what is the access control and authorization needed to access them (e.g. physical access, remote with password, OTP, some combination)?
How many keys need to be compromised at once to compromise the processes, and how likely is that to occur?
What safeguards are in place, for example in-contract limiting of minting or redemption amounts over time?
How is recovery handled if the stablecoin provider loses access to the minting and redemption keys, or contract upgrade keys?

With all of these components, has the developer team run practice scenarios responding to bugs in the blockchain, smart contract, or minting and redemption processes? Might trading on exchanges need to be halted if compromise occurs, and is there a communication plan in place? Is there an estimate of the impact to the users of other smart contracts and financial instruments which use the stablecoin?

In stablecoins, blockchains are just accounting

Stablecoins rely on some backing and a stablecoin provider to redeem stablecoins. Usually, in the redemption process, the provider gives other funds (for example, an ACH, wire, or Bitcoin transfer) to the person who can show they control the stablecoin token on the blockchain after they transfer it back to the provider. But if the blockchain and the stablecoin provider disagree about token ownership, who wins? What responsibility does the stablecoin backing-holder (which might even be different from the provider) actually have to honor the state of the blockchain for redemptions?

Users need to understand how the stablecoin provider will mediate conflicting state—if there is disagreement (for example, due to an attack), who gets restitution, who doesn’t, and how is this determined?

Risk to the underlying blockchain from large stablecoins

Interestingly, the blockchain itself might be at risk if a stablecoin which runs on it becomes too big, especially compared to the monetary base of the blockchain’s native token. Stablecoin providers can have influence on the blockchain’s governance by only honoring the version of the stablecoin on one side of a blockchain fork, for example, even if it is not the side that most blockchain users prefer.¹² Or, a stablecoin issuer could choose to honor tokens on either side in different ways. For example, they could honor the first token to be redeemed on either side and cancel the corresponding token on the other side. They could reject all transfers and redemptions during a time of uncertainty until a clear “victor” emerges. They could split the backing between the two forks.

Additionally, it is unclear how a very large stablecoin might affect the blockchain’s underlying security incentives, especially if miners (or stakers) are processing large stablecoin transactions but are rewarded (or slashed) in amounts denominated in the smaller, less valuable blockchain token. This might cause more incentive for miners or validators to conduct double spend attacks.

There is also a regulatory risk. If stablecoins grow large and are deemed systemically important, an argument could be made that the blockchains they run upon are also systemically important. This might increase attempts to regulate decentralized blockchain networks.

Conclusion

This might come off as critical of decentralized blockchains. To be clear, I think this area is enormously exciting and has a lot of potential, and I don’t really see how stablecoins that run on permissioned blockchains or private networks have anything new to offer. However, it’s clear that many of those deciding if and how to regulate centralized stablecoins do not necessarily have access to unbiased information on how the various technologies work, nor the threat models behind them.

Thanks to members of the Digital Currency Initiative and others for useful conversation and feedback, and in particular Tadge Dryja for raising the point about stablecoins’ potential impact on the underlying blockchain. All errors are my own.

Messari lists USDT at 71B, but Coinmarketcap says $69 as of September 24, 2021. ↩
Centre Consortium. Announcing USDC on Ten New Platforms. June 29, 2021. Linked explorers accessed as of September 23, 2021. ↩
Coinmarketcap. What is USD Coin (USDC)? Accessed September 19,2021. ↩
Centre Consortium. www.centre.io. Accessed September 24, 2021. https://archive.ph/QRiQA. ↩
Behrens, Alex. USDC on TRON: High-Speed, On-Chain Value Transfers. September 14, 2021. ↩
Ossinger, Joanna. Solana Promises ‘Detailed Post-Mortem’ After 17-Hour Outage. Bloomberg, September 15, 2021. ↩
Böhme, Rainer, Lisa Eckey, Tyler Moore, Neha Narula, Tim Ruffing, and Aviv Zohar. Responsible vulnerability disclosure in cryptocurrencies. Communications of the ACM 63, no. 10 (2020): 62-71. ↩
Gasnow. Accessed September 19, 2021. https://archive.ph/M5zP3 ↩
Layer 2 solutions (Lightning, rollups, etc) might help increase transaction capacity, but require new assumptions (sometimes economic) ↩
Note that blockchain fees do not apply if the token is merely transferred across accounts inside the same intermediary, like an exchange. This is because the exchange retains custody of the token on the blockchain and simply changes ownership on its own internal accounts. This is much like a bank transfer between accounts within the same bank. However, while they appear similar in the most optimistic scenario, stablecoin deposits at exchanges may not be individually insured. This is very different from underlying currency deposits at a bank, which typically are guaranteed by an agency of the issuing sovereign itself (e.g. FDIC deposit insurance in the U.S.). ↩
O’Leary, Rachel-Rose. Brain Freeze? Parity Bug Continues With No Easy Solution in Sight. Coindesk, November 24, 2017. ↩
Lee, Leland and Haseeb Qureshi. Ethereum is now unforkable, thanks to DeFi. October 31, 2019. ↩