Deviation

MULTI/DEX is a decentralized exchange (DEX) platform designed for the Internet Computer (ICP) blockchain. Unlike many other DeFi platforms that rely on traditional web servers for their front-end interfaces, MULTI/DEX operates entirely on-chain, with its entire stack—including the matching engine, order books, and front-end—running as canister code on the Internet Computer network. Key Features of MULTI/DEX Fully On-Chain: Because the front-end is hosted directly on the blockchain, it is decentralized and censorship-resistant. This contrasts with many Ethereum-based DEXs, where the smart contracts are on-chain but the interface is often served via centralized web servers. AI-Powered Interface: The platform integrates AI, allowing users to interact with the exchange using natural language. This includes receiving assistance with trading strategies, portfolio management, and the automation of approved actions. Non-Custodial: Users maintain full control over their assets while using the platform. Cross-Chain Capability: It is built to support cross-chain asset swaps, leveraging the Internet Computer’s native ability to interact with other blockchains (like Bitcoin and Ethereum) without the need for traditional "bridges" that are often security vulnerabilities. Performance: By running directly on the Internet Computer, it aims to achieve high transaction speeds and low latency, targeting a performance level comparable to centralized exchanges while maintaining the transparency and security of a decentralized protocol internet-computer:native #internetcomputer #ICP

Since @dfinity has decided to build in public - commendable - and since the DEX is in play mode, I will post here about issues I find, since they form excellent and rare examples-in-the-wild but with no money on the line, perfect discussion material for those who are interested in software security. There are many categories of security bug. From really deep ones, where something is wrong in some cryptographic primitive we rely on (catastrophe, loads of apps go down) to some bug in app code that only impacts that app. There are far more of the latter, plus it’s the kind you might be involved in both causing and fixing, so it’s the kind to pay attention to. The bug in the quoted post is not a security bug, it’s just a broken method that will fail to present a report. So far I haven’t found any security bugs in the app code…but to be fair, at this time the source code has not been published (github link is dead) so all I have been able to do so far is inspect the API of their backend canister to see what pops up. That’s how I found the bug below, but also how I found something potentially more nefarious. Don’t worry, your fake funds are safu! And furthermore, one might disagree on if what I found is a security issue at all. It’s even possible that once the source code is published it turns out I was completely wrong, because my analysis is based entirely on guessing what a method might do from its name. The method name is setAnthropicApiKey(text) As mentioned there are many categories of security bug, and one evergreen category is “placing a secret where you think it’s safe but it isn’t”. The question before us is whether putting your Anthropic API key in a canister is safe. As it happens, this very topic has been the subject of heated debate between me and ChatGPT (and Claude, who agrees with ChatGPT) for many months. I have posted about it before. I have done my utmost to steelman the resistance but in the end I have been forced on grounds of reason and logic to yield to the very stern AIs. The verdict is clear: You should NOT put your important/valuable secrets in a canister! This is an important subject, and while I do agree with my very uncompromising (on this issue) AIs, rather than decree what “thou shallst nawt dothe” I prefer to explain the situation and let you draw your own conclusions. I see this as an opportunity to clarify an important architectural concern when building on ICP that you should definitely take the time to understand even as a vibe coder. Here’s the basic deal: You’ll have heard of Chain Key and Chain Fusion, and you know that when your ICP smart contract calls BTC, the BTC keys are split up among the node operators so nobody ever sees a full key. Beautiful and secure. You also know that for node operators to be able to tamper with your smart contracts several of them need to collude. Again, nice and secure. Then you have also heard that ICP supports private data in smart contracts. It does. But the conclusion you should be careful NOT to jump to, is thinking it would require colluding node providers to see your private data. Each node provider can see your private data. It only takes 1 corrupt node provider in a subnet to steal your secrets, no collusion necessary. If you upload your API keys, or BTC keys to a canister, they will NOT be broken into pieces where every node provider only sees a piece. Thus it is a terrible idea to store data that is sensitive to node providers seeing it in a canister. An Enterprise AI API key could potentially be worth more than a node operator profits in a year. It would be almost impossible to figure out which node op stole it, too. Dfinity is of course well aware of this and has drawn attention to it in documentation and have often discouraged storing important secrets in canisters. They also have roadmap items, delivered and future, to deal with this. But before going further, to show that this is not some unsolvable problem in general (only hard on-chain), what would be the recommended approach instead of storing, say, your Anthropic API key in a canister? Simple: you build a web2 server that has access to your key (stored in a safe vault) and calls Anthropic. Your canister makes a HTTPS outcall to your web2 server with the prompt, the web2 server uses its key to call Claude with your prompt and returns the result. This is what both ChatGPT and Claude recommends every time. Now let’s look at some ICP features that might look promising, if you don’t want the web2 server. VetKeys might seem interesting at first, but are not for this use case. They save data in encrypted form so node operators can’t read it, which is great, but the data will only be decrypted for the users with access - not for the code in your smart contract. Great for sending messages safely, but doesn’t work when your canister code needs to see the secret key to attach it to a call to Anthropic. The next thing that seems relevant is TEE/SEV-SNP subnets. Here we get much stronger protections against node operators seeing your data, so this is definitely a step in the right direction for our use case of storing expensive API keys. Some may even hold that it is enough. Going into what circumstances can cause SEV to break is too deep for this post, but the gist is that your data is no longer plaintext to node operators, and they’d have to work hard to see it. How hard? “Not hard enough!!” chorus ChatGPT and Claude who seem to share a thing for protecting AI API keys religiously. I think the important thing to remember at a high level is that to hack their own node and see your data, again the corrupt node op would not have to collude with other node ops - one evil node op with a zero day is enough. But even if you trust SEV, there’s another wrinkle. If you want to do HTTPS outcalls to Anthropic or OpenAI with your key, the replicas that will make the call for you need to see your key in plaintext. Oops. Back to the web2 server. So, my AIs aren’t pleased with SEV subnets either due to the HTTPS outcall issue - what would please them, other than the web2 server? It turns out the upcoming Internet Intelligence Gateway might fit the bill. If that can split up AI keys with Chain Key so node providers really have to collude to steal them, then my AIs are finally happy. But it still doesn’t mean you can put valuable secrets in canisters. You can’t. If you plan on using them in HTTPS outcalls, not even SEV subnets will help. The IIG would basically be a way to take the web2 proxy server and make it part of the protocol. NB: I only speculate the IIG will even work like this, I am not sure it will. But if it does, then there’s a solution my AIs will like. So, back to the setAnthropicApiKey method. Maybe it does nothing and this post is moot - except it isn’t because a general discussion on why not to store API keys in canisters is well due! But what if that method does store an expensive, enterprise AI API keys? Currently multidex isn’t even on a SEV subnet - any node operator would have been able to steal Dfinity’s high volume AI API keys! And even if they move the DEX to a SEV subnet, as we have seen that doesn’t help when they leak the key via HTTPS outcalls. Only the IIG, if it works as I speculate, could save this approach, otherwise the right solution is to put in a web2 proxy server. And as far as I understand, the IIG is a specialized solution for calling AIs, not a new general purpose vault for secrets. Still, perhaps that’s the plan, to use the IIG, this is after all only the play version of the DEX? Perhaps this is too soon to raise flags? Sure, that might be it. But then we scroll a bit further down the list of method names and stumble upon setGoogleApiKey… Bottom line: the way this DEX is built really does seem to contradict Dfinity’s own recommendations on how to handle secrets, unless the methods do something totally different than the names suggest. @dfinity please do take a look. Especially since this DEX will become a de facto reference for best practices on ICP.