Hi Everyone!
It is my great honor to share with you the CYCLES-TRANSFER-STATION - the CTS. The goal of the CTS is to bring the native CYCLES to the mainstream for use as a stablecoin. As many of you know the native cycles are stable at 1-TCYCLES = 1-XDR. This makes for the perfect stablecoin for the world-computer platform. The CYCLES stablecoin is perfect for services where a value must stay the same, such as an online t-shirt store, a DeFi stablecoin lending contract, storing money without price volatility, and many more services and dapps that need stablecoins. In this post I will share an overview on how the CTS manifests it’s goal.
As many of you know, the native CYCLES must be held by a canister-smart-contract living on the internet-computer blockchain and cannot be held by a key-pair-principal-identity alone. This brings us to the first function of the CTS: a mainstream-user can go into the CTS website UI (without writing any code) and create a personal smart-contract that holds, receives, and transfers the native CYCLES for the user. We call this personal smart-contract a CYCLES-BANK. Each user creates their own CYCLES-BANK to manage their CYCLES. Creating a CYCLES-BANK is a one-time thing, once a user owns a cycles-bank, it can last forever. Through the CTS website UI, the user can burn ICP and mint CYCLES straight into their cycles-bank (without any coding). As of the time of this post, creating a CYCLES-BANK costs 5-XDR one-time-fee and comes with a 1-year lifetime, 10-MiB of storage-space for the cycles-transfer-logs, and 2.0-CTSFuel for the cycles-bank.
For each cycles-transfer or transaction, the internet-computer blockchain network charges some cycles to the cycles-bank-smart-contract. The CTSFuel of the cycles-bank is cycles for the network transaction costs that are kept separate from the main cycles-balance and is labeled as the CTSFuel-balance. The storage-space cycles-cost is paid in advance ahead of time for the lifetime of the cycles-bank and when the lifetime is lengthened, so that the user will not see a dwindling cycles-balance or ctsfuel-balance for the network’s storage charges.
Within the cycles-bank UI, the user can lengthen the lifetime without limit by paying from it’s cycles-balance for the storage-space cost for the lengthened time. The user can grow the storage space (as of the time of this post up to 1-GiB) by paying from it’s cycles-balance for the added storage space costs for the remaining lifetime. The user can topup the ctsfuel-balance by using cycles from the main cycles-balance. Within the cycles-bank UI the user can transfer cycles and see the transfer-logs.
This brings us to the next function of the CTS: The CYCLES-TRANSFER-SPECIFICATION is the method that canister-smart-contracts can use to transfer cycles between themselves. The specification contains a memo field that can be used to identify specific cycles-transfers for payments for services. The cool thing about the cycles-transfer-specification is that businesses and services can create their own custom canister-smart-contracts that implement the cycles-transfer-specification and then be compatible with every cycles-bank to receive and send cycles! Blockchain smart-contracts for the win!
CYCLES-TRANSFER-SPECIFICATION:
type CyclesTransfer = record {
memo: CyclesTransferMemo;
};
type CyclesTransferMemo = variant {
Text: text;
Nat: nat;
Int: int;
Blob: blob;
};
service cycles-transfer-specification : {
cycles_transfer(CyclesTransfer) -> ();
}
A technical point on the specification is that there is no return value. This is because if there was a return value, a malicious smart-contract could for example return an error value indicating the cycles were not accepted while still accepting the cycles in the call which renders the return value useless. Cycles-transfers use the platform’s built in system functions for seeing if the cycles sent in a call were accepted or refunded.
The final function of the CTS is the CYCLES-MARKET. For the native CYCLES to succeed as a stablecoin within the world-computer, there needs to be a way for people to liquidate and trade their cycles into different currencies. The CYCLES-MARKET is the place where people can trade the native cycles for icp and icp for the native cycles in both ways. When trading on the cycles-market, users set the TCYCLES-PER-ICP-RATE for their position. This keeps the cycles stable at the market-value.
One of the current roadmap items of the CTS is making each user’s CYCLES-BANK into a wApp, where the smart-contract is in the user’s solitary controll, so that not even the CTS SNS DAO can change the code of the user’s cycles-bank. Only if the user opts-in to an upgrade can the user’s cycles-bank be updated. This gives the user complete surance for their valuable CYCLES.
Another item on the CTS roadmap is letting the cycles-banks transfer cycles direct from cycles-bank to cycles-bank or canister. Since cycles-banks can transfer cycles to any canister-smart-contract that implements the cycles-transfer-specification including smart-contracts that are not part of the CTS system, and since canister-smart-contracts that are not part of the CTS system can possibly be malicious and hold up a response which would stop the sender cycles-bank from being able to upgrade, currently the cycles-transfers go through a safe-transferrer-canister that makes sure that even if a callee holds up a response, the cycles-bank can still upgrade. Once the canister-safe-upgrades feature ships, user cycles-banks will transfer-cycles direct canister-to-canister without any intermediary.
The CTS is here: https://thp4z-laaaa-aaaam-qaaea-cai.ic0.app!
I welcome your feedback, questions, and comments!
Thanks for reading.
Levi.
.
as I can see immediate direction integration in communities. Well put & Brilliant reasoning 