## re: mangata finance

Jimmy's notes:
* Tried out the testnet app (bridging and swaps/LP), local testnet and sdk, pretty solid (esp leveraging substrate and snowbridge, the repos are straight forward)!
* an explorer and some docs (and additional methods) for the sdk methods would be great!
* a genesis.json equivalent (to setup local testnet and some accounts/tokens) would be great for testing, modelling both probabilistic extraction and the markets when order is randomized (wrt arbitrage)
* also to model what collusion infra would look like^
* On fee market:
* Noticed you explicitly mention there's no fee market (fixed fees), would love to have you expand more on the tradeoffs and why you chose that design.
* I'm open to being convinced otherwise but seems like it'd be a problem down the line (think spam from diff accounts to increase edge in probabilistic arb extraction? inadequate fees/incentives that might lead to validators colluding for more profit?)
* On collusion:
* You mention "Collusion should either introduce a direct punishment for the colluding parties or be detectable by any user. The exact solution will be introduced in a future protocol version."
* Very curious to hear what solutions/prototypes you've in mind for this and I see the long term incentives trending towards collusion otherwise.
* You could argue a DEX specific chain is better than the status quo for its atomic vs probabilistic sandwiching but assuming there's enough at stake wrt arbitrage, I worry this will end in block producers colluding
* Even if there's a governance backstop or a oracle to slash, I wonder what prevents that ending in collusion too
* On block creator vs executor:
* Seems directionally where we're headed with Ethereum too (block builder proposer separation in eth2), makes sense in this case too!

Cupid Notes:

* “Optimized for DEX-specific blockchains” - how?
* “Unconventional MEV” - inclusive of arbs and liqs and other things protocols need to function?
* No good/bad MEV - they don’t consider arbitrage “good” MEV b/c users can’t claim it (explicitly calls out flashbots as solving this)
* What about marketplace efficiency concerns?
* Additional nuance here w.r.t. protocol captured MEV IMO
* VER: Value Extraction by Reordering
* In execution order is shuffled using info that doesn’t exist at building time (Proof of History Solana style?)
* Builder provides seed for shuffling (is this an attack vector?)
* Block executor signs seed w/ their private key, shuffles
* Priv key so unknown to block builder (unless they coordinate?)
* Each executor also builds the next block, etc etc
* “Seed chain” for shuffling
* Argues that probabilistic value extraction (e.g. spamming the network) is more fair
* “Participates are disincentivized to attempt to extract any gains with multiple transactions” - how?
* Details: https://github.com/mangata-finance/mangata-node/blob/develop/Mangata.md
* VED: Value Extraction by Denial
* “Doesn’t know what to deny, because no info about transaction purpose”
* Encryption is voluntary (& costly)
* All encrypted transactions are required to have fixed gas costs
* This seems awful for DDOS attacks
* “Users transaction index within the block taken into account for shuffling, only one transaction from a single account will have a chance to be placed before the user’s transaction”
* They can just use multiple accounts tho?
* “Subject to exchange commission” too - even for failed transactions (will this be an awful user experience?)
* “In the case of non-exchange transactions, we believe that having a higher chance of getting the profit by sending more transactions is fair since every participant has equal opportunities”
* This is horrible for spam and user experience IMO
* “Pricing even failed transactions reduces spam”
* Not convinced there is a good balance between user-friendly fees and the amount of spam transactions on this network - will have to see

Conclusions:

* What about marketplace efficiency? Intentionally making your prices less efficient seems like bad UX
* What about network spam balance vs. UX? Still will have some issues and/or very high user costs
* What about builder executor collusion? Especially prevention mechanisms