Announcing the Optimism Dai Bridge with Fast Withdrawals

Maybe I haven’t fully understood the system correctly but if Oracle failure (i.e. incorrectly assuming a withdrawal on the canonical transaction chain is correct when in fact, it gets pruned later) is a possibility and you still give a user fDAI, won’t you end up with a vault of collateral that is worthless anyway?

Also, what exactly is a double spend in this context?


Let’s first define double spend. Alice has 1000 oDAI on Optimism. She first sends 1000 oDAI to Bob and later she attempts to withdraw 1000 oDAI. Canonical Chain on L1 will register two transactions (transfer() and initiateWithdrawal()). Clearly the second transaction will fail (revert). The fact that there is a initiateWithdraw() tx on the Canonical Chain by itself is clearly not enough evidence to release DAI from the deposit contract. So normally the bridge would wait for the Sequencer to post the L2 state, wait 7 days, and only then act accordingly (i.e. release DAI if and only if the execution of the initiateWithdrawal() actually succeeds)

Oracle can execute transactions from the Canonical Chain and see whether the initiateWithdraw() will succeed or revert. fDAI is a tokenised withdrawal claim that may be considered by Maker holders good collateral for DAI. It’s almost risk-free assuming no Oracle failure. If Oracle “lies”, collateral is worthless and DAI minted will be unbacked with the standard consequence for MKR holders


Thanks for clarifying.

Please correct me if I’m wrong but my understanding of Optimism is as follows. The canonical transaction chain is append-only. So the sequencer will add only one of the two double spending transactions if it is honest. If the sequencer is malicious, it may add both in some order, say initiateWithdrawal() followed by transfer(), but some verifier will prune the transfer() tx and initiateWithdrawal() remains valid and will succeed. On the other hand, if the order is transfer() followed by initiateWithdrawal(), the oracle should spot this. Either way, as soon as initiateWithdrawal() gets appended to the CTC, the oracle should know whether it is valid or not.

If the oracle works correctly, there is no risk. If the CTC has a malicious tx and the oracle fails to spot it, Maker loses money no matter how we design the system since the user has DAI (minted from the vault). So I’m still not sure why we don’t release DAI to the user in the first place.


Is there are mechanism in place to reward and punish oracles? And could you please talk through how you can prove that an oracle has acted poorly?

1 Like

No, that’s not how it works. The sequencer will add both txs in the chosen order. The first one will succeed, the second will fail. See for details. Nobody “prunes” any transactions, they are canonical once they are submitted to L1. It’s the state (the result of their execution) that can be potentially fraudulent - honest Sequencer will submit the correct state, dishonest may submit wrong state.

1 Like

I’m seeing some questions about Oracle manipulation/failure–does this imply we will have a DC assign to this mechanism?

Also, with fDAI Vaults–if I understand it correctly–the Users will incur interest? Or, perhaps I misunderstood.

1 Like

Yes we will want a DC to protect against worst case scenarios such as fDAI gets minted ad-infinitum.

We will need some fee to pay for the service. This could take the form of an interest rate or maybe even just a fixed fee like the PSM.


Here is my solution that might cost less gas and is more decentralized (no trusting maker oracle), and does not require putting maker holders at risk if the oracle fails

  1. lock DAI (L1) in vault to receive oDAI(L2).
  2. do stuff on L2 with oDAI
  3. to take oDAI from L2 to L1 instantly, go to L1 vault contract and mint an empty nftDAI
  4. burn oDAI with a note associating it with particular nftDAI.
  5. anyone can see that the oDAI was burnt, meaning the associated nftDAI now has value. That value is oDAI_burned * (1 - (1 week of interest ~0.19%)) * (chance the burn was not fraud) - (gas cost of later redeeming the nftDAI)
  6. sell nftDAI to anyone willing to pay for it, competitive pricing from relayers should result in the price in the previous step with a very tiny profit. User now has DAI on L1 within minutes of burning oDAI.
  7. relayer holds on to nftDAI on L1 for 1 week
  8. relayer burns nftDAI and the vault contract can see the optimism contract has fully verified the oDAI burn, that the burn is associated with the nftDAI it is receiving, and thus gives the relayer an amount of DAI equal to the oDAI burnt.

The vault only accepts two things to release its DAI: oDAI that has made the 7 day journey to leave Optimism and make it to L1, nftDAI that is pointed to by a L2 oDAI burn was 7-day-confirmed.


Isn’t this the same setup, minus fDAI, plus nftDAI, and putting nftDAI buyers at risk if their oracle fails?

On another note I got a little confused about fDAI per past comments, I think the keyword here is “accounting”. With the DAI-only setup, an oracle failure gives you unbacked DAI with I think no easy way to account for that inside Maker and trigger e.g. flop auctions – with fDAI you get to go through the vault mechanism for issuing DAI and can track fDAI value.

1 Like

Here are the steps to use oDAI/fDAI official relayer system described in OP as I understand. I think I am missing something especially regarding the paying of interest at the end.

  1. lock DAI (L1) to receive oDAI(L2)
  2. do stuff on L2 with oDAI
  3. burn oDAI
  4. relayer verifies oDAI burn one week early taking on risk of fraud
  5. relayer mints fDAI on L1 , this is a nft
  6. fDAI used as collateral for DAI borrow
  7. 1 week later the oDAI burn is finished processing and the user is expected to pay the interest to the vault instead of just running off with the L1 DAI.

What exactly happens once the oDAI burn is 7 days old? What is being repaid to the vault? Just the interest?
There are only 3 assets to consider once the user takes out a loan against the fDAI: the DAI which the user has, fDAI which the vault has, and oDAI which was burnt.


When Oracle fails, that means that the original “withdraw” transaction eventually fails. But we are tricked to believe by the Oracle that it will succeed. Maker mints DAI based on the Oracle claim, but never gets back the DAI from the deposit contract. fDAI that was used as collateral for the mint turns out to be worth zero (as it ends up being non-redeemable for DAI). The easiest way to think about it is that fDAI is a “tokenised withdrawal claim”. You can see that this claim is worth anything only if the withdrawal tx actually succeeds. Tokenised Withdrawal Claim of a withdrawal transaction that reverts is worth zero


@bartek perhaps you can shed some light for us non-experts on Optimism. In the opening post, it is claimed that

What this means is that although we have to wait 1 week to ensure that the result of the computation of the CTC is correct, we can have off-chain proof that the individual transaction is correct within a few minutes

So in what sense can the oracle fail/get tricked? Is it the double spend problem you highlighted earlier i.e. the individual transaction is correct but it is inconsistent with another one? If so, isn’t the risk of this rather high i.e. can a user simply keep withdrawing DAI through the bridge and include enough double spends so that it becomes profitable for them?

Or to ask differently, what is the risk of bad debt in this protocol?

There is always risk that oracles collude and produce invalid data. We do not think this risk is high, but it’s still there. If we allowed them to withdraw the DAI from the bridge directly then in the event of oracle failure, the users who have oDAI will lose funds as there is now more DAI in L2 than locked in the bridge. Imagine if the oracles drained all the collateral from the bridge then the L2 oDAI would become worthless. Using the fDAI mechanism shifts this risk to MKR holders instead. If the oracles fail then MKR holders have to take the loss instead of the average user on L2. This correctly aligns the incentives for MKR holders to prefer a very robust oracle system


If the Oracle does not fail and properly validates the transaction - zero. But we still want a construction in which the attack on Oracles (or their technical failure) will hurt MKR holders, but not DAI holders. That’s why minting DAI rather then simply releasing DAI from the deposit contract is, IMO, a safer, more decentralised and trust-minimised solution

Releasing DAI directly from the deposit contract will make the bridge not much better than the M-Sig bridges that we seen all over the place today to other L1 chains


Is this also happening on Arbitrum? If not why not?

I would like to know if anyone is working on this and if so where we are in terms of timeline.

Hey guys, yes, the work continues!

@nbiz , we actually had a meeting with Arbitrum yesterday. A brief update: We are working with their team who recently refactored their infrastructure (in particular the bridge design). We discussed opportunities to leverage their audits as we definitely want to be a part of their mainnet launch. I’m not going to commit to a specific timeline right now as there are a number of different external entities involved (exchanges, oracle providers etc). Our conversation with them was very positive, we still have some technical questions we need to resolve, but all in all this is moving forward nicely.

@ejbarraza , regarding Optimism, our team has been working on improvements to the Dai Optimism Bridge, including Echidna debugging work to; find invariant breaks, fix token interfaces in the L1 gateway, add directories to our yarn scripts, and more. I’m in the process of setting up a follow-up call with the Optimism team to align our L2 fungibility design thoughts and bridge design progress.

In both cases, our approach is to build a simple bridge, support fast withdrawals, and in due course look towards Maker Protocol deployment on L2 (although as you’ll appreciate, this 3rd point is further down the road due to the complexities involved). In parallel we have also commenced discussions with StarkWare regarding Cairo and StarkNet - again supporting our Multichain Strategy.

I’ll provide a more comprehensive update and specific timeline once I have some more demonstrable details of the work completed.


So glad to hear that MakerDAO is in contact with Starkware. Hopefully zkrolllups solve the gas fee problem for good.


Excellent thanks for the quick reply and info ! I must admit I first checked telegram and it’s a little … subpar to say the least ; ) But hey maybe that’s intended – more engagement to the governance forum lol

Same like @ejbarraza very excited for the massive impacts these rollups will have.

I wonder if MakerDAO will find a way to facilitate or contribute to the possible future of “sharding” these L2s?

Question? What would happen to the uncollateralized L2 DAI in this “bug” scenario after Maker Governance has intervened? Would it get burned, or blocks would be reorg?

“Bug allowing to send arbitrary messages from L1 to L2 ie. making OVM_L2CrossDomainMessengerto send arbitrary messages, could result in minting of uncollateralized L2 DAI. This can be done via:

  • sending finalizeDeposit messages directly to L2DAITokenBridge
  • granting minting rights by executing malicious spell with L2GovernanceRelay

Immediately withdrawing L2 DAI to L1 DAI is not possible because of the dispute period (1 week). In case of such bug, governance can disconnect L1DAITokenBridge from L1Escrow, ensuring that no L1 DAI can be stolen. Even with 2 days delay on governance actions, there should be plenty of time to coordinate action.”

Also, disconnecting the bridge would need an emergency Executive Vote? If so, how will the community deal with such a scenario that could take “hours” to resolve? Can an attacker mint an endless amount of uncollateralized L2 DAI while the community rallies MKR token holders?