The token attempts to implement the SIP 10 standard. stacksgov/sips#5
This token standard implements the "Standard Trait Definition for Fungible Tokens." This trait exposes functions for token metadata:
- get-name
- get-symbol
- get-decimals
- get-token-uri
The get-token-uri
method mimics the functionality found on the ERC721 standard. The expectation is that a token owner can set this to reference an external URI that contains extra metadata about the token (such as logos, agreements, or other documentation)
In addition to metadata, it exposes functions for querying the current total supply of the token and the balance for a specific account:
- get-balance
- get-total-supply
Finally, it defines the function for transferring tokens:
- transfer
This trait is defined in ft-trait.clar
.
The following public functions are available similar to ERC1404:
- detect-transfer-restriction
- message-for-transfer-restriction
If any restrictions are put into place that would prevent a transfer from succeeding, the standard transfer
function would fail with a u403
error code. 403 was chosen to mimic the HTTP 403 Forbidden
status.
A wallet should check the detect-transfer-restriction
function to determine why the transfer was restricted, and then can return a human readable message found by calling message-for-transfer-restriction
to the user to take corrective actions.
This trait is defined in restricted-token-trait.clar
.
Each deployed token should have a different name, symbol, etc. The principal that deploys the contract can call an initialize
function on the contract to set all initial values. This function can only be called once and will set the following:
- Token Name
- Token Symbol
- Decimals
- Initial Owner Principal
The reason that these items are set dynamically is that once the contract has been audited, we don't want to accidentally make any changes to the source code that could affect the functionality. Also, if this contract represents a registered security, it may be necessary that the deployer (e.g. Wrapped) never holds the ownership role of the contract.
The token has certain roles built into it to allow administrative actions. One or more principals can be granted each of the roles and a principal can be granted multiple roles. The following roles are available:
- Owner
- Minter
- Burner
- Revoker
- Blacklister
By default, the account specified in the initialize
call will be granted the Owner
role. The Owner
role is the only role that can add or remove other accounts from roles.
NOTE!!! If all owners are removed then no other role administration can be performed. Any time an owner removes themselves, great care must be taken to ensure another owner still exists. Also, this means that all admin functionality can be irrevocably disabled by removing all roles from all principals.
A principal with the Minter
role can mint new tokens to any principal. The total supply of the token will be increased when new tokens are minted.
A principal with the Burner
role can burn new tokens from any principal. The total supply of the token will be decreased when existing tokens are burned.
A principal with the Revoker
role can move tokens from any principal to another principal.
A principal with the Blacklister
role can add or remove any principal to a blacklist. Any transaction sending tokens to
OR from
a blacklisted account will be denied and the transaction will fail.
Install dependencies:
yarn install
yarn test
Stop by our Telegram or send us an email.