Discover more from Fairyproof Official Newsletter
Security Considerations on Implementing EIP-3475 Based Tokens
EIP-3475 is a proposal to create tokenized obligations with on-chain metadata storage. Here are some security points to implementers need to consider.
EIP-3475¹ is a newly submitted proposal to create tokenized obligations with on-chain metadata storage.
This EIP is created to solve the major problem of the existing ERC-20 based LP tokens not possessing data structures to handle complex redemption logic.
By adding a calldata data structure to store metadata as JSON objects, this EIP allows developers to define complex logic in the metadata of a token. Not only can this EIP be used to implement tokens with complex logic, but also bonds with complex business or redemption logic.
If we dive deep into the possible implementations of tokens based on this EIP, there are some security points implementers must pay attention to:
1. Ensuring Storage of Metadata On-Chain
A key point of this EIP is that the metadata that defines the token’s complex logic should be stored on-chain (For instance, on Ethereum.). This is to ensure the metadata is permanently available as long as the underlying blockchain works. Off-chain sources usually lack the capabilities to ensure permanent data storage compared to a blockchain like Ethereum, therefore, all of the metadata should describe the obligation terms and details on-chain instead of pointing to an off-chain source that describes said terms and details.
When auditing a token implemented based on this EIP, we need to check whether the obligation terms and details defined as metadata are stored on-chain.
2. Ensuring the Bond Issuer Has Sufficient Principals and Interests to Repay
The “redeem” function allows a bond holder to redeem his/her bond from the bond issuer. In order for the redemption to work, the bond issuer needs to have a sufficient amount of principals and interests accrued to pay back the bond holder.
Some of the existing DeFi applications invest users’ staked assets or principal assets to third-party programs for profits. However, if these third-party programs suffer from attacks, these investments may be lost.
Therefore, when auditing, we should
- Check whether the redeem function has a conditional check to ensure the bond issuer has sufficient assets
- And check whether the overall implementation has secured the principals and interests, especially when the application would invest users’ principals in third-party programs.
This applies to the “issue” function as well.
This function allows an issuer (i.e. a bank contract or even an EOA account) to issue any number of bond types to an address.
When we audit this implementation, we should not only audit its technical implementation but also its tokenomics and ensure the bond issuer has sufficient assets to pay back the bonds it issues.
Based on our experience, quite often, tokenomics security is more of a concern than technical security for implementations.
3. Access Control to Privileged Functions
There are three privileged functions:
i) burn(address _from, Transaction calldata _transactions) which is called to burn the bonds specified by “_transactions” held by “_from”.
ii) approve(address _spender, Transaction calldata _transactions) which is called to approve a spender to withdraw the bonds specified by “_transactions” from the “msg.sender”.
iii) setApprovalFor(address _operator, bool _approved) is called to authorize or revoke the right of “_operator” to withdraw all the bonds held by the “msg.sender”.
These three functions should be called with great care and usually by the admin. However, if the admin’s private key is compromised and these functions were called maliciously, unexpected risks would be introduced.
To mitigate this risk, the admin’s access control should be transferred to a multi-sig wallet or DAO.
In summary, as a blockchain security company, when we audit tokens implemented based on EIP-3475 we would cover these three areas:
i) From an implementation point of view: We would check whether the bond’s logic data is saved on-chain to ensure its data is sorted permanently on-chain.
ii) From a technical point of view: We check whether the access control to the privileged functions is safely and securely managed and maintained.
iii) From a tokenomics point of view: We would check whether the bond issuer has sufficient assets to ensure the application is financially secure.
¹ Yu Liu, Varun Deshpande, Cedric Ngakam, Dhruv Malik, Samuel Gwlanold Edoumou, Toufic Batrice, “EIP-3475: Abstract Storage Bonds,” Ethereum Improvement Proposals, no. 3475, April 2021. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-3475.