There’s been an absolute riot of Cardano news lately that I thought it about time I made a blog post to comment on them all. I’ll start with the less technical news then gradually more on to the deeper end of the pool.
- Minswap Drama
You may remember Minswap as “that DEX that caused concurrency fud back in Sept causing the price to tank”. Well our favorite bungling DEX is back on the scene, this time they released their DEX, which became hugely popular but had a critical bug in the code which could have led to the loss of all user funds and a massive blow to the early Cardano DApp eco-system.
They were however saved by one of their competitors, Wingriders, who reviewed the code after Minswap had open-sourced it, and discreetly pointed out the vulnerability to them. Not only that but there were a few other bugs that they also pointed.
As a result Minswap were able to use the very same vulnerability to migrate user funds to a newer safer smart contract before any malicious hackers got to it. Hats off Wingriders for saving the day!
Now I’m being overly-critical here of Minswap. I’ve tried coding in Plutus, and this stuff is not easy. Furthermore the code was audited by Tweag who have done a detailed write up on the issue and also said that their audit had “found 3 critical issues that would have likewise enabled an attacker to empty the reserves, and 13 issues in total, but failed to find this one.”
There’s a lot to digest there. Are this many bugs in the code reflective of the quality of the Minswap team or the difficulty of Plutus? How did the auditors miss what they themselves admit in hindsight looks simple to spot? What can be done to spot these issues sooner?
Tweag themselves say they are working on automated tools that would have spotted issues like this. I’m thinking we need some open source community tool for checking Plutus smart contracts. Mind you such tools can only assist and spot simple bugs. Formal verification of DApps may help too, but to me there is a need here for sharing of best-practice and knowledge. I’m sure there will be more coming out from the aftermath of this especially as it relates to the certification of DApps, but for now let’s be thankful that no money was lost.
2. Milkomeda launch imminent
The Ethereum side-chain project known as Milkomeda has made amazing progress in the space of a few months and is now ready to launch on the 28th of March, so it’s likely they will have launched by the time you are seeing this.
This will allow Ethereum DApps to run on the Cardano blockchain, and both MuesliSwap and Milkyswap have stated they are planning to launch a DEX on Milkomeda. The Milkomeda team also mentioned that their testnet indicated “10M in TVL between wADA, USDC and USDT”. To have USDC and USDT being locked up in the Cardano ecosystem will be huge! This is made possible by their partnership with Nomad bridge.
3. Muesliswap v2 preview
Speaking of Museliswap, they dropped this bit of news on what is to come in the next version of their platform. The ability to trade on any Cardano DEX through their interface:
This is impressive! In addition the next version of their UI is significantly improved and looks much more like what you might see on Binance. I for one welcome this – I find their existing UI highly confusing to use.
4. Djed
Charles Hoskinson on his most recent AMA from Dubai, mentioned that Djed might come after the June hard fork in order to take advantage of the capabilities that brings. This will be disappointing news to those who have been eagerly anticipating the launch of a native stable coin on Cardano and Ada Whales response to my tweet on this has generated a lot of discussion. While disappointed, I’m buoyed by the news of the Milkomeda and Nomad partnership that will bring in stablecoins into the Cardano eco-system. It would be good to find out a bit more about the cause of the delay though, as well as whether it’s the simple or the extended Djed that will be launching as I’ve never been clear on this. (Extended Djed improves the stability of Djed).
4. June Hardfork
Speaking of the June hardfork aka Vasil hardfork, it looks to be a bumper edition. Apparently some of the updates that were initially planned for Feb were pushed to June as it made sense to bundle them together with the other improvements. These will cover CIPs 31,32,33, and 40 amongst others.
| CIP | Title | Description |
| 31 | Reference Inputs | allows looking at an output without spending it. This will facilitate access to information stored on the blockchain without the churn associated with spending and recreating UTXOs. |
| 32 | Inline Datums | Allow datums themselves to be attached to outputs instead of datum hashes. This will allow much simpler communication of datum values between users. |
| 33 | Reference Scripts | Allow reference scripts to be used to satisfy script requirements during validation, rather than requiring the spending transaction to do so. This will allow transactions using common scripts to be much smaller. |
| 40 | Collateral Output | adding a new output type to transactions called Collateral Outputs which removes the need for wallets to explicitly set collateral (which is bad UX) and improves safety of collateral at the same time |
5. TPS
IOG published a blog post recently detailing the performance improvements to be expected from various updates happening in the June hardfork. This does not include Input endorsers which is expected later in the year.
The blog provided estimates for what the TPS might be after various optimizations. After some initial confusion on my side I went back to my own prior estimates for TPS and realized the 20 – 170 TPS range, depending on the complexity of the transaction was freakishly close to my own back of the envelope estimates of 30-160.
These numbers are calculated as total transactions in a day divided by number of seconds in a day. By way of comparison, Avalanche is currently doing around 24 TPS on a daily basis, Algorand’s daily range is ~30-70, while Ethereum is doing ~13.
Note that these are the daily average TPS. It’s quite possible that a chain can process many more transactions in a particular second of the day when demand is high. Avalanche’s max observed TPS is 869 for example. Therefore I’m not clear from the blog post whether Cardano will similarly have a much higher TPS if looking across at the individual second level.
However it’s definitely good to hear that Cardano will be in line with other chains with regards to average daily TPS.
6. Input Endorsers
Another piece of the scalability jigsaw is input endorsers. This is expected to come out towards the end of the year though may creep into next. I’d been struggling to find a good explanation of what they are and how they might enable Cardano to scale until someone on Reddit recommended watching this video to me. It’s apparently the research that Input Endorsers are based on although it was done for Bitcoin. I highly recommend watching the video as it made a lot of sense but long story short it demonstrates that a TPS of 70,000 is quite possible. This puts it in the same order of magnitude as Solana and the researchers goes on to say the bottle neck shifts from the consensus mechanism to the storage mechanism (ledger keeping). This is pretty much word for word what Charles Hoskinson has said about Input Endorsers.
Therefore it could very well be that by the end of the year we will see Cardano able to achieve a TPS of 70,000 and that is without taking into consideration the ability to batch multiple transactions into one using the UTXO model!
7. Hydra
Charles commented on Hydra in his recent AMA. Apparently there is a timeline somewhere in the github repository but I was unable to find it. However Charles was quick to downplay the impact of Hydra. It’s something that is being worked on iteratively but won’t be in a fully usable form this year, with the focus being on the other aforementioned scalability improvements. Now there’s a lot of talk about Hydra enabling a million TPS. Let’s be clear – that’s only for certain specific use cases. In my head I imagine Hydra to be a payment network like visa designed to do high volume simple transactions. It won’t work for things like DEXES where the liquidity providers come and go. Hydra will do wonders in certain areas but it’s not the be all and end of for Cardano scalability.
8. zk-Snark on Cardano
One exciting area of development that can be applied to DEXEs however is a zkSnark rollup for the Cardano platform being built by Orbis as explained in this blog post.
“Cardano is in need of a scaling solution which makes minimal compromises to achieve maximum results and Hydra will not solve every scaling problem. We propose Orbis as the best possible scaling solution as it maintains all the core design principles of the Cardano blockchain while having the ability to scale the network to where it can safely host RealFi and DeFi applications at mass scale. The potential of ZK technology to transform the world in general and blockchains specifically cannot be understated. Orbis will enable all dApps on Cardano to achieve true mass adoption…
Initially, Orbis will launch with a single prover operated by Orbis Labs. Orbis will transition into a fully decentralized, distributed stack whereby network participants will exist in an open, permissionless network. Full decentralization of the prover means that there is no computer, individual or trusted entity which is a single point of failure. Full decentralization of the prover is not in scope of the initial release but is an eventual goal and commitment of the project.”
There’s no mention on timing but it’s certainly one to closely watch.
ReddSparks Crypto Blog 