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

• How will Alice execute the transfer? Need a dApp

Prototype Review

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 wraptokens

      2. The oracle executes a mint to the users address

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

After several discussions with the team, it was decided that the extra steps for the user to transferFrom may not be worth the security benefits of using approve. We will go with the direct mint.

Prototype Testing

Prototype environment:

• fio.oracle and oracle server: http://44.234.122.169:8889

• Dashboard: http://44.234.122.169:8000/

• Ropsten endpoint: http://50.250.156.58:18545/ or ws://50.250.156.58:18546

• dApp to interact with contract: https://oneclickdapp.com/matrix-second

• contract address: 0x409F0d72e4700884200df4B11394b10A3539EB94

• oracle: 0x41D1ADa8F67968F54Dbc55a259302dE700bC2bE9

Prototype was tested:

• Called wraptokens with Eth address

• Used https://oneclickdapp.com/matrix-second allowance to confirm available wfio (Oracle account currently holds the minted wfio)

• Used transferFrom to transfer tokens to ETH address.

• Added wfio token contract to Metamask and the correct amount of wfio appeared.

Todo

• Only initial validation was done on wraptokens.

• Need to update oracle to use _mint (to user address).