This effort prototypes a simplified end-to-end flow of FIO Wrapping.

Use case

Wrap FIO Token:

1. Alice (dApp) executes wraptokens on FIO chain

2. Oracle monitors wraptokens for transfers

3. Oracle executes ERC20 _mint

4. Oracle executes ERC20 approve

5. Alice (dApp) calls ERC20 balanceOf to get balance

6. Alice (dApp) executes ERC20 transferFrom

Assumptions

• Assume there is a single Oracle managing all transactions. Do NOT worry about multisigs, approvals, etc.

• No validation on either chain is required.

• Do not worry about oracle fee imbalances.

Diagram link: https://drive.google.com/file/d/12f8iOoZjj1txZCJprpuQ5VFb8Ejpc9Bp/view?usp=sharing

Deployment

• fio.wrapping: contract deployed to DEV server with V1 History (eventually will move to Hyperion)

• oracle: daemon running on server

• ERC-20: open zeppelin contracts on Ropsten testnet

TBD

approve vs transfer when wrapping

Tracks the discussion regarding the best way to transfer wfio. There are two options listed below. It is important to note that some kind of dApp will be needed on both sides of wrap/unwrap in either case. So, the question becomes what functionality belongs in the oracle and the contracts versus what belongs in the dApp. Constructed correctly, the difference between approve and transfer can be “hidden” from the end user--it would simply show up as an extra step in the dApp.

1. approve

   1. Steps:

      1. User (via a dApp) calls wraptokens

      2. The oracle executes a mint then an approve

      3. The user (via a dApp) executes a transferFrom

      4. The user adds wfio token to Metamask (or similar) holding their Ethereum key and now sees their wfio

   2. Pros:

      1. This is a more standard approach to transferring ERC20 tokens. For example, Uniswap first asks users to “approve” the transaction. Once approved a second “transferFrom” step happens.

      2. Using approve gives an extra layer of security to the transfer process. In theory, if a mistake is made during approve, the approval can be modified (assuming the transferFrom has not occurred).

      3. The user pays the fees for the transferFrom

   3. Cons:

      1. Extra steps

2. transfer

   1. Steps:

      1. User (via a dApp) calls wraptokensT

      2. The oracle executes a mint then a transfer

      3. The user adds wfio token to Metamask (or similar) holding their Ethereum key and now sees their wfio

Alternative

1. User (via a dApp) calls wraptokens

2. Oracle #1 calls mintTransfer

   1. ERC20 contract collects “observation” #1

3. Oracle #2 calls mintTransfer

   1. mintTransfer calls _mint (mints to contract , not to Oracle)

   2. mintTransfer calls transfer (to user Ethereum key)