Hyper-Optimized DEXs?

[patrick-ogrady]

[patrick-ogrady]

As soon as more primitives are built out, they could definitely be used to instantiate a custom trading application (and expect a number of folks will do so).

Unlike other approaches out there (like HyperSDK/Cosmos-SDK), commonware-* is not a framework. This means it might take you longer to get started (no enshrined block/tx/state format) but yes, it would definitely let you build a wicked onchain trading engine.

[HariSeldon23]

What are the current thoughts about block building? Will there be a ruleset in place for nodes to reorder or censor based upon tip/MEV opportunities/others? What is the current thinking around priority fee's and gas calculations? Purely based on compute or will there be an ability to have a storage component make up the fee?

[patrick-ogrady]

What are the current thoughts about block building? Will there be a ruleset in place for nodes to reorder or censor based upon tip/MEV opportunities/others?

As designed, consensus::simplex defers rules around leadering (who is a builder and when) + ordering to the application. All it cares about is that everyone agrees on some hash representing some data at the same time.

We've considered using threshold signatures to introduce a bias-resistant VRF for use in post-inclusion ordering but you could alternatively introduce your own ordering based on some other focus.

What is the current thinking around priority fee's and gas calculations? Purely based on compute or will there be an ability to have a storage component make up the fee?

There is no notion of transactions nor fees in consensus::simplex. These would be up to the application.

We are working on more complex examples at the moment that provide examples of "one way" you could incorporate ordering/fees in a production deployment (but that would just be a guide not a rule).

[HariSeldon23]

This is really helpful, thank you.