Wow, this was a stream of questionable to outright mind-bogglingly ridiculous problems and decisions!
Maybe, other projects can learn from this debacle.
The “Support”
Shortly after the start of the Glacier Drop, the Midnight team made very clear that they will not provide any support in their Discord server:
The only official support channel was a chat hidden on their FAQ page:
The reports on how good the help provided by that chat was vary a lot. For quite some users, it made the impression of mainly useless AI slop. Others were more satisfied.
In any case, users were, of course, roaming the Midnight Discord and all Cardano forums, anyway, easy prey for all kinds of scammers. So much that the Cardano Telegram group and this forum had to introduce standard messages redirecting people to the proper channels:
Some users have answered questions in the Midnight Discord for the whole two and a half months without being commissioned or being supported by Midnight for that, just to not let it completely implode. (The admin of the Discord has at least tried to ban scammers swiftly and gave us the permission to timeout scammers and delete scam messages at some point. Thanks for that!)
I don’t know why that has to be stated, but: If you start something of this scale, you, of course, have to have a support team that is responsive 24/7 and monitors at least your channels, ideally also the channels of closely related projects – Cardano in this case!
Scattered and Unclear Information
In my opinion, it was already a bad decision to launch a completely separate website – https://www.midnight.gd/ – and not implement that as an integral part of the already known https://midnight.network/. Every instance of such a move makes the usual advice to only go to already known sites weaker.
So, information about how this all works was in the end scattered over https://midnight.network/blog, https://www.midnight.gd/news, https://www.midnight.gd/faq, https://www.midnight.gd/how-to-get-night, the tokenomics whitepaper downloadable at https://www.midnight.gd/#tokenomics, …
A disappointing number of users coming into the various channels with questions very clearly had read none of those, but even if they had tried, it is more than understandable if they did not find the information relevant to their specific case in this maze.
One of the most important sources was the “News” article “Glacier Drop wallets and address type compatibility”: https://www.midnight.gd/news/glacier-drop-wallets-and-address-type-compatibility
Unfortunately, this wall of text was not really end-user friendly. It required a lot of hand-holding to get users to find that that document, e.g., quite clearly states that Bitcoin addresses starting with 3… were not eligible at all.
It also was not properly updated and some alternatives were never mentioned at all.
It still says that “null transaction signing” is “undergoing audit”, while it was launched at the beginning of September with more than enough time to do the claim.
It never mentioned NuFi as the only method to claim for XRP on a Ledger.
It never mentioned @ATADA’s cardano-signer as the tool to do manual Cardano signatures for cases where people could not or did not want to import their keys into a browser wallet app.
For all chains, it just states “manual path: verified” without any detail how the f to execute that “manual path”. Even if you know your way around several blockchains, you need some more information on standards, algorithms, and encodings to successfully do a manual signature. D’uh!
If you plan to target a huge crypto audience, put a little more effort into giving less confusing, but specific and comprehensible information! And please provide the technical details, so that people not affiliated with you can help better!
Claim Portal User Experience
Although they did know that manual signatures were not for the faint of heart (especially because – see above – they did not give us any hint which tools, formats, … they expected and tested)
they happily offered to manually give an origin address at the very beginning of the claim process without any warning:
I have seen dozens if not hundreds of users to whom we had to explain that the choice of manual origin address at the very beginning made that they also were asked for a manual signature at the very end. Obviously not intuitive.
Could have easily been made better by a) giving a clear warning about that, b) switching the order and first give the destination, then the origin so that the connection is clearer (would have maybe also helped the dozens of users who thought that they had to sign with the destination wallet), and/or c) offering to connect a wallet app to sign at the end even if the address was given manually.
Another big UX fail was the introduction of “null transaction signing”. After that was activated, this screen was presented to everyone claiming for Cardano:
Lots of users interpreted this as an error, not as something that they can just continue. Even more thought it had something to do with their specific wallet, not a generic warning given to everyone. Problem was made larger by the poor implementation of “null transaction signing” (see below) which means that some users had to choose “try message signing anyway” although this screen strongly recommends otherwise.
Nice to haves would have been: If an address is given manually, immediately give information if that address type is not supported at all, so that the users do not waste more of their time trying. Extra bonus points for: State explicitly if the address would have been eligible technically, but was excluded by the third-party auditor. Again, so that users can stop wasting their time. (And you cannot tell me that there are legal reasons to not state that if that is exactly what the support chat told every user asking as “likely” explanation for them not being eligible.)
The “Unused Address” Confusion
That the destination address has to be an unused address already led to confusion before the claim process was even started. And that confusion was completely unnecessary.
While the tokenomics whitepaper claims that that requirement is “best practice”
I have never seen a single airdrop do this.
Most wallet apps (including IOG’s own Lace) chose to provide an unused address of the same account/wallet. In that case, there is absolutely no privacy benefit. The addresses of the same account, of the same stake can easily be correlated by anyone who is able to use a blockchain explorer.
But even if you use the address of a completely new account or wallet (and even if that would have been enforced by the claim portal), it is still very hard to reliably keep that new account unrelated and private. You cannot fund it from an existing account. You cannot move the claimed tokens to an existing account. If you fund it through a CEX, that CEX has the knowledge that it’s you. So, you better find the most shady CEX without any KYC process.
This would have been so much easier if the default way for 90% of the users would have been to just not enforce this and allow any destination address, but only optionally allow for users who really want that to give a destination address of their choice … and then provide extensive coverage on all the details how to really keep that new account private.
The execution of this thing was also very much suboptimal. They used the getUnusedAddresses() method of CIP-30 while they could have known that some single-address wallet apps have chosen for years to just return the single (used) address with that method. Eternl had implemented and offered them an experimental method to circumvent this problem:
They ignored this and used
getUnusedAddresses() anyway without any communication before the launch forcing Eternl (and perhaps other wallet apps) to hastily change their CIP-30 implementations.
If you do something like this, communicate with the relevant actors in the space!
Cardano Hardware Wallets
At the start of the claim period, claims with Trezor were completely impossible and with Ledger only possible with some wallet apps. It is beyond me why that was not tested at all. Supporting the relevant hardware wallets should be a requirement from the very start of such a project and not an “Oopsie!” you only realise after launch!
(At the very least, they – including Hoskinson – could have remembered the “hardware wallets not supported” debacle with the CIP-1694 temperature check in December 2023. By the way, the promised second temperature check with hardware wallets never happened.)
The problem with Ledger was that the signature was done not on the message itself, but on a hash of the payload.
This possibility has been in CIP-8 for five years to accommodate limited hardware capabilities and was never debated: https://cips.cardano.org/cip/CIP-0008#payload-encoding
The Midnight team claims that this is a phishing risk because the hashed header is not itself signed so that a malicious dApp could present the hash of a bogus claim as unhashed payload, get a signature from the user, and then use that to steal the claim.
That is not completely untrue, but it requires the user to happily sign a random string of hexadecimal numbers on that malicious dApp. I’d very much think that users who do that would in many, many cases also be vulnerable to just signing an unhashed bogus claim. It’s not that that would be much more clear to technically unsavvy users.
In any case, the proper way would – again – have been to openly communicate that way before the launch and not act as if everybody should have known and the wallet apps and Ledger are to blame and now rightfully should better hurry up to fix their problem. If you deviate from the established standard, it is your responsibility to nicely ask. (I still don’t see a pull request repairing CIP-8 here https://github.com/cardano-foundation/CIPs/pulls?q=is%3Apr+CIP-8 or here https://github.com/cardano-foundation/CIPs/pulls?q=is%3Apr+CIP-0008.)
Luckily, the claim messages were still short enough that most if not all Ledger devices could do a signature without hashing and the wallet apps “just” had to disable that which was done rather swiftly.
(By the way, this representation of the whole matter
https://x.com/IOHK_Charles/status/1952738980249964653
was peak tone-deaf: There was no “issue” with Ledger’s implementation. You decided for debatable reasons to not use an established standard. And expecting Ledger to jump through hoops in a few weeks because the new project of a medium-relevant crypto company asks them to is unbelievably entitled.)
For Trezor, it was worse. It was very much well-known that they had never implemented message signing. So, Midnight had to either provide one of the well-known alternatives – the infamous “null transaction signing” – or push Trezor to finally merge the implementation that they had ignored for years. However, Midnight again acted very surprised that this problem even existed and only started both after the launch of the claim phase. You could have known months before that! Everyone who knows half a thing about Cardano would have known!
Well, Midnight did implement “null transaction signing” and activated it beginning of September: https://www.midnight.gd/news/night-claim-portal-technical-updates
Unfortunately, they did a very strange version of it. The idea is that the message you want to have signed is in the metadata of a “fake” transaction that will never be submitted to the chain, that ideally cannot successfully be submitted and won’t move any of the users assets. What they did was leaving inputs and outputs of the transaction completely empty. This led to some wallet apps trying to give the user a preview of what they are about to sign to reject these null transactions completely.
No previous project doing this work-around has done it that way. (I have shown my idea of how to do it a year ago at https://forum.cardano.org/t/the-most-trivial-aiken-validators/133285#using-a-burnt-utxo-for-login-7 using inputs that are locked in an “always fail” script.)
Eternl had to hotfix again to allow this version of null transactions. As far as I know, Lace was not able to handle them until the end of the claim phase.
If you are doing a project like this, test all steps with all relevant wallet apps with and without hardware wallets! And do that early!
On the plus side, Trezor now has finally merged the message signing implementation: https://trezor.io/support/troubleshooting/coins-tokens/how-do-i-claim-night-tokens-on-trezor
The NIGHT Token Mint
Not directly related to the claim, but Midnight was very proud that they now have minted the NIGHT token: https://www.midnight.gd/news/night-token-supply-minted-on-cardano-mainnet
Just out of curiosity, I tried to find it. So, they said that they submitted its metadata to the Cardano Token Registry:
Should be easy enough to find: https://github.com/cardano-foundation/cardano-token-registry/pulls?q=is%3Apr
Ah, there it is (the only PR related to something called “NIGHT”): https://github.com/cardano-foundation/cardano-token-registry/pull/7714/files
But that token – policy ID 0691b2fecca1ac4f53cb6dfb00b7013e561d1f34403b957cbb5af1fa and asset name 4e49474854 (“NIGHT”) – does not exist: https://adastat.net/policies/0691b2fecca1ac4f53cb6dfb00b7013e561d1f34403b957cbb5af1fa
The only token that does exist is the one with the empty asset name: https://adastat.net/tokens/0691b2fecca1ac4f53cb6dfb00b7013e561d1f34403b957cbb5af1fa
Will be interesting how they are going to fix this.
And I’m flabbergasted that nobody in this organisation had realised that problem between minting on 14th October and submitting the registry PR and publishing that proud news on 20th October.
Conclusion
None of this has anything to do with the technology of the Midnight chain itself. That might be sound. It might even have interesting use cases. (Although I’m very sceptical of that. Privacy is important, but for most of my privacy needs, ZK and blockchain can offer very little benefits. Those are questions of regulations and laws that cannot be replaced by technology.)
But on all things Cardano, this was an unbelievable stream of technical incompetency and horrible communication and I don’t want that to be sugar-coated!
This was only made somehow bearable by the effort of a lot of people not affiliated with Midnight who gave support in the channels ignored by the Midnight team, found work-arounds and fixes for more exotic cases (e.g., How to claim midnight NIGHT tokens for old Byron Daedalus/Yoroi wallet funds - Tutorial, Import BC Vault Wallet to Eternl (for Midnight Glacier Drop claim), Import Exodus (Shelley) Wallet to Eternl (for Midnight Glacier Drop claim) - #27 by HeptaSean, How to claim midnight NIGHT tokens for Cardano EXODUS wallet funds - Tutorial, You can sign anything with Cardano-Signer now - #3 by ATADA, …), implemented work-arounds in all the wallet apps, … without much acknowledgement from the entity responsible for this hot mess.
(We haven’t really touched the other assets of the claim here. This was also a bumpy ride for a lot of users.)
