WBTC approach and how it compares to Multiple Oracles

Feature	Spec 1 - Oracles	Spec 2 - Merchants	Notes

Feature	Spec 1 - Oracles	Spec 2 - Merchants	Notes
Custodians	Register Oracles and Custodians 10 Custodian keys hard coded into contract Dev Estimate:	Custodians Register Merchants and Custodians Custodian smart contracts Monitor their FIO vaults looking for FIO deposits (WFIO minting requests) from Merchants Dev Estimate:
Oracles / Merchants	Based on Alien Teleport Oracle code is run by designated FIO Chain BPs Multiple Oracles: Monitor User wraptokens and unwraptokens actions on the FIO Chain Submit “observations” for minting/burning Dev Estimate:	3rd party “trusted” merchants Merchants have vault accounts for FIO and WFIO Merchants: Monitor their FIO vaults looking for FIO deposits (WFIO requests) Monitor their ETH vaults looking for WFIO deposits Exchange FIO for WFIO Dev Estimate:	Cost of multiple Oracle Ethereum contract transactions
Minting / Burning of Tokens	Minting occurs for every User request Multiple Oracles monitor User “wraptokens” actions on the FIO Chain “Observations” are submitted to the Eth smart contract Once a number of oracles have submitted observations, WFIO is minted and sent to User’s Eth address	Minting is an offline process where 3rd party Merchants exchange FIO for WFIO in bulk Custodian contracts approve the minting of FIO for approved Merchants
NFTs	wrapdomain transfers ownership of domain from User to fio.wrapping account Oracle monitor fio.wrapping account then submit “observations” to create a NFT on the Ethereum chain Dev Estimate:	TBD on Design??
FIO Contracts	fio.wrapping contract: wrapping and unwrapping of tokens and domains registering/unregistering of oracles Setting oracle fees Dev Estimate: 4-6 weeks	?
Ethereum Contracts	These smart contracts control: Minting and burning of the WFIO token Adding and removing Merchants and Custodians in the network Pausing or resuming transfers on the wrapped contract Changing logic to Mint or Burn tokens (if needed) Dev Estimate: 2-3 weeks	These smart contracts control: Minting and burning of the WFIO token Adding and removing Merchants and Custodians in the network Pausing or resuming transfers on the wrapped contract Changing logic to Mint or Burn tokens (if needed) Dev Estimate: Leverage existing Eth contract code: 2-3 weeks
Multisig	Support for multisig approval by Custodians msig required for “meta” tasks such as registering Oracles and Custodians Support for “multisig” approval by Oracles (A set of) Oracles approve Wrapping and Redeeming requests (minting and burning) Dev Estimate:	Support for multisig approval by Custodians msig required for “meta” tasks such as adding and removing Merchants and Custodians and changing contract logic NOT required for minting/burning (???) Dev Estimate:
Fees	Oracles specify fees they want to be paid by user for wrapping services Fees collected from user and distributed to Oracle when wrapping FIO Fees collected from user and distributed to Oracle when redeeming FIO These fees should cover gas fees on ETH	Custodian fees: This is taken by the Custodian at the time when the merchant mints or burns wrapped tokens. Merchant fees: This is taken by the Merchant who the User exchanges wrapped tokens with for the asset.

Tasks

Task	Details	Estimate	Status

Task

Details

Estimate

Status

Phase 1: Token Wrapping on Testnet

Sprint to deploy existing Alien Teleport functionality on Testnet

Phase 1: Wrapping Technical Design

3 weeks

https://fioprotocol.atlassian.net/browse/BD-2281

Phase 2: Domain Wrapping on Testnet

Links


michaeljyeates/alienteleport Github	https://github.com/michaeljyeates/alienteleport
Wrapped Bitcoin Whitepaper	https://wbtc.network/assets/wrapped-tokens-whitepaper.pdf
Wrapped Bitcoin Github	https://github.com/WrappedBTC/bitcoin-token-smart-contracts/tree/master/ethereumV2

Risks and development considerations

Risk	Tasks

Risk	Tasks
Who is the custodian and what control do you want to give them?
Locking a FIO Token is easy. When you unlock from ETH back to FIO, who is in control of that?
Current wrapping is all third party.
Focus on decentralization

Development strategies

Strategy	Pros	Cons

Strategy

Pros

Cons

Alien Teleport Model

Makes asset safekeeping easier ( Single account lock )

Requires participation from all registered oracles

Promotes high fees

not “Turing-complete”

Lots of changes needed to meet written spec

WBTC Model

Permission based participitation

Scalable

Allows Merchants to customize the experience and set their own fees

Trusted and Audited Security Model

Allows merchants to KYC end-users

Requires safekeeping of assets

not “Turing-complete”

Requires audits of locked assets

WFIO Ecosystem

(Refer to Wrapped Bitcoin Whitepaper and Wrapped Bitcoin Github links above former details.)

The proposed WFIO ecosystem consists of Custodians, Merchants, and Users.

Custodians

The Custodians provide reliable, institutional-grade security for your WFIO. All WFIO issued will be fully backed and verified through on-chain proof of reserves.

Custodians may consist of foundation+bps and other third-Parties?
Each custodian has a “FIO vault” account on the FIO blockchain.
Each merchant has a “WFIO vault” account on the Ethereum chain
At any point in time, the amount of FIO in Custodian vaults should be greater than or equal to the total supply of WFIO.

Merchants

Merchants perform key roles for the WFIO community as administrators who initiate the process of minting newly wrapped tokens and burning wrapped tokens which are performed by the Custodians.

Merchants may consist of wallets, exchanges, and BPs?
Each Merchant has a “FIO vault” account on the FIO blockchain.
Each Merchant has a “WFIO vault” account on the Ethereum chain.
Only Merchants can burn tokens

User

Users are the holders of the wrapped token. Users can use wrapped tokens to transfer and transact like any other ERC20 token in the Ethereum ecosystem.

Trust

Custodians will not be able to mint tokens on their own, but would instead require the initiation of a Merchant in order to do so. The creation of new tokens involves both the Custodian and the Merchant.
Only Merchants can burn tokens.
The User is insulated from interacting with the Custodian through a set of merchant institutions. An individual Merchant does not need to be trusted, but instead, all Merchants together would need to be.

Custodian / Merchant Rules

Custodian is being trusted to confirm valid mint requests. I.e, a request followed (or preceded) by a FIO deposit to Custodian deposit address with a greater or equal amount.
Custodian is being trusted to confirm burn requests and send FIO to Merchant deposit address (as depicted in the burn request)
Merchant is trusted not to spam the Custodian with dust requests.
Custodian is trusted not to frequently change his FIO deposit addresses

Use Cases

Minting (Merchant acquires WFIO from Custodian)

WFIO tokens are minted when a Merchant deposits FIO into the Custodian vault and submits a minting request. The Custodian then approves the minting. In other words, for minting to happen a single Custodian and a single Merchant have to agree.

The Merchant sends the Custodian (amount + fee) FIO to the Custodian’s FIO account
Merchant waits for X confirmations of the FIO transaction
Merchant initiates a transaction* to authorize the Custodian to mint X WFIO to the Merchant’s address on the Ethereum chain
Custodian calls confirm mint request to mint X new WFIO tokens on the Ethereum chain

** call the mintRequests function with a value of Y, where Y is the index of the mint request

Burning

User sends WFIO to the Merchant.
The Merchant calls Burn with the amount, and lets the Custodian know the nonce of the request
Custodian reads the burn request
Custodian waits for 25 block confirmations of the ETH transaction
Custodian sends (amount requested - fee) FIO from Custodian’s vault to the Merchant’s vault
Custodian makes an Ethereum transaction marking the burn request as completed

User acquires WFIO (from Merchant)

Merchant monitors their FIO account (similar to an Exchange)
User sends FIO to merchant’s FIO account
User supplies Ethereum address to merchant
Merchant sends WFIO to User’s Ethereum account

User swaps WFIO for FIO (from Merchant)

Merchant monitormns their WFIO ETH vault (similar to an Exchange)
User sends WFIO to merchant’s WFIO account
User supplies FIO Public Key to Merchant
Merchant sends FIO to User's FIO account

Fees

Transfers of WFIO between Users will have no cost apart from network fees. There are three ways in which different parties in the network can earn fees:

Custodian fees: This is taken by the Custodian at the time when the merchant mints or burns wrapped tokens.
Merchant fees: This is taken by the Merchant who the User exchanges wrapped tokens with for the asset.
Sidechain transaction fees: This fee is predominantly aimed at preventing spam on the sidechain. This is shared equally among all institutions running nodes on the sidechain.

Architecture

FIO Contracts (TBD)

Wrapping FIO contracts are not required as part of the ecosystem, but there may be use cases for creating specialized FIO contracts including:

Allow custodian or merchants to update deposit wallets
Register/voting as custodian/merchant?

ETH Contracts

Custodians will hold the keys to a multisig wallet, which owns a set of Ethereum smart contracts. These smart contracts control:

Minting and burning of the WFIO token
Adding and removing Merchants and Custodians in the network
Pausing or resuming transfers on the wrapped contract
Changing logic to Mint or Burn tokens (if needed)

‘M’ of ’N’ signatures will be required to send transactions from the multisig wallet where M and N will be determined once the launch partners are ascertained.

ETH Contract Overview

The end-user interacts only with the WFIO component which exposes an ERC20 interface. The implementation also has an interface and implementation for minting and burning. The owner of the token is the Controller contract. The Controller contract is owned by the Custodians (e.g., a multisig wallet) which has the authority to:

Pause the token transfers
Upgrade the minting and burning protocols
Upgrade the protocol for adding (and removing) new members, namely, merchants and custodians.

The initial implementation of the burning and minting protocol is defined in the Factory contract. The initial implementation of the member selection is implemented in the Members contract. The connection between the different contracts is depicted in the figure below.