...

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.

...

FIOChain Oracle RelaySmartContract DeFiSmartContract
@Starter(User)
"{Confirmation}" = FIOChain.FIORequest
"{ValidFIORequest}" = Oracle->FIOChain.GetFIORequests
"{Confirmation}" = Oracle->RelaySmartContract.TriggerPayment {
  "{Confirmation}" = DeFiSmartContract.FunctionA(x, y)
  "{DeFi Token Transfer}" =DeFiSmartContract.FunctionB(x, y)
  RelaySmartContract->User:DeFi Token Transfer
}
"{Confirmation}" = Oracle->FIOChain.ApproveFIORequest

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 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.

...