Table of Contents

Introduction

Today interaction with DeFi smart contracts typically requires MetaMask-type browser extensions or WalletConnect-type functionality.

FIO Protocol can be a much easier way to interact with DeFi by using FIO Address and FIO Request. Example use cases:

• Users could deposit funds to a smart contract using FIO Address, e.g. smart@somedefi. Different addresses could be used to accomplish different objectives, e.g. product1@somedefi

• Users could withdraw funds from smart contracts using FIO Request

The objective of this project is to identify and potentially implement ways in which FIO Protocol could be used with DeFi smart contracts and applications.

The document often refers to Ethereum, but the same approach will likely apply to other smart contract chains.

Ideas

Idea 1: Relay Smart Contract

Most DeFi smart contracts on Ethereum require that a specific function be called with specific parameters. Most wallets only support basic transfer of tokens and typically do not support interaction with other functions of smart contracts. As funds sent to smart contract address will likely be lost, FIO Address should not be mapped to a DeFI smart contract address.

Sending funds to DeFi smart contract using FIO Address

A purpose-built Relay Smart Contract could be built, which would accept funds sent to it (e.g. by using receive function) and would then call specific function on specific DeFi smart contract. The contract’s address could be mapped to a FIO Address, e.g. vault@somedefi

The amount of deposit may be reduced by any gas required to executed functions on DeFi contract.

Withdrawing funds from DeFi smart contract using FIO Request

An Oracle will be required to enable the use of FIO Requests, e.g. sent to vault@somedefi, to withdraw the funds. Since using an Oracle, especially centralized, introduces security risks, a decentralized oracle solution is recommended. See https://fioprotocol.atlassian.net/wiki/spaces/DAO/pages/7012357 for more details on oracle solutions being considered.

The amount of withdrawal may be reduced by any gas required to executed functions on DeFi contract and to send funds back to the user.

The Relay Smart Contract may be built to interact with any DeFi project and would not require any changes to that DeFi’s smart contracts.

Idea 2: Enable on-chain access to FIO functionality for Smart Contract Chains

It is believed that if FIO functionality was available natively, i.e. on-chain, to developers of DeFi smart contracts, such functionality would be far more likely to be included in their smart contracts.

FIO Address look-up

DeFi platform may accept a FIO Address as an attribute, e.g. for refund address, if they can resolve it easily on-chain to a public address. FIO Address mapping to public address on specific chain could be recorded on that chain and be made accessible from other smart contracts on that chain. For example to support FIO Addresses on Ethereum, an Oracle may record every ETH Address to FIO Address mapping on a designated “FIO” smart contract, making it easily accessible by any smart contract on the Ethereum Chain.

The Foundation would likely have to cover the cost of gas for storage.

FIO Request

DeFi platform may trigger FIO Requests, e.g. funds deposit, if they can do it easily on-chain.

Since currently FIO Request only supports token transfer, the DeFi smart contract must support ability to send funds to it.

FIO Data

FIO Data (e.g. did a transfer on another chain occurred) would be very valuable if available on-chain. In theory it could be made accessible in the same way as FIO Address Mappings, but because the data set would be much larger and oracles would have to perform validations on other chains, it may not be feasible.

Idea 3: Extend FIO Protocol to include smart contract interaction details

As stated previously, today most wallets do not support interactions with DeFi, because of their complexity. However, FIO Protocol could standardize such interactions making them much easier for wallets to support. Specifically, FIO Protocol could add a new type of mapping that defines smart contract interaction, and return it to wallet instead of the public address.

For example, when wallet attempts to resolve farm@somedefi, FIO Protocol would return a set of smart contract actions that have to be executed in order to participate in this DeFi product. This will allow the wallet to present standardized screen for smart contract interaction and standardized calls made to the smart contract.

Some may see similarities between such standard and Ricardian Contracts, which were primarily designed to communicate smart contract logic to users using familiar contractual language. Even though, user-friendly text may be returned as part of this standard, the primary objective is to allow wallets to more easily support smart-contract interactions.

See https://fioprotocol.atlassian.net/wiki/spaces/DAO/pages/53314345

Idea 4: Request for signature

This idea builds on Idea 3 and is related to https://fioprotocol.atlassian.net/browse/WP-95

It introduces the concept of Request for Signature, where a properly formatted transaction is included in a new type of FIO Request. When the wallet receives that request, they present it to the user for signature rather than token send.

This could be used by DeFi dApps to send a signature request for interaction with the dApp (approve ERC-20 token withdrawal, etc.) to the wallet.

See See