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
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 ofNFT assetswhich 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:
Bundle eligibility can be a useful tool for new users to acquire dropped assets to their wallet and transfer out without ever needing to purchase FIO from a 3rd party
Support for wallet activation/signing
FIO Crypto Handle can used to login to an interface to enable further interaction, yet there is no supported action
NFTs created on the FIO chain can automatically have an NFT signature created
Proof of origin
NFTs minted on FIO can be signed by creators, gamers, game developers, etc. to show proof of origin and history of trades
NFT Marketplace integration
API to enable direct integration with eosio-based marketplaces
Dashboard NFT Management
Use the dashboard to manage NFTs and other UX en
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.
TBD: need initial revenue model
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.