Justin Drake's March 2023 research-forum post defines a based rollup through the base layer's proposer: the next proposer can permissionlessly include the next rollup block, potentially working with builders and searchers. The proposal argues that this arrangement reuses base-layer liveness and sequencing infrastructure. It also discusses economic tradeoffs, including where sequencing revenue and extractable value flow.

This is an original technical proposal and discussion, not a peer-reviewed empirical paper demonstrating every implementation. Its core contribution is a sequencing architecture. The phrase based does not specify whether state transitions are checked using validity proofs or optimistic disputes. Read the definition first, then identify which claimed benefits depend on the exact relationship between proposer, builder, rollup contract and transaction submission path.

The November 2023 based-preconfirmation proposal addresses the delay before base-layer inclusion. It considers proposers that opt into additional obligations and issue signed promises about execution, with penalties for specified failures. Its construction assumes mechanisms for slashing and forced inclusion. These assumptions are part of the proposal; they should not be silently treated as universal features of every based rollup.

A preconfirmation is therefore different from a finalized base-layer transaction. Read exactly what is promised: inclusion, ordering, execution outcome or some combination. Then identify how a breach is proven, who submits that proof and which funds secure the promise. A fast acknowledgement can improve user experience, but its economic and technical guarantees must be described independently from the settlement rule that ultimately accepts the rollup state.

Imagine a fictional rollup where a user submits a trade before the next base-layer block. A service responds immediately with a signed execution promise. Later, a proposer includes a batch; after that, the rollup's proof or dispute mechanism establishes the accepted state. The interface might display three distinct milestones: promised, included and settled. Combining them into one green checkmark would hide which guarantee has actually been obtained.

Now imagine the promise issuer disappears before inclusion. The research questions are whether another proposer can include the trade, whether ordering changes its outcome, and whether compensation covers the user's actual loss. A penalty is not automatically equivalent to reversing an unwanted trade. This example is deliberately implementation-neutral: it helps a reader extract the necessary facts from a real protocol without assuming that every promise mechanism has the same behavior.

For a concrete system, trace authority rather than relying on its category name. List who may submit a batch, who may prove or dispute it, who publishes its data, and who can upgrade the contracts. If one of those roles remains restricted, describe that restriction directly. Permissionless sequencing alone cannot answer whether a user can reconstruct state, challenge a false claim or exit during an upgrade dispute.

A useful comparison uses the same hypothetical outage across designs: the usual transaction service goes offline for an hour. Work through submission, inclusion, proof production and withdrawal separately. Record delays and dependencies instead of assuming that inheriting one layer's liveness solves every stage. The purpose of reading the proposals is to understand which bottleneck is removed and which responsibilities remain elsewhere in the system.