Greetings world-computer community.
In this cold and dark of the winter, the CYCLES-TRANSFER-STATION launches as the home for the native CYCLES.
The CYCLES are the fuel that canisters need to pay the network for the storage and computation of the canisters’ code systems. When cycles are paid to the network, the cycles are burned. This creates a constant need for the cycles and puts buy-pressure on the cycles. The more systems and services hosted on the internet-computer, the more buy-pressure there is on the cycles. This constant buy-pressure creates a scenario where now even people who are not hosting canisters can utilize the cycles as a stable store of the value, since the cycles can be liquidated due to the constant need/buy-pressure for the cycles.
The CYCLES-TRANSFER-STATION - the CTS, is where people on both sides of the equation come together and trade their goods back and forth in both ways.
The first step is that mainstream users need the ability to mint and hold the cycles. Through the CTS, users create their own personal CYCLES-BANK that can mint, hold, transfer, and trade the native cycles on the world-computer.
Through the user’s personal CYCLES-BANK, the user can burn ICP and mint CYCLES direct through the NNS straight into the user’s cycles-bank. Logs of the cycles-transfers are kept in the user’s cycles-bank. Cycles transfers are done through the cycles-transfer-specification which is a simple method and types for transferring cycles, with a memo for identifying payments, where both sender and receiver can know how many cycles are being transferred and make a log for the transfer.
Technical note: At this time, cycles-transfers are limited to only transferring between CTS cycles-banks. This is because of the security concern that an unknown canister can hold up a response and try to prevent the cycles-bank from upgrading since at this time canisters need to finish handling all callbacks before upgrading. This restriction will go away when the name-callbacks feature on the DFINITY roadmap is implemented. Then the cycles-banks will not need to wait for a response in order to upgrade.
The CYCLES-BANKS also have a special function for the canister coders and developers, the ability to use the management-canister’s deposit_cycles method to deposit cycles onto any canister (even canisters not part of the CTS). However be careful using this button as there is no way for the receiving canister to know about the transfer or log the transfer. To accept cycles as payment for a service, instruct users to send cycles using the main method on the main page that uses the cycles-transfer-specification. With that said, this developer-only functionality is useful for developers that want a user-interface on a webpage where they can burn icp and mint cycles straight into their cycles-bank and then deposit the cycles onto any canister.
The second step is the CYCLES-MARKET trade-contracts, where people trade the native CYCLES and many different ICRC-1 tokens back and forth in both ways. The CTS cycles-market is a position-book (order-book) market where users set the rate (price) for the trade. The position then goes onto the book, if there is a matching position, the trade is made, if there is no current matching position, the position is put onto the book, and waits for a match. The position-book is a requirement for the stability of the cycles and makes sure that the cycles-market shows the true market value of how much the market is willing to pay for the CYCLES.
The CTS is live here: https://cycles-transfer-station.com.
:Levi.
