How it works

The engine keeps the submission path regional and Redis-backed. PostgreSQL receives durable projections asynchronously and is not required to answer an orderflow submission.

Flow overview

1. An originator submits a signed raw transaction or bundle.

2. The engine validates its envelope and chain ID, admits it atomically, and forwards it to every configured builder.

3. Authorized searchers receive the decoded transactions without raw bytes or signatures.

4. A searcher references the last transaction hash in the originator orderflow and appends its own signed transactions.

5. The engine forwards the bundle and transaction.

6. Tracking and refunds endpoints reflect the status of transaction, bundle and refund.

Privacy boundary

Searchers see decoded transaction fields—including calldata—but not signed raw transaction bodies or signature fields. Configured builders receive the signed payloads needed for execution. Do not submit secrets in transaction calldata.

Lifecycle

Status	Meaning
PENDING	Accepted; no terminal builder result is available.
FORWARDED	At least one builder accepted the submission.
REJECTED	Processing failed or all applicable builder submissions failed.
CANCELLED	A searcher replacement group was cancelled.
UNKNOWN	No matching hash is visible to the tracking service.

Only PENDING is non-terminal. UNKNOWN can be temporary immediately after submission because tracking projections are asynchronous.