RP1’s execution path is designed for parallel, observable application work without weakening transaction ownership or deterministic results.
Admission
The lane-aware mempool classifies transactions by type and priority, keeps duplicate indexes synchronized, and preserves accepted work through bounded backpressure. Encrypted and commit-reveal paths exist as experimental, deployment-dependent capabilities; they must not be treated as production cryptographic privacy or enabled for value-bearing workloads without a separately reviewed cryptographic deployment.
The public consequences are:
- an accepted transaction can remain pending while workers drain;
- broadcast acknowledgement is not committed finality;
- transaction ordering is a consensus result, not a client-side sort;
- gas and fee constraints are checked before execution and preserved in the receipt.
Parallel execution
The application builds a dependency graph from transaction access patterns. Independent transactions can execute in parallel groups; conflicting transactions retain a deterministic order. Module keepers remain responsible for their state invariants, so parallelism is an execution strategy rather than a license to bypass accounting.
MEV-aware execution
RP1 combines transaction lanes, frequent batch auctions, slippage bounds, reference-price checks, and circuit breakers in the production-facing execution model. Encrypted mempool support and commit-reveal remain experimental, deployment-dependent paths and are not a guaranteed MEV shield. Each control protects a different failure mode:
| Control | Protects against |
|---|---|
| Encrypted or hidden transaction content | Early information leakage in the mempool. |
| Commit-reveal | Revealing order details only after a commitment exists. |
| Batch auctions | Excessive advantage from intra-batch ordering. |
| Minimum output and price bounds | Unacceptable execution price. |
| Circuit breakers | Repeated execution failures or abnormal conditions. |
Performance language
The chain repository maintains live benchmark and validator-resource gates. Public docs should report a dated, reproducible run with workload shape, query cadence, validator set, fee, and evidence validity when making a performance claim. Do not use fixture simulations or a single closed-loop run as a universal TPS, finality, or memory guarantee.
Integration implication
Design clients around lifecycle evidence, not timing assumptions. Keep the signed envelope, query by identity, require a positive committed height, and surface unresolved observation separately from execution failure.