Thanks for jumping in, and Hi!
I’d just like to be upfront and say that I don’t intend for anything from Phase 1 other than the RNG to be deployed and used on mainnet, it’s research focused on overcoming the problems that make phase 2 possible at which point the Dark DEX can be specified and we can come back to you with a high-value seed phase proposition (or just approach VCs who seem to be creaming themselves over ZK tech at the moment).
Is it a DEX or an AMM? More details on how it would work. My gut feeling is that it’s much more complicated than currently reasoned about.
It’s not possible for this to be an on-chain AMM as it cannot rely on a price / UTXO oracle (like Shinobi protocol) or overly complex game theoretic / economic mechanics without contravening my requirements.
I have a very good intuition for the complexity involved, and I believe that mostly non-interactive cross-asset fungibility without oracles or trusted third parties while retaining strong anonymity guarantees is solvable, and I have intricate knowledge of this from my experience working with, analysing the defecits and developing various privacy enhancing coins / technologies, zkSNARKs, mixing algorithms etc.
Let me be frank though, I do not want to be responsible for a MVP which makes convenient but bad compromises to get to market faster, or something that gives users a false sense of security just because it’s deployed on Secret Network, as if it accidentally gains traction we’ll be stuck with it and it will suck.
For example, monetizing this directly from user transactions is non-trivial without breaking anonymity (like scrt’s native gas token does for those who aren’t exceptionally careful). And I agree that simply encapsulating wallets as NFTs with an escrow method is not the end goal, it’s a known stepping stone - to overcome the problems making it unsuitable for use with a “Dark DEX”. Personally I think the current Cosmos/Secret token standards just perpetuate the problems that we’re now stuck with on Ethereum which make composability and gasless meta-transactions an absolute nightmare (and these patterns are blindly followed by most other smart-contract chains), and having an AMM like SecretSwap is an ‘easy’ solution that leaks de-anonymizing data on every transaction even without gas payer linkage… those are bad convenient compromises.
We need something better, and I don’t think you can do that if the scope is too narrow or is artificially limited by incrementalism.
First, let me try to explain the Phase 1 solution in my own words to make sure I get it. IIUC, the idea would be for users to be able to generate a BTC/ETH/other wallet for themselves on Secret Network (there will be a UI that will generate a keypair associated with the user sending that tx … etc
That’s one way of doing it and similar to my starting point. But the wallets need to be freely tradable on scrt.network without any further native ETH transactions, ideally they need to be fungible (that’s really difficult without making the SPV client compromise that Shinobi has made, and now they’re stuck with high gas fees and only support BTC), without revealing the wallet address until the final withdrawal, with an ever growing anonymity set size and no cross-chain linkability or correlation, without side-channel de-anonymization, without relying on expensive oracles or continuously running external processes which are prone to breaking down etc.
TL;DR I’m limited by difficult constraints where the answers will define what I can and cannot do when it comes to a DEX that doesn’t suck and is actually anonymous. I can’t commit to a half-arsed but easy solution because there are still some hard problems to solve - and importantly they’re worth solving properly without compromises. Secret network makes this possible with much less effort and fewer compromises.
When it comes to generalizing this, the idea would be that people would be able to ‘trade’ eth/btc/whatever address on Secret, creating a new kind of DEX/AMM in phase 2
Yes.
At the moment I’m continuing to problem-solve and we’re in the process of refining the proposal. Query nodes + the extra builtins coming up in Shockwave let us do some very interesting ‘transactionless’ things using derivation schemes, but without those building blocks it will be much less valuable if implemented.
Ethereum specific:
Given an Ethereum block hash (any time after the deposit) the depositor can privately use the state trie to prove to the contract that the wallet has at least a certain ETH balance. The proved block hash and declared value is included in the public metadata so anybody can verify that if the block hash is real then the proof of funds must be legitimate.
This doesn’t reveal the wallet address until the NFT owner chooses to void the token and gain access to the secret, only then do they learn the wallet address. The NFT can change hands on scrt.network any number of times while keeping the wallet address secret.
The same method can be used for ERC-20 tokens (or even EIP-721 tokens), but is slightly more complex as the storage slot used to track owner/balance varies from contract to contract (it can still be generalized, but requires access to an Ethereum archive node and per-token logic in the client).
BTC / others:
Because Bitcoin has no global state tree a proof of funds would reveal the specific block that contains the deposit transaction (bad). By verifiably/trustlessly constructing an off-chain merkle tree of all BTC blocks a proof similar to the Ethereum case can be made without revealing which block the UTXO exists in - thus keeping the wallet address secret and increasing the anonymity set size.
… I’m not sure if I need to use this method as there are other methods with different trade-offs when considered as a whole. But it’s in my toolbox.
The cost seems arbitrary – on the higher end for what Phase 1 describes, and on the lower end for Phase 2.
It is enough to cover some of the expenses involved in solving the problems necessary to get to the point where phase 2 is both theoretically and practically possible, and more importantly can be specified in a way which won’t drastically change.
Then factor in drafting the phase 2 proposal, legal oversight + jurisdictional advice (I’d rather not get dragged infront of the FCA, NCA, or the SEC), and finding more staff of the calibre I need is both tedious and expensive.
(Also, if you can recommend legal counsel familiar with this kind of project I would appreciate it).
On a side note: I do not trust the DDT5/scrt-rng project - it should not be used by any projects. I have uploaded a stripped down version which doesn’t allow the ‘owner’ to permanently break dependant contracts by changing the settings. Likewise I do not trust the blackbox.cash project as it offers no protection against a malicious relayer (which is a shame because it’s a good idea, but again should not be used by anybody) - it can also be permanently broken by the ‘owner’.