SFT Whitepaper 03|Chapter 2: Financial NFTs: Applications and Technologies
In order to build a more sustainable and decentralized Web3, we must learn from simple financial NFTs and build far better financial NFTs.
Decentralized Finance, or DeFi, is a financial system that uses cryptocurrency and blockchain technology, instead of centralized intermediaries, to manage financial transactions. Similar to traditional finance (TradFi), DeFi’s primary objective is to maximize capital efficiency when allocating crypto assets.
In the broadest sense, financial NFT refers to tokenized ownership of advanced digital assets. However, leveraging financial NFTs without a proper infrastructure would be like building a house without a foundation — sooner or later, it would collapse. Two Ethereum token standards that use NFTs are ERC-721 and ERC-1155. ERC-721 NFTs are blockchain-based cryptographic assets with unique ID codes and metadata that distinguish them from each other, and ERC-1155 Multi-token Standard enables the implementation of multiple token types on a single deployed contract. Each of these standards serves as a financial NFT infrastructure in a slightly different way.
In this chapter, we’ll first delve into how each of these standards are contributing their skill sets to DeFi and then discuss their weaknesses as financial NFTs. In the second half of the chapter, we will provide a technical overview of these standards for the technologically-inclined readers of this book.
2.1 ERC-721 Financial NFTs
ERC-721 NFTs have been utilized by numerous DeFi protocols for a variety of purposes. To demonstrate the skills of NFTs in DeFi applications, we cover Uniswap, Centrifuge, and Solidly. Please note that this section is for educational purposes only and does not provide financial advice.
Uniswap
Uniswap is a decentralized exchange (DEX) that offers automated market-making (AMM) instead of the “highest bid-lowest ask” model. Uniswap v1 is an on-chain system of smart contracts on the Ethereum blockchain, implementing an automated liquidity protocol based on a what’s called “constant product formula.” Each Uniswap V1 pair stores pooled reserves of two assets, and provides liquidity for those two assets, maintaining the invariant that the product of the reserves cannot decrease. Uniswap V2 is a new implementation based on the same formula, which also enables the creation of arbitrary ERC20/ERC20 pairs, rather than supporting only pairs between ERC20 and ETH. The issue with V2, however, is that liquidity providers (LPs) have no active position management. Without it, liquidity is distributed in all price ranges between zero and infinity instead of within the range of LP’s own choice.
Uniswap V3 solves the position management problem by allowing LPs to create their own price range and receive an ERC-721 NFT representing the range. LP NFTs strike the right balance between capital efficiency and risk parity by providing the option of customizing laser-focused liquidity positions instead of committing capital unproductively to a wide range.
A transaction fee is used to reward LPs for taking on concentrated (customized) liquidity positions. As figure 2.2 shows, following the implementation of Uniswap V3, the protocol’s trading volume has increased.
With more capital flowing into DeFi, LPs need better risk-reward allocation and granular capital control. Therefore, the NFT will earn a reputation as a safe and efficient capital management tool, not just a nice-looking jpeg.
Centrifuge
Centrifuge is a network where real-world assets could be represented by ERC-721 NFTs for various purposes, such as lending. To finance real-world assets (RWAs), businesses (“asset originators”) can tokenize their financial assets into privacy-enabled NFTs and then use those NFTs as collateral in an open marketplace of real-world asset pools.
Users of Centrifuge bridge RWAs to DeFi through the network’s P2P protocol. The process is simple: asset originators mint NFTs from off-chain Centrifuge documents containing information about their assets and create a pool. After that, DeFi investors and protocols lock their investment in DAI into the liquidity pool and receive an ERC-20 token (called TIN or DROP) that enables them to earn a stable return from the asset originators.
Bridging RWAs to DeFi is all about ensuring the document with specific field types representing the asset cannot be easily manipulated. Using Centrifuge’s peer-to-peer (P2P) method, asset data could be tokenized into NFTs and verified between collaborators. Moreover, any service providers with document-level read access or field-level write access can be added as collaborators to demonstrate the verifiability of NFTs. (To learn more about how Centrifuge works, read its docs here: https://docs.centrifuge.io/)
Not surprisingly, regulations and compliance are mandatory for RWAs. Centrifuge’s prospects are attractive precisely because NFTs are highly descriptive, fraud-proof, and immutable, all of which place NFTs in a favorable light in the eyes of regulators and law enforcement.
Solidly
As a Fantom-based DEX, Solidly was launched by Andre Cronje, a well-known DeFi developer dubbed the “Godfather of DeFi.” Cronje is best known for his contributions to numerous Ethereum projects, including Yearn.
Among Andre’s most exciting innovations is ve(3,3), which utilizes “Flexible Emission Levels” to incentivize staking tokens into pools while creating a “win-win” value proposition for all participants. For example, if the total supply of a token is 10 million and 5 million tokens are staked, ve(3,3)’s flexible emission rate will yield 5 million tokens per week. These tokens are distributed to the market and LPs.
There are two weaknesses to veTokens (tokens representing lock positions). First, as veTokens cannot be sold or bought (no liquidity). Second, veToken holders cannot stake more tokens through the same address in a separate timeframe (no flexibility).
The solution is NFT. By wrapping veTokens into an NFT (“veNFT”), an LP can sell his or her veNFT in an open market or, if needed, secure a loan with it. Now that veNFTs are here, LPs can own multiple locks and enjoy the flexibility that comes with it.
2.2 ERC-1155 Financial NFTs
Fuji DAO
Fuji DAO is an infrastructure protocol that aggregates lending-borrowing crypto markets. It sources its liquidity from three lending protocols: Compound, Aave and dYdX. Fuji DAO proposes isolated debt positions for each collateral/borrow pair, allowing for better risk management and more effective interest rate optimizations.
As a borrowing aggregator, Fuji DAO is generally required to map its internal positions relative to a protocol, using, for example, Aave debtToken standard, an ERC-20 position-mapping approach.
However, the ERC-20 standard has some complications that limit Fuji DAO’s capacity as an aggregator, like deploying extraordinary amounts of smart contracts, needing more approvals for each transaction, hefty gas fees, as well as the fact that Aave debtToken was an interest-bearing and non-transferable asset.
The scheme in Figure 2.6 shows that to swap ERC-20 cryptocurrencies, the user must approve each transaction and then approve the swap operations. This is not only inefficient, but also will result in gas price spikes during periods of volatility and high volume of swapping activities.
The ERC-1155 standard is a token framework created by the blockchain-based gaming platform and asset marketplace, Enjin, which allows for more efficient trades by bundling transactions, making transfers less expensive.
With ERC-1155 tokens, multiple currencies or assets can be swapped at once, and users can enjoy a host of benefits including fast transaction approval and reduced gas fees.
Alpha Homora V2
Homora is DeFi’s first leveraged yield farming protocol, built by Alpha Venture DAO. In Alpha Homora V2, yield farmers (who are liquidity providers) can perform leveraged yield farming on numerous asset pairs and DEXes and receive higher farming APY and trading fee rewards than other no-leverage yield farming protocols.
Like Fuji DAO, Alpha Homora V2 tokenizes farming positions into ERC-1155 financial NFT, which are treated as a class of ERC-20 tokens grouped by IDs. Since reward amounts for farming positions depend on two factors, LP shares (how much LP is staked by the user) and stake time, if two users stake at the same time, their rewards split will simply be proportional to their LP shares. Thus, positions with the same stake time will have the same ID and can receive rewards efficiently under the one ERC-1155 smart contract, instead of numerous ERC-20 ones.
Being a less “fragmented” solution to the pain point of deploying a separate contract for each new token, ERC-1155 enables projects like Homora V2 to reduce gas expenses as well as frictions to manage farming rewards by allowing them to interface with a multi token standard.
Furthermore, Alpha Homora V2 utilizes ERC-1155 tokens to tokenize farming positions to use as collateral, while the actual LP tokens must be staked at the corresponding staking contracts to earn yield farming rewards.
2.3 Technical Overviews of ERC-721 and ERC-1155
2.3.1 ERC-721 Non-fungible Token Standard
ERC-721 NFTs are blockchain-based cryptographic assets with unique ID codes and metadata that distinguish them from each other. What’s at the core of an ERC-721 NFT is _tokenID, which is a 256-bit unsigned integer that enables the identification of an ERC-721 NFT. _tokenID represents the uniqueness of ownership over the token itself as well as whatever underlying (digital or physical) assets it has.
To describe the ownership, ERC-721 has a metadata extension featuring properties of name, description, and image, all of which delineates the key information associated with the token:
{
“title”: “Asset Metadata”,
“type”: “object”,
“properties”: {
“name”: {
“type”: “string”,
“description”: “Identifies the asset to which this NFT represents”
},
“description”: {
“type”: “string”,
“description”: “Describes the asset to which this NFT represents”
},
“image”: {
“type”: “string”,
“description”: “A URI pointing to a resource with mime type image/* representing the asset to which this NFT represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive.”
}
}
}_tokenID is useful for the mapping of financial applications with users’ various demands. Furthermore, the enhanced text description within ERC-721’s metadata helps differentiate configurations with complex equities of a specific scenario, such as multi-position market-making. With visualization, the image file in the metadata will display information that can’t be presented easily in plain text.
Another core feature of ERC-721 is address-to-address transfer, implemented through transferFrom() and safeTransferFrom() and executed on _tokenID (other than _value in an ERC-20 token):
/// @notice Transfers the ownership of an NFT from one address to another address
/// @dev This works identically to the other function with an extra data parameter,
/// except this function just sets data to “”.
/// @param _from The current owner of the NFT
/// @param _to The new owner
/// @param _tokenId The NFT to transfer
function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable;/// @notice Transfer ownership of an NFT — THE CALLER IS RESPONSIBLE
/// TO CONFIRM THAT `_to` IS CAPABLE OF RECEIVING NFTS OR ELSE
/// THEY MAY BE PERMANENTLY LOST
/// @dev Throws unless `msg.sender` is the current owner, an authorized
/// operator, or the approved address for this NFT. Throws if `_from` is
/// not the current owner. Throws if `_to` is the zero address. Throws if
/// `_tokenId` is not a valid NFT.
/// @param _from The current owner of the NFT
/// @param _to The new owner
/// @param _tokenId The NFT to transfer
function transferFrom(address _from, address _to, uint256 _tokenId) external payable;
Note that ERC-721s and ERC-20s differ in the token transfer process. Transferring an ERC-721 NFT from one address to another means transferring proof of ownership in its entirety while transferring ERC-20s means the transfer of numerical value of the same ERC-20 token.
2.3.2 ERC-1155 Multi Token Standard
ERC-1155 Multi-token Standard enables the implementation of multiple token types on a single deployed contract. The standard was created so that multiple types of in-game items (fungible or not) could be deployed on a single deployed contract. Its widest usage is in blockchain games.
Technically, both ERC-20 and ERC-721 require a new contract to be deployed for each token type or collection. This mechanism adds superfluous bytecode to Ethereum and thus hurdles certain functionalities such as token-address separation.
ERC-1155’s main data structure is _id, which represents configurable token types, and _value, a quantitative attribute representing the transfer amount of the corresponding token. Like the ERC-721, ERC-1155 also features a metadata extension defined by things like name, decimals, description, image, and other arbitrary properties. Here is ERC-1155’s JSON Schema:
{
“title”: “Token Metadata”,
“type”: “object”,
“properties”: {
“name”: {
“type”: “string”,
“description”: “Identifies the asset to which this token represents”
},
“decimals”: {
“type”: “integer”,
“description”: “The number of decimal places that the token amount should display — e.g. 18, means to divide the token amount by 1000000000000000000 to get its user representation.”
},
“description”: {
“type”: “string”,
“description”: “Describes the asset to which this token represents”
},
“image”: {
“type”: “string”,
“description”: “A URI pointing to a resource with mime type image/* representing the asset to which this token represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive.”
},
“properties”: {
“type”: “object”,
“description”: “Arbitrary properties. Values may be strings, numbers, objects, or arrays.”
}
}
}Distinct from ERC-721’s _tokenID, which represents a token’s identification, ERC-1155’s _id represents the configurable type of a token. An ERC-1155 powered sword may have several attributes in terms of its material, color, power, and so on. When a forge or transfer event occurs, ERC-1155 removes the need to deploy multiple contracts for each of the sword’s attributes and, instead, implements the event in a single transaction.
In financial applications, ERC-1155’s _id and corresponding metadata can be utilized for differentiated, more nuanced configurations with complex equities, with certain quantitative operations on attribute _value. Because tokens under ERC-1155 with the same _id are fungible, ERC-1155’s financial applications may be limited as financial contracts in a broad sense non-fungible.
Visualization is key to differentiating financial NFTs from NFT collectibles. ERC-1155 tokens’ ability to embed image files in their metadata means they are good at delivering information visually which can’t be delivered easily with plain text.
Another core feature of ERC-1155 is address-to-address transfer, implemented through safeTransferFrom() and executed through ( _id, _value):
/**
@notice Transfers `_value` amount of an `_id` from the `_from` address to the `_to` address specified (with safety call).
@dev Caller must be approved to manage the tokens being transferred out of the `_from` account (see “Approval” section of the standard).
MUST revert if `_to` is the zero address.
MUST revert if balance of holder for token `_id` is lower than the `_value` sent.
MUST revert on any other error.
MUST emit the `TransferSingle` event to reflect the balance change (see “Safe Transfer Rules” section of the standard).
After the above conditions are met, this function MUST check if `_to` is a smart contract (e.g. code size > 0). If so, it MUST call `onERC-1155Received` on `_to` and act appropriately (see “Safe Transfer Rules” section of the standard).
@param _from Source address
@param _to Target address
@param _id ID of the token type
@param _value Transfer amount
@param _data Additional data with no specified format, MUST be sent unaltered in call to `onERC-1155Received` on `_to`
*/
function safeTransferFrom(address _from, address _to, uint256 _id, uint256 _value, bytes calldata _data) external;Batch Operations make it possible to operate over multiple tokens in a single transaction efficiently. ERC-1155 provides two functions, balanceOfBatch() and safeBatchTransferFrom(), that make querying multiple balances and transferring multiple tokens simpler and less gas-intensive.
/**
@notice Transfers `_values` amount(s) of `_ids` from the `_from` address to the `_to` address specified (with safety call).
@dev Caller must be approved to manage the tokens being transferred out of the `_from` account (see “Approval” section of the standard).
MUST revert if `_to` is the zero address.
MUST revert if length of `_ids` is not the same as length of `_values`.
MUST revert if any of the balance(s) of the holder(s) for token(s) in `_ids` is lower than the respective amount(s) in `_values` sent to the recipient.
MUST revert on any other error.
MUST emit `TransferSingle` or `TransferBatch` event(s) such that all the balance changes are reflected (see “Safe Transfer Rules” section of the standard).
Balance changes and events MUST follow the ordering of the arrays (_ids[0]/_values[0] before _ids[1]/_values[1], etc).
After the above conditions for the transfer(s) in the batch are met, this function MUST check if `_to` is a smart contract (e.g. code size > 0). If so, it MUST call the relevant `ERC-1155TokenReceiver` hook(s) on `_to` and act appropriately (see “Safe Transfer Rules” section of the standard).
@param _from Source address
@param _to Target address
@param _ids IDs of each token type (order and length must match _values array)
@param _values Transfer amounts per token type (order and length must match _ids array)
@param _data Additional data with no specified format, MUST be sent unaltered in call to the `ERC-1155TokenReceiver` hook(s) on `_to`
*/
function safeBatchTransferFrom(address _from, address _to, uint256[] calldata _ids, uint256[] calldata _values, bytes calldata _data) external;2.4 Summary
Flexibility in creating on-chain financial tools and assets will be in high demand in the coming years. The ERC-721 and ERC-1155 NFT standards may work, but they are not long-term solutions due to their lack of liquidity and flexibility. A major disadvantage of ERC-721s is that they cannot be fractionalized, do not support token-to-token transfer, and their metadata is only suitable for displaying static art, not real-time data feeds. While ERC-1155 is a gamers-driven standard focused on representing and transferring homogeneous items, the level of numerical fine-tuning and granularity required by most sophisticated financial applications are not within the skill set of ERC-1155. Both ERC-721 and 1155 lack the expressivity and would rely on smart contract developers for each new use case that surfaces. Therefore, it may be appropriate to classify ERC-721s and 1155s as simple financial NFTs.
In order to build a more sustainable and decentralized Web3, we must learn from simple financial NFTs and build far better financial NFTs. Maybe the ERC-3525 Semi-Fungible Token Standard will fit the bill.
You can download the SFT whitepaper here: https://sftlabs.io/
A telegram group for EIP-3525 builders: https://t.me/EIP3525_DEV
