Tao Zhu

Hi @SpaceMonkeyForever, thanks for contributing! > You can see my TXs on openbook for example, the priority fee is 50k-200k usually. Can you provide a few examples of your txs?...

if `compute_unit_price` is set to 50K - 200K microlamports, then increase its unit to 1 lamport is a x20 - x5 increase on `compute-unit-price` alone; at same time, if `compute_unit_limit`...

> +1 to exposing CU consumption if we want users to request tighter CU limits Agreed. Simulations or careful design help on some use cases, but may not be enough...

> Also, it seems your overall goal is to increase the fees, The overall goal is to continuously improve network so it serves better for _everyone_. To that end, the...

> Can you elaborate on why higher CU limits is problematic? Will make it easier to brainstorm suggestions! - requesting more CU than actually needed wastes block space (block has...

> I imagine you'd end up getting less fees overall. In general sense, leaders do extra work for TXs with priority, prioritization fee compensates that extra work. Less prioritization, less...

> are block CU limits based on CU used or CU requested? i was under the impression it's the former, but could be wrong. Currently there is a QoS adjustment...

Without understanding what takes to trade successfully, and with full respect, I'm wondering if possible such transaction be broken up into smaller TXs, coordinated by signals generated off-chain? Akin to...

Right, this is model is common that creates large variance in requesting CU limits. Would be great if the decision could be made off-chain, so you have one small and...

Note: this feature gate should be scheduled/activated *after* https://github.com/solana-labs/solana/issues/34982