tBTC redemption mechanism design flaw

General
1

This is an excerpt from the Threshold blog with the relevant portion for this conversation. This is a place for the Threshold community to start brainstorming better solutions for this mechanism or discuss eliminating it entirely.

https://blog.threshold.network/a-tale-of-two-bugs/

The second bug — redemption mechanism design flaw

The second bug became apparent as we prepared the first patch.

The Threshold DAO can delegate to multiple approver addresses in the WalletCoordinatorcontract.

Unfortunately, as of today, there has only been one delegation to a single maintainer address — a single point of failure. Today, that address is controlled by a US-owned company, disallowed from approving the FTX-associated redemption.

Fixing the mechanism design

Only having a single delegated approver with $25M in TVL was an oversight. Still, the bigger issue is the mechanism design itself.

Any system relying on the explicit approval of a redemption is bound to have another issue like this. When the protocol first shipped, the rationale for an approval mechanism was speed and user friendliness — alternatives meant a worse user experience.

I don’t believe the current system has made the right tradeoffs.

There are two clear approaches to fixing this flaw

  1. Move from an approval-based flow to a veto-based flow
  2. Remove all redemption review at the protocol level

I believe the safest mechanism design, going forward, is something I call “optimistic redemptions”. Instead of a list of addresses that finalize redemptions, we have a list of addresses than can veto a redemption — similar to the Guardian role in optimistic minting.

With this mechanism in place, all redemptions are valid by default. If a redemption is vetoed due to a suspected bridge hack, it can be delayed. If it’s vetoed by enough guardians, it can fall back to a token-holder vote. If the veto is upheld by a token holder vote, the rejected tBTC redemption can be automatically returned to the redeeming user.

The downside is that this hypothetical mechanism requires an additional delay for each redemption. Over time, though, that delay could be shrunk to as little as 15 minutes, and entirely waived for small transactions.

Finally, if and when the community judges the system secure without a redemption review period, it could eliminate the delay altogether, smoothly migrating from the first approach to the second. In fact, I think a clear schedule to removing redemption review would help build confidence across the community.

However this mechanism design flaw is resolved, we’ve learned a ton from this experience ­— and I’m glad we learned it this week rather than 10x from here.

What next?

The DAO and community have decisions to make.

Whether the community decides to add another approver address, upgrade the contracts to an “optimistic redemption”-style mechanism, or research and consider other options, as a dev team, we’re here to advise, and help build a more robust, secure, and neutral future of finance, together.

2 Likes
2

I’m not a fan of gate keepers that could stop me getting my BTC back without an extremely high barrier being met.

I think there are several scenarios to consider

  1. A hacker trying to exit from Ethereum to Bitcoin
  2. A hacker who finds an exploit in TBTC to drain funds
  3. A rouge / hacked / compelled Guardian

Under normal operation I would imagine that the time from exploit detections to exiting funds in scenario 1 would usually be to short for a Guardian to react.

In scenario 2 I would expect alarms to be sounding for network operators to then delay

  • large transactions.
  • high volume transactions from one address.

Its a hard balance of some safety rails while the system gets battle tested vs being fully permissionless. IMHO there should be a clear timeline to removing any safety rails that act as gate keepers.

If adopting a philosophy of progressive decentralisation I think there should be a maximum time in which the guardians can be in place. As the TVL increases I believe there is a risk of increased reluctance to remove all the guard rails, so a hard deadline will influences the design choices.

I think keeping the guardians should be able to be extended once with an onchain DAO vote with a predetermined fixed time extension.

Because scenario 3 is a risk when having some doxxed participants I believe that a single guardian should only be able to delay the transaction to allow time for additional guardians to weigh in to eventually escalate to a DAO vote.

3 Likes
3

Seconded.

I like the idea of a programmatic timeline here… eg

  1. Upgrade from today’s approval mechanism to a veto mechanism
  2. Veto mechanism needs 3 vetoes to move to a “long veto”. Eg first delays 8 hours, the second 24, the third brings it to a token holder vote.
  3. The veto mechanism starts with a delay of 2 hours, with a step function down to 30 minutes over the first 12 months.
  4. Unless the DAO votes otherwise in advance, at 18 months, the veto mechanism drops to a delay of 0, completely removing the ability of guardians to delay or veto.

The reason we had approvals in the first place is to prevent hacks in the tBTC bridge — that’s it. That need is still very real.

4 Likes
4

What is the estimated time to deployment (development + audit(s)) for an Optimistic Redemptions mechanism?

With an Optimistic Redemptions model, should the Council retain veto power over Governor Bravo proposals or should that power be revoked?

3 Likes
5

Very much spit-balling here, and would need a Solidity engi more familiar with the code to get a better idea. But for a heavily tested upgrade, I’d expect 2-4 weeks of spec + dev time and a up to 1 week of audit time. We’d likely also need some sort of maintainer that vetoed huge redemptions by default, and let the remaining human keyholders follow up after that to confirm… and maybe some alerting setup for all related guardians… the details there are less clear to me though.

With an Optimistic Redemptions model, should the Council retain veto power over Governor Bravo proposals or should that power be revoked?

If after the third veto, Governor Bravo has, say, 45 days to confirm the veto or it goes through… the Council’s veto power over Bravo couldn’t be used to censor transactions. I think that’s enough time for a good community discussion as well? But I’ll defer to @Will and @Luna5 who have a better feel for the DAO’s operational cadence.

6

I feel we should remove all reviews, it’s not our problem who uses the service and how, we can’t police things, it’s not our job.

So I vote for 1. Remove all redemption review at the protocol level

“If a bank gets robbed and the thief uses BMW I’m sure the police doesn’t expect BMW to interfere…“

Policing chains be it eth or btc is not our problem.

2 Likes
7

This seems like a reasonable set of params.

Probably need to define a starting guardian size + a mechanism to remove chaotic actors (e.g an individual / group that votes to veto everything … because crypto)

2 Likes
8

Veto first sounds like a great idea.

1 Like
9

Escalating veto design with a timeline seems appropriate to me. The protocol is still young and we need safety mechanisms in place … for some prudent time. I would have said 12 months, but could also be 18 to full decentralization.

2 Likes
10

for some prudent time. I would have said 12 months, but could also be 18 to full decentralization.

Absolutely, the actual params are difficult to choose — you can imagine circumstances where we are sideways for 12 months, then it locks… only to grow very quickly in the next cycle, and expose more issues.

I liked 18 because at 12 months / 30 minutes, requiring 3 vetoes from aligned people around the world, we’ve already made any attempt at human-time censorship quite difficult… and if in that trailing window, there’s a new bug or something, we can revisit.

I’ll also call out that while I think this mechanism is strictly better than what we have today, as it returns vetoed funds to a redeemer, we’ll still need a campaign to grow our delegates / get more people engaged in on-chain governance so the DAO is a proper backstop.

1 Like
11

Strong agree. It’s not what we’re building, and it’s not why I’m personally in the space.

However, if there’s a bug found in the tBTC bridge and it gets drained… it’s a very difficult thing to come back from. We need a balanced approach that lets us take off the training wheels as the bridge grows ideally programmatically so we don’t run into hazard like this again.

Here’s the most recent bug to give you an idea. The dev team, DAO, and stakers were on top of it and it was handled very quickly, but if this had been a zero day, it would’ve been game over.

2 Likes
12

Bad actors using the service will become the DAOs problem if/when the US Treasury chooses to sanction the smart contracts / DAO as they have done with TC.

A veto mechanism is a progression in efficiency that also shows the DAO is willing to self regulate. This minimizes the risk of government intervention which, in turn, secures the future of the DAO.

Any approved proposal should:

  • Be specific regarding what conditions warrant a veto and what would not. This is complicated enough it deserves a discussion and documentation.
  • Minimize the length that user funds being held/locked based on vetoes. This should be 48 hours max. Addresses should be refunded if the transaction is not processed within a short/reasonable amount of time. This gives protocol users confidence their funds will not be lost indefinitely and if, for any reason, the DAO fails to act they can get their funds back and try other avenues to achieve their goals. This should be automated.
  • Include a technical avenue to automate vetoes based on publicly listed sanctioned addresses

Without an automated refund the DAO will be in the position of potentially being asked by regulators / LE to indefinitely hold in-transit funds. That makes the DAO no more decentralized than a US Bank.

Taking a veto to a token holder vote should happen after a refund has been processed and a user appeals the veto. This allows the user to get their funds back while allowing an honest user to appeal to the DAO for a ‘whitelist’ on their transaction which can then be resubmitted if they want.

These guardrails will dissuade bad actors from using the protocol while ensuring honest users who accidently get caught up are able to have their funds returned while at the same time having an appeal option. It also ensures the DAO is viewed as being proactive regarding misuse of the protocol.

5 Likes
13

So it feels like Optimistic redemption is the only way for now…… to mitigate any could be bugs.

I suppose we need to increase the budget for bounty’s and stress test the f out of the bridge while losses could be manageable…sort off :face_with_peeking_eye:

Thank you all at T for guiding the community stakers and node operators :heart_hands:

I feel hopeful for the future of T and look forward for 0 delay redemptions🔥

3 Likes
14

My view is that the only condition that should warrant a veto is an exploit in the TBTC bridge, since that is the only thing members of the DAO evaluate with certainty in a timely manner.

This is not possible if it goes to a DAO vote. Governor Bravo adds a minimum two week delay.

I don’t like the idea someone having the power of adding sanctioned addresses. This makes the technology less neutral and could clog up Governor Bravo with votes.

100%

why would a user appeal the veto after they have their funds back?

15

@mhluongo what is/would be the process of adding more approver addresses?

I like the idea of optimistic redemptions, guardians that safeguard redemptions by issuing a veto sounds reasonable, as long as the DAO has the ability to remove a guardian swiftly, if needed.

16

My view is that the only condition that should warrant a veto is an exploit in the TBTC bridge, since that is the only thing members of the DAO evaluate with certainty in a timely manner.

Having automated filtering of Treasury sanctioned or exploit related addresses demonstrates the DAO is making reasonable efforts to comply with regulations and to prevent abuse of its technology. This minimizes risk of the DAO being sanctioned by the US Treasury and provides an avenue for authorities to engage with the DAO constructively if required.

Failing to provide these safeguards increases risk to the DAO - a US Treasury sanction would be a death blow for any DAO.

why would a user appeal the veto after they have their funds back?

Unlikely to happen. However, if somebody wants to bridge in a decentralized and permissionless way in order to maintain privacy, Threshold may be their preferred and chosen way. That said, perhaps it’s better to just return their funds and let them find another path.

17

I believe the relevant contract is currently owned by the Council — so a TIP with a process or pre-decided list of addresses + a Snapshot vote could do it.

2 Likes
18

We are potentially willing to take on this role.

Can you share the specific contract call that approvers need to make to approve redemption requests?

19

If funds are in a sanctioned address, the owner would just have to transfer them to a new address and then use the bridge.

Even if it was an effective way to demonstrate good will, it adds in two trust assumptions into the bridge.

  • The source of where the addresses come from / how many need to be checked.
  • How the addresses actually get added.

How is the Badger planning to approach this with eBTC?

20

How is the Badger planning to approach this with eBTC?

eBTC is a synthetic BTC position and can’t be used to redeem for native BTC. There’s no custody aspect to it, so this issue isn’t something Badger needs to concern itself with.

1 Like