Name: thedude
Wallet Address: 0x9ffAab6c24d4fb58d61b26B08c8795E9E323F28B
# LUCID feedback: two arguments the thread hasn’t made yet — backrun adjacency vs. pricing, and the gas-limit anonymity leak
Cross-posting to the Shutter Forum since the Ethereum Magicians thread is locked. This builds on the submissions already there — ashaqeela, doodlemax, and 0xwans in particular have covered a lot of ground well — so rather than re-derive the points they’ve made, I want to lead with two arguments I haven’t seen anyone raise yet, then engage the strongest existing points (FRAME/`signature_id`, provider bonds) where I think I can add a little rather than repeat.
The two new ones both concern LUCID specifically, and both fall out of one under-examined fact: in LUCID the `ToB_fee` and the `gas_limit` are the two values that are *fixed and legible before the payload is revealed*. Each of those has a consequence nobody’s costed.
## 1. Backrun capture: you get adjacency XOR competitive pricing, not both
0xwans’s execution-quality section maps the ordering regimes well and notes that the ToB auction is value- not fee-maximising (`FBV_a > V_e`). But that’s about *who wins a ToB slot*. And ashaqeela asked the drafts to explicitly bless benign backrunning and add an advisory “backrun-share allowed” hint. I want to go a layer under both, to the mechanism: **can a user actually capture the backrun value of their own trade?** dataalways argued on the LUCID thread that N+1 execution shifts that value to validators, making trading more expensive. Julian answered “use a trustless onchain OFA”; aelowsson answered “seal your trade and backrun as a bundle with sequential ToB fees.” Those two answers don’t compose, and I think that’s the crux beneath ashaqeela’s ask — a blessing doesn’t help if the mechanism can’t route the value to the user.
`ToB` order is fixed by the `max_tob_fee` carried in the *plaintext* ST ticket, so a transaction’s position is allocated at commit time (slot N) — before the payload is revealed, and therefore before anyone knows what backrun the trade will create. Competitive pricing of that backrun only becomes possible after reveal (N+1). That timing gap forces a choice:
- **Committed bundle (aelowsson’s path).** Bundle the trade and backrun under one `key_publisher` with adjacent `max_tob_fee`s. Because a bundle executes as an atomic unit, nothing can wedge between the two legs, so adjacency is guaranteed — *but* whoever assembles the bundle must already know the backrun at commit time, i.e. be their own searcher. There is no price discovery on the backrun. (And absent atomic bundling, adjacency is weaker still: `max_tob_fee`s are public integers, so a third party can tie the backrun’s fee and win the tiebreak into the gap — which is exactly why aelowsson notes the coupling “could be strengthened by enforcing atomicity.”)
- **Post-reveal onchain OFA (Julian’s path).** A competitive router discovers the best backrun *after* the trade is revealed — that’s where price discovery and the user refund come from. But by reveal, the ToB positions have already been allocated by the commit-time tickets in slot N. The OFA’s backrun therefore either had to be committed earlier as its own ticket (blind to the revealed trade — no better than path A) or executes as an ordinary later transaction, **losing adjacency** and eating any state change between the trade and the backrun.
So LUCID as specified offers *trustless adjacency without price discovery* or *price discovery without trustless adjacency* — never both in the same ToB segment. dataalways’s “value leaks to validators” critique is only answered if a user can capture a **competitively priced** backrun that is **guaranteed adjacent**, and neither path delivers that.
aelowsson already gestured at the fix (“coupling guarantees could be strengthened by enforcing atomicity across sequential ToB fees from the same decryptor”). I’d make it a concrete primitive — a **reserved adjacent slot**:
- An ST may seal a flag declaring “the ToB position immediately after me is auctionable; the winner is force-placed adjacent; proceeds split to a sender-named beneficiary.”
- The reserved slot is filled by a small post-reveal auction whose outcome the builder must honour, executed before the next `max_tob_fee` rank.
That restores price discovery (the auction is post-reveal and competitive) without breaking adjacency (the protocol pins the winner immediately after the trade) and routes the value to the user rather than the validator. The part that needs careful design is that it introduces a *post-reveal placement* step, which interacts with the “order fixed at slot N” property — that interaction is the real work, and I think it’s the single highest-value extension to the MVP, because without it “just use a trustless onchain OFA” has no way to land adjacent and the backrun value does leak to validators exactly as dataalways said.
## 2. The plaintext `gas_limit` is a pre-reveal anonymity fingerprint — and the refund concession is quietly a privacy lever
This one I haven’t seen raised at all, and I think it’s the more important of the two.
The ST ticket has to carry `gas_limit` in plaintext: the FOCIL IL gas accounting and the pay-for-the-envelope charge both need it before execution. So `gas_limit` is public at slot N, *before* the payload is revealed — and gas limit is a strong fingerprint of transaction class. A plain transfer (21k), an ERC-20 transfer (~50–65k), a Uniswap v3 swap (~120–200k), and a multi-hop route (500k+) sit in distinguishable bands. An observer watching the committed STs in a slot can bucket them by declared limit and shrink the effective anonymity set *before any key is released*. The exact calldata stays sealed, but the *class* of transaction leaks — which partially undercuts the “hidden until execution” guarantee for precisely the flow (DEX trades) LUCID most wants to protect.
Here’s the part that connects to the live fee debate. dataalways and jflo pushed on the strict full-gas-limit charge; aelowsson conceded that unused base fee and ToB fee should be refunded on success, keeping only the priority fee strict. That concession is usually read as a fee-fairness fix. It’s also a **privacy lever**: under the strict charge, padding your limit to a uniform value is pure cost, so every rational user sets a *tight* limit — which maximises the fingerprint and minimises the anonymity set. Once unused base + ToB fee is refunded, padding to a standard limit becomes nearly free on the success path, so uniform padding becomes affordable.
The constructive ask is to finish that thought and make it deliberate: recommend (or lightly enshrine) a small set of **standardised `gas_limit` buckets**, so STs round up to the nearest bucket and cluster into a few large anonymity sets instead of each leaking an idiosyncratic value. The residual friction is that padding is still burned on withholding, so bucket sizing and the withholding rate jointly decide whether users actually pad — which is one more reason (see §3) to keep withholding genuinely rare rather than merely priced. This turns a fee-policy detail into anonymity-set design, and it’s nearly free.
## 3. On provider accountability — agreeing with 0xwans and ashaqeela, and one reason a flat bond isn’t enough
0xwans proposes a `minimum_sponsor_collateral` (~0.1 ETH) slashed on equivocation, and ashaqeela proposes an opt-in bonded provider class with rolling-window penalties on attested miss-rates; doodlemax and Roni-Travis both framed the same behaviour from the liveness side (the free-option / reveal-failure DoS, and the need for a timeout/fallback path). I agree with the accountability direction, and I think the underlying incidence point 0xwans made — that the sponsor-ST penalises the *user* who picked the bad publisher, not the publisher — is the right diagnosis. On a withheld key the user’s prepaid ETH is burned while a third-party decryptor forfeits only fee revenue it never collected and posts nothing; that asymmetry is the core problem.
The one thing I’d add: a **flat** bond floor is necessary but not sufficient, and it’s worth saying why so the number doesn’t get treated as solved. Withholding is deterred only when the withholder’s cost exceeds the benefit of toggling the transaction:
```
bond + ToB_fee + decryptor_fee > toggle_value + bribe
```
`ToB_fee` and `decryptor_fee` are user-set and small (they’re pure cost to the sender), so for cheap transactions the deterrent collapses to roughly the bond. And `toggle_value` is not bounded: ashaqeela’s own liquidation-threshold example is exactly the case where nudging state across a discontinuity is worth far more than 0.1 ETH. Since `toggle_value` is unknowable at bond-posting time, no fixed floor can be sized against it. So bonds have to be **paired with tight expressivity bounds** — LUCID’s `max_preceding_commitments`, ashaqeela’s user-facing trust cap, or the trust-graded `max_preceding_untrusted_commitments` 0xwans sketches — so that the *branching optionality* a withholder can express is bounded even when their stake can’t cover the worst toggle. Bonds raise the floor; expressivity bounds cap the ceiling; you need both. I’d frame the two proposals as complementary rather than alternatives for exactly this reason.
## 4. On FRAME — concurring, with one line to add
0xwans made the FRAME/`signature_id` case in detail — with side-by-side pseudocode showing 8105 hardcodes ECDSA in its RLP layout while LUCID’s `signature_id` byte lets a future `FRAME_TX_TYPE` slot in without a re-encode — and ashaqeela also pointed at FRAME convergence over time. I fully agree and won’t re-derive it. The only thing I’d add is a note on sequencing and the merge: jannikluhn’s FAQ argues the encrypted mempool shouldn’t be *gated* on EIP-8141, and I think that’s correct — this is a forward-compatibility requirement, not a dependency. The concrete watch-item, now that the 8105 and LUCID teams are converging, is simply that **the merged design keep LUCID’s `signature_id` discriminator and not inherit 8105’s hardcoded-ECDSA envelope.** That’s the cheap, high-leverage outcome 0xwans is pointing at, framed as a merge constraint rather than a new dependency.
## Smaller notes
- **Execution context.** The spec should state plainly which block’s context decrypted transactions execute against. LUCID pins execution to the *commitment* block’s header (so `SLOTNUM` returns the commitment slot) to deny the next builder post-reveal injection — a defensible choice, but it means price-sensitive trades execute against up-to-a-slot-stale state, which feeds dataalways’s execution-quality objection and interacts with §1 (a competitively-priced adjacent backrun would partly offset the stale-fill cost).
- **2935 / 4788 deferral.** Deferring the parent-hash and beacon-root registry writes until after the last decrypted ST executes is necessary for the commitment-context model, but a decrypted transaction reading `BLOCKHASH(parent)` or the beacon root then sees pre-update state. Worth surfacing for app developers rather than leaving implicit.
## Net
The thread has already converged on the big two — provider accountability (bonds) and FRAME/`signature_id` — and I think those are basically right; my only addition there is that bonds need expressivity bounds alongside them, for the toggle-value reason in §3. The two arguments I’d most like the authors to engage are the new ones: the **backrun adjacency-vs-pricing impossibility** in §1, which I think is the real substance behind “value leaks to validators” and which the reserved-adjacent-slot primitive is meant to resolve, and the **pre-reveal `gas_limit` fingerprint** in §2, which is an anonymity leak hiding in a field everyone treats as mundane, and which the refund concession can be turned into a fix for almost for free.
Happy to take the reserved-adjacent-slot primitive and the gas-bucket scheme from sketch to something a client team could read — those are the two I think are worth the detailed spec work.
