NTC – Neutrinite Trillion Cycles is similar to XTC and TCycles, but has a few key differences.
Let’s start with a short history of Cycles.
Simply put, anyone can convert ICP to Cycles based on the latest ICP/XDR rate, which updates using the Exchange Rate Canister (XRC) on demand. XRC makes HTTP outcalls from many nodes to various APIs, asking for the previous minute’s close prices. Each API has to return the same rate. At the end, all API rates are used (possibly via a weighted average), so we come up with one final rate.
I believe the initial goal of Cycles was for them to be a native IC stablecoin.
Every canister consumes Cycles for running, storage, and reserving CPU.
ICP has a few components: speculative, utility, and governance. When one converts ICP to Cycles, they retain only the utility component and give up the other two. For that trade-off, they gain certainty (to an extent).
If the ICP/XDR rate goes up over time, someone holding ICP and refilling with it will refill with more Cycles, compared to someone converting to Cycles right away and refilling canisters over time. But if the rate goes down, they’ll get less. However, if the NNS increases canister Cycle costs for messages, storage, etc., holding ICP will probably be better than holding Cycles.
Developers and their canisters appear to be subsidized currently. Depending on what developers do, in many cases they could load a subnet to capacity, while the Cycles spent may not cover the nodes cost. This would require new subnets to be created. That makes services consuming Cycles and using IC’s resources (for no good reason) net negative for ICP token holders. People don’t get more deflation from this-rather, inflation-because they’re burning through subsidies. If these services don’t use IC’s resources and just burn Cycles, that’s not a problem.
About half a year ago, some costs increased tenfold. But it’s hard to nail down canister costs because they’re based on usage, not on what happens. A canister can use chain-key cryptography to swap $1 billion using the powerful systems the IC has, but the IC will probably get 1 cent of burn from that.
And because the worst thing that can happen in crypto is often what does happen, I think this is true: On most (if not all) traditional no-finality chains, all transactions are crunched through AIs running in validators/miners, reorganizing blocks, and colluding with other validators through protocols to ensure they benefit as much as possible from that $1B moving through their chain. The transaction gets slowed down, censored, front-run as much as possible before it executes. That’s what the so-called ‘VCs’ profit from. It’s arguably not even part of the official MEV rewards distributed to stakers. It could also be why they don’t like the IC-it kind of hurts their business.
Currently, IC’s advanced cryptography and 2-second finality are unmatched by any other chain. But they’re hard to monetize. The only way to monetize them with the current flat-fee structure is through mass adoption - via products like Caffeine, Dragginz, etc.
Interestingly, developers who value decentralization and primarily build on Bitcoin, Ethereum, and Cosmos (the most decentralized chains) also like the IC and its capabilities. Other chains that, according to ChatGPT, are decently decentralized include Avalanche and Polkadot. Then there are chains about as decentralized as a dev running a Node.js DEX on their home PC - Base, Arbitrum, etc. - all centralized sequencer chains, which will probably be the last to use the IC for anything.
(Side note: Can people please stop shilling Base inside the IC ecosystem? It doesn’t even qualify as a real blockchain. Every contract on it can be fully controlled by the centralized sequencer. Transactions can be censored, front-run, positions liquidated, TVL inflated to oblivion.) Ledger.com Academy
Back to the original story.
Psychedelic DAO created XTC (the only wrapped Cycles at the time) and Sonic DEX - a constant product formula DEX.
People created the ICP/XTC pool and put around $1.5 million TVL inside.
The XTC price dropped in the following months from $1.30 to $0.30. People lost hope in the ‘native stablecoin.’
Psychedelic left - for other reasons - and handed off some systems to another team, which launched Sonic DAO.
Much later, DFINITY created the TCycles ledger so DFX devs could hold Cycles without a canister wallet and do everything they needed with it. But it never gained DEX adoption.
So why did the XTC rate fall so badly?
Initially, many thought someone had a lot of Cycles, minted XTC, and sold it. But in reality, the ICP/XDR rate fell. Because XTC was in a pool with ICP, its price went down. No one even had to sell for that to happen.
Unironically, buying XTC at that low was one of the best opportunities in IC DeFi. The thing is - it could be a good stablecoin after all; we just put it in the wrong pool. There was no ckUSDT or ckUSDC back then. When someone burns ICP for Cycles, they’re giving up the chance to sell them for liquid USD, so they aren’t really interested in selling them cheaper than they got them - unless they’re in a bind and over-minted.
Now we’ve launched NTC, and there’s an NTC/USD pair.
Why? Why not use TCycles?
We built a whole DeFi framework that has nothing to do with the officially documented way of doing DeFi on the IC.
Currently, the NTC mint is 170 lines of required code, using DFINITY’s SNSW ledgers, which we upgrade from one blessed ledger to another (governed by NTN).
We use two of our middlewares in it and want to stress-test them in production. We already have hundreds of PocketIC tests, but production is always the best testbed.
We’ve added one superpower already:
Every canister on the IC has an ICRC-1 address that anyone can send NTC to, and the canister will be topped up within seconds. It can be placed at the bottom of a frontend - so visitors can donate Cycles.
Our middleware still uses get_transactions, but we’re not sure whether to upgrade to ICRC-3. The TCycles ledger is custom and doesn’t support that. get_transactions is faster, doesn’t require additional parsing, and is more predictable and less error-prone. There’s nothing the endpoint can’t do (except off-chain phash verification, arguably not needed on-chain) that ICRC-3 can.
Plus:
-
Our NTC minter/relay is DoS-resistant
-
We have 2 new vectors around NTC
We’ve just added another superpower:
Making an NTC transaction to a specific ICRC-1 address makes our relay send that canister a best-effort call and passes it:
-
The
fromaddress -
The
memo(80 bytes)
One of our middlewares scans NTC ledger transactions (up to 80,000 tx per 5 seconds, parallelized), then passes them to another middleware, which launches on-demand threads (also parallelized) that make the calls and retry for a while.
Messages have priority - the higher the NTC tx amount, the faster they’ll be sent. It’s FIFO, but with priority. If a call fails, its priority is halved. This turns the NTC ledger into a kind of mempool.
Example call making ICRC-1 transfer (account derivable from canister principals - no need to call get_account).
The ntc method will receive the Cycles minus the fee whenever someone sends a transaction. Transactions will be prioritized based on amount. (If someone sends thousands of 0.00001 NTC transactions, a real user tx will still go through ASAP.)
This system is useful for devs who don’t want to deal with receiving ledger payments, which are hard to make DoS-resistant. We’d use this ourselves in projects for its simplicity. The other system we made that is DoS-resistant (and can receive payments) requires a canister to make thousands of calls with a timer - it costs ~$30/month and causes serious network congestion.
Some may be thinking - why build something few will appreciate or use, and not work towards mass adoption?
Well, writing this post probably took longer than the canister code. What we want is to ensure our systems run well and that we master our own tech before applying it to critical projects. As a side effect, someone might find it useful - we certainly will.
Next up: multi-chain tokens. Crypto, brace for impact!
You’ve even added a bit of game theory into the justification for using TCycles at all. Bravo 