FIO Assets
Overview
This document serves as forum to discuss creation of user generated assets onto the FIO Blockchain.
The current architecture of FIO Protocol is able to provide Layer 1 functionality like token bridging, pegging, wrapping, and asset storage to Layer 2 applications. But, L1 functionality cannot be easily accessed by L2 applications in FIO Protocol’s current state as a closed contract platform. The solution is to allow users to create their own assets on the FIO Blockchain by deploying a standard set of contracts to enable their implementation. For example, similar functionality has been achieved with AtomicAssets/SimpleAssets which allows users to generate assets using a single contract on the EOSIO and WAX chains.
The FIO Assets project proposes the following:
Development and deployment of one or more contracts on the FIO Chain to enable users to create assets compatible with ERC20 and ERC721/ERC1155 and similar standards.
Partnering with existing marketplaces and applications to provide asset storage
Strategic Objectives
FIO Assets serves three main FIO Strategic Objectives: The Why, The Users, and The Money.
The Why - FIO as a Layer 1 Protocol
The Why objective aims to tell a compelling story. While the current Layer 2 story is interesting from an application perspective, it neglects to leverage the powerful story that FIO is, in fact, a Layer 1 protocol. The Layer 2 field is crowded and somewhat confusing. The Layer 2 space is increasingly being defined in terms of side chains and other scaling protocols (e.g., Polygon) that rely on a Layer 1 chain to finalize transactions. Realistically this put current FIO functionality at Layer 3, the application layer, a very crowded layer.
The goal of FIO Assets is to enable the FIO token to capture the value that users and investors place on Layer 1 protocols.
TBD: Table of valuations of L1 versus L3 EOSIO-based (and other) chains.
The Users (Part 1) - NFT Assets
The Users objective aims to increase FIO Protocol utilization. FIO currently collects income through two different types of utilization:
Crypto transfers. This includes the fees that come from mapping FIO addresses, FIO requests, OBT data, and other transactions related to the transferring of crypto.
Asset storage. This includes the storage of FIO Domains, Crypto Handles, and NFT Signatures.
The FIO strategy to date has been to increase the number of wallets and exchanges that support the use of Domains and Crypto Handles to support the transfer of crypto. In addition, we are trying to come up with new and interesting use cases that will make users want to create (and possibly exchange) domain, crypto handle, and signature assets. In other words, were are trying to make our existing assets more valuable.
The goal of FIO Assets is to drive more utilization of the FIO chain by providing infrastructure for the storage of NFT assets which are already known to be valuable to users.
TBD: Table of how many assets are being stored and the cost of storage
Blockchain Gaming, FIO Domains, and FIO Crypto Handles
Rather than casting a wide net, the FIO Assets project proposes focusing on blockchain gaming as its primary market. The gaming market already employs wide use of NFTs and there are many examples of marketplaces and Layer 1 protocols making revenue by supporting the gaming industry. In addition, there are several compelling use cases for the use of FIO Domains, FIO Crypto Handles, and NFT Signatures within the blockchain gaming.
TBD: need to organizes this into clear use cases:
Use Case | Summary |
|
|---|---|---|
Asset drops |
|
|
Support for wallet activation/signing |
|
|
Auto-sign NFT |
|
|
Gamer tipping |
|
|
Proof of origin |
|
|
Royalties |
|
|
NFT Marketplace integration |
|
|
Dashboard NFT Management |
|
|
TBD:
FIO Handle required
Further increase FIO Handle adoption
Better entry for prospective blockchain gamers if they are making use of bundles
Created fungible (ERC20 compatible) assets automatically create a new asset type for the FIO chain token_code. Once the token has been created, it cannot be reused by another party. This can help eliminate token copy cats and fraud. Of course, you can still prefix/affix other values to the token_code.
Will need to work on a solution to reserve the most popular 500 or so token_codes so they cannot be created without Foundation authorization
It may be a good idea for the asset contracts to have their own transfer functions to make implementation simpler; modifying fio.token=>trnsfiopubky and other actions to support assets from other contracts may become too cumbersome to implement and test
Reward and Claim actions that do not require users to sign additional authorizations
Claim makes use of arithmetic directly instead of an inline transfer action that would need an additional authorization for the token sender
The benefit to reward is that as an issuer, I can take back the reward or recalculate and reward again before it is claimed by the recipient into the recipient’s balance from the issuer balance
Stake/Unstake actions and table entries to allow reward calculation offchain based on locked stake amounts
The Money - Asset-based revenue
The Money objective aims to get FIO to economic sustainability. Fee-based revenue models generate revenue from the storage of assets and the secondary trading of those assets on marketplaces.
The goal of FIO Assets is to increase revenue through fees by supporting the storage and exchange of NFTs (initially) and other user-generated assets (in the future).
The revenue model for NFT assets is similar to that of FIO Domains with one exception: there is already a strong and growing market for storage of NFTs while the market for FIO Domains is still uncertain.
KPIs
TBD: need initial revenue model
Budget
TBD
|
|
|
|---|---|---|
WP Lead |
|
|
Engineering |
|
|
Business Development |
|
|
Marketing |
|
|
Notes
From Pawel: It is interesting that that Aurox's integration is very different from every other integration we had, in that they will be using the FIO Protocol as decentralized storage for their platform's (smart contract whitelists) and users' (tx metadata). I think we should document that as it expands the FIO use cases and perhaps can be adopted by others.
Links
|
|
|
|---|---|---|
AtomicHub |
| |
AtomicAssets Contract |
| |
Dgoods standard | https://github.com/ObsidianLabs/eos-studio-docs/blob/master/source/contracts/dgoods/index.rst |
|