Skip to content
This repository has been archived by the owner on Apr 12, 2021. It is now read-only.

UniBridge: Single bridge contract for tokens #257

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

dmihal
Copy link
Contributor

@dmihal dmihal commented Mar 1, 2021

Description

New bridge for fungible tokens.

  • Doesn't require re-deploying new bridge contracts for each token
  • Allows deploying ERC777 & ERC20 tokens on L2
    • Tokens can be converted ERC777 <-> ERC20 on L2
  • L1 contracts can calculate the address of L2 tokens (using Create2)

Contributing Agreement

@dmihal dmihal force-pushed the unibridge branch 3 times, most recently from bfd263f to e0bbc32 Compare March 3, 2021 00:13
@transmissions11
Copy link
Contributor

transmissions11 commented Mar 3, 2021

Left points for discussion in the #devex channel on Discord.

Only things that I think would warrant additions to the actual contracts are a way for new tokens (meant to be used on Optimism) to lock in using ERC20 or ERC777

Also I would like to add some withdrawAndCall functionality like I've been talking with @ben-chain about for a while but that can be seperate from this PR 👍

@dmihal
Copy link
Contributor Author

dmihal commented Mar 3, 2021

@TransmissionsDev Ya there's lots of features I'd like to add around withdrawals as well, but I figured I'd try to limit the scope of this PR

@dmihal dmihal changed the title DRAFT: Unibridge UniBridge: Single bridge contract for tokens Mar 3, 2021
@dmihal dmihal marked this pull request as ready for review March 3, 2021 10:10
@maurelian maurelian self-requested a review March 4, 2021 16:28
@rockfridrich
Copy link

We need a depositFor function in order to allow interactions via smart-contracts. Similar to Polygon:
https://docs.matic.network/docs/develop/ethereum-matic/pos/calling-contracts/erc20#deposit

@maurelian
Copy link
Collaborator

I'm sorry this PR has been sitting here for so long, without at least having some feedback from the team. FWIW, different people have had some discussion with @dmihal on other channels, so we're not completely ghosting on him.

IMO, the main obstacle to merging this is that review needs to be done carefully, and there is a significant amount of code here.

I'll sync with the team and try to come back next week with:

  1. a decision for if this should be in scope for the repo
  2. a timeline for review

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants