Summary
The Token Integration Standard (TIS) is a set of security requirements for a Token to help decide whether integrating specific Tokens poses known and unacceptable security risks.
Table of Contents
Introduction
Purpose
The goal of the this specification is to provide a set of security requirements for description and use of Tokens such that Tokens which meet these requirements provide a high level of safety assurance for common integration cases.
To reach these requirements we have considered the combination of technical robustness, operational resilience, and economic integrity ensuring the token’s safe functionality, reliable governance, and protection against malicious or unintended exploits, to capture the inherent trade-offs between trust, security, and decentralization, while being flexible enough for diverse Token implementations.
Important: Note Well: It is not possible to provide a formal security guarantee for a Token. Meeting the requirements in this specification does not constitute such a guarantee, it simply identifies that the Token or Token holders are unlikely to be maliciously exploited through a specific set of common and well-known vulnerabilities.
It is important to understand that while careful review is important to minimise the likelihood that a Token is unsafe, safety cannot be guaranteed by compliance with this specification. Carefully and correctly meeting the requirements outlined in this document will minimize the chance that a Token is exposed to a number of known vulnerabilities, and is thus likely to be more secure than a Token that contains a known exploitable vulnerability. However, it is not a guarantee that there are no vulnerabilities.
Please see also the Disclaimer of Warranty and Liability.
Scope
This specification currently explicitly covers [ERC-20] Tokens, and by extension, compatible [ERC-1155] Tokens. While the content of this specification might be useful for assessing other types of Tokens, the BSSC has not explicitly considered them in developing this specification.
Future revisions of this specification MAY cover more types of Token.
Conformance
The key terms "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document MUST be interpreted as described in [RFC2119] as modified by [RFC8174] when they appear in all capitals, as shown here.
TIS Requirement Domains:
The TIS requirements are spread over 6 domains:
This division is intended to help drive careful consideration of the diverse aspects of security that all contribute to ensuring a Token is sufficiently well-secured to enable a high level of confidence to third parties integrating it.
Requirements Domain 1: General Information
The Token Project MUST provide the following information:
Token allocation
Token allocations and vesting schedules.
Name and Symbol
The Token Name and Token Symbol. These MUST match the values returned by the name() and symbol() methods, respectively.
Technical Documentation
A link to technical documentation of the Token.
Contact Information
Contact information for the team who manage the Token Project.
Deployment Address
The address(es) of Token Contracts deployed by the Token Project, on each blockchain where they have deployed it.
Is it native, bridged, wrapped?
Whether the Token is native, bridged, or wrapped.
Token Rebasing
Any circumstances in which the Token will rebase, and how such rebasing is applied.
Document Upgradability
Whether the Token Contract is upgradeable.
Trading History
The Trading and TVL history of the Token since deployment.
Price discovery mechanism
If the Token Contract supports Minting or Burning, what automated price discovery mechanisms are available.
Stablecoin Backing
If the Token claims to be a Stablecoin, an explanation of the stabilization mechanisms for the Token's value.
Requirements Domain 2: Governance
The Token Project MUST document how the Token is governed, and provide a list of all the privileged roles in the Token Contract.
Decentralize Privileged Roles
Privileged Roles SHOULD be decentralized through a Multisig.
Identify Parties Controlling Critical Actions
The Token MUST provide documentation identifying the parties or contracts that control any Critical Functions including any of the following functions:
- Emergency procedures such as pausing, locking, or self-destruction of the Token,
- Modifying any allow list or deny list,
- Token Contract Upgrades (See also Requirements Domain 4: Upgradability),
- Minting Tokens,
- Burning Tokens on a user's behalf, and
- Account management that impacts any Privileged Role.
Document Multisig
The Token Project MUST document the nature of any Multisig that enables any Privileged Roles, including relevant multisig wallet address, total number of signers, the quorum required to execute these functions, and attestation of whether this enforces authorization by entities known to be independent (e.g. different individuals).
Document DAO Governance
If any Critical Functions are managed by a DAO, the Token Project MUST document how the DAO is governed, including:
- entities that control any Critical Functions in the DAO,
- The process to obtain governance tokens, create proposals, and vote,
- All DAO parameters (minimum quorum, approval/veto threshold, voting period, etc.), and what privileged roles have the ability to alter these values, and
- Whether the Token Project has the ability to override a DAO proposal, and if so, how and under what circumstances.
Requirements Domain 3: L1 Network Security
While there are no formal requirements in this section, it is important to consider the security of any blockchain on which a Token is deployed.
The overall processing power, the level of decentralization, and the general level of activity in a blockchain can all provide information that helps make an assessment of whether a specific blockchain is likely to be a reliable platform for a Token under consideration.
Requirements Domain 4: Upgradability
Not upgradable
The Token SHOULD NOT be upgradable.
If the Token is upgradeable, the Token Project MUST document the following:
Document upgradable components
Which components are upgradable.
Can users upgrade voluntarily
Whether users can voluntarily upgrade their assets.
Document Timelocks
When an upgrade can happen instantaneously and when there is a time-lock delay.
Document upgrade logic
The design logic of the upgrade mechanism.
Document upgrade process
How upgrades are approved and implemented.
Document upgrade communication
When and how the Token Project provides public communications around upcoming upgrades.
Document ERC-20 upgradability
Whether Token Contract directly includes the ERC20 implementation, or is a proxy forwarding to it.
Requirements Domain 5: Security Posture
It is important to understand what work has been done to ensure the Token's security.
Document Security Posture and Procedures
The Token Project MUST document
- Vulnerability disclosure processes,
- Emergency contacts, expected responsiveness levels and response availabilities, and
- Any disaster recovery plan and preparations.
Contract Security Review
The Token Project MUST provide at least one security review of the currently deployed Token Contract code, and SHOULD
- provide at least one Conformance Claim that the Token Contract conforms to [[EthTrust](#ethtrust)] level [Q], and
- publish all security reviews of the Token Contract.
Bug Bounty
Token Projects SHOULD have an active bug bounty program.
Requirements Domain 6: Token Behaviors
Implement ERC-20 methods
A Token Contract MUST implement all the methods defined in [ERC-20].
Balance changes create Transfer Events
Any methods in the Token Contract that change Token balances, such as transfer(), mint(), burn(), etc MUST emit a Transfer event as described in [ERC-20].
If Tokens are created, the from address in the event MUST be set to the zero address, and if they are destroyed the to address in the event
MUST be set to the zero address.
For example
function _mint(address account, uint256 value) internal {
//Actual logic, check, effects, interactions, ...
emit Transfer(address(0), account, value);
}
Supply Changes Create Mint or Burn Events
Methods in the Token Contract that change the Total Supply of the token MAY emit specific events:
- Where the Total Supply of Tokens is increased, an event called
Mintwith parametersaccountof type `` specififying the account to which the tokens were added, andvalueof typeuintspecifying the number of token units (the smallest recorded fraction of a token as determined by the methoddecimalsin the Token Contract) added to the accountaccount.
- Where the Total Supply of Tokens is decreased, an event called
Burnwith parametersaccountof type `` specififying the account from which the tokens were removed, andvalueof typeuintspecifying the number of token units (the smallest recorded fraction of a token as determined by the methoddecimalsin the Token Contract) taken from Total Supply.
Extending the example given for Balance Changes Create Transfer Events above, this could be implemented with
function _mint(address account, uint256 value) internal {
//Actual logic, check, effects, interactions, ...
emit Transfer(address(0), account, value);
emit Mint(account,value);
}
No over/underflow
The Token Contract MUST conform to the EthTrust Requirement "[S]No Overflow/Underflow".
Implement C-E-I
The Token Contract MUST conform to the EthTrust Requirement "[S] Use Check-effects-interaction".
No fallback function
The Token Contract SHOULD NOT have a fallback function. If the Token Contract has a fallback function, it MUST document when it reverts.
No transfer or method hooks
The Token Contract MUST NOT implement any transfer hooks or hooks on any method.
No tx.origin
The Token Contract MUST conform to the EthTrust Requirement "[S] No tx.origin".
Use standard signatures
The Token MUST NOT use non-standard transaction signatures (i.e. outside the format of a standard Ethereum transaction). If so, the Token MUST have been audited.
No 96-bit integer operations
The Token Contract SHOULD NOT use 96-bit integers for mathematical operations.
Specified integer size
The Token Contract MUST specify the integer size used in mathematical operations. If 96-bit integers are utilized, this MUST be documented, and the contract MUST ensure precision and prevent overflow errors.
Specify transaction limits
The Token Contract MUST specify any limitations on the number of transactions a user can initiate within a given timeframe. If such rate limits exist, they MUST be clearly defined and documented.
Define transaction size limits
The Token Contract MUST define any thresholds for the amount of tokens a user can send in a single transaction. If such thresholds are set, they MUST be explicitly stated and documented.
Restrict Transfers from Blocked or Frozen Accounts
If the Token Contract implements a method to block or freeze accounts, transfers initiated from a blocked or frozen address MUST revert.
Revert Blocked Transfers
Where a Token Contract blocks a transaction from interacting with a specific account, it MUST cause the transaction to revert with a clear error message, for example "Transfer to blocked address is not allowed".
Document Whether Blocked Accounts Can Receive Transfers
The Token Contract MUST document whether deposits to blacklisted or frozen addresses are allowed or blocked.
EthTrust Requirements
The EEA EthTrust Security Levels Specification [EthTrust] provides a comprehensive description of known vulnerabilities for smart contracts written in Solidity. This specification makes reference to various specific requirements of that specification, incorporating the relevant requirement by reference.
In many cases the specific requirements are multi-layered, with a simple testable assertion such as "there is no tx.origin in the code", and an 'overriding requirement' for cases where the simple assertion is not met, that allows meeting the requirement by ensuring sufficient review has been done to provide a reasonable level of security in such cases.