:warning: The Cartesi team keeps working internally on the next version of this repository, following its regular development roadmap. Whenever there's a new version ready or important fix, these are published to the public source tree as new releases.

Token

Cartesi Token is an ERC20, with the following attributes:

• NAME = "CartesiToken";
• SYMBOL = "CTSI";
• DECIMALS = 18;
• INITIAL_SUPPLY = 1000000000 * (10 ** 18) (1 Billion)

The code imports two Open Zeppelin libraries: ERC20Detailed v2.5 and ERC20Mintable v2.5

The ERC20Mintable code implements the basic ERC20 standard, following the same definitions of the Open Zeppeling ERC20 code - including Safe Math, for sound mathematical operations. Being a mintable token means that the total supply of CTSIs can increase - as opposed to the capped version of ERC20. This minting behavior is implemented using the MinterRole library, also provided by OpenZeppelin. The minter is defined, initially, as the deployer of the token contract - and it has the power to create new tokens, add a new minter or renounce it's privileges.

The ability to create new Cartesi Tokens will be paramount to the network, it is a relevant part of the incentive layer/macroeconomics planned. The minting of new tokens will be entirely managed, in a decentralized way, by the macroeconomics smart contracts. In the beggining, while these smart contracts are not yet available, the Cartesi Token contract will have its minting blocked - by an override in its mint function. The amount of time that the minting privilege will be blocked for can be extended by calling the extendMintLockTime function - which will emit an mint locktime extended event (only the minter can call this function).

The decentralized minting process will be implemented and audited before the mintng locktime mechanism is released.

Vesting

The Cartesi vesting will use the design available in the TokenTimelock v2.5 contract, also provided by OpenZeppelin. This contract implements a simple token timelock, in which a certain amount of token is transferred to a deployed version of this contract and becomes available to a beneficiary after an amount of time - both of which are defined in the deployment. This version of vesting differs from the TokenVesting v2.5 in the way tokens are released. The TokenVesting contract offers a continuous and linear vesting procedure which was not a desired feature. In Cartesi we opted for a vesting design in which the tokens are vested following a step function - the total amount of tokens will be divided into a number of time periods and will be paid in full as these time periods expire. For instance, with vesting duration of one year, with a time period of 6 months, half the tokens would be vested at the same time after the first 6 months and then the other half when the 12 months finish. As opposed to having a tiny amount of tokens being released linearly every second. Part of Cartesi's tokens (CTSI) will be reserved for the so-called mine, which defines a decentralized incentive structure that pays workers for performing certain tasks on Cartesi network. The specifics of the mine contract are still being defined, so we created a special TokenTimelock version for it. It is very similar to the timelock mechanism defined above, differing in the sense that this version allows for a change in the beneficiary address - only callable by the owner. The idea is that the tokens will be locked from the beggining but the real beneficiary , the decentralized mine contract, will be set when its ready.

We chose OpenZeppelin v2.5 for both the token and vesting because it is the last stable release (v3 is still beta) and it includes specific purpose contracts - like MinterRole, which will be substituted by more general purpose ones (i.e AccessControl) in the next version release.

Faucet

For test purposes we created a SimpleFaucet contract that transfers 100,000 CTSI to any address, once every 4 weeks. This faucet is deployed to all supported testnets.