Transaction lifecycle
Track submission, execution and revenue as separate outcomes.
A transaction can be received without being included, and an included transaction does not necessarily generate MEV revenue. Your application should distinguish these outcomes when reporting status to users and reconciling revenue.
Submission and acknowledgment
The partner sends flow through the agreed connection. Confirm whether a successful response means only receipt, successful validation or something further. A timeout leaves the submission outcome uncertain until the agreed reconciliation mechanism resolves it.
Record a correlation identifier if supplied, network, transaction hash where available, submission time and the original response. Keep credentials out of application logs.
Search and simulation
The engine searches and simulates opportunities. Some flow may offer no viable opportunity, and changing chain state can invalidate a previously simulated opportunity. Absence of MEV revenue is not by itself evidence that the user transaction failed.
Execution and confirmation
Reconcile execution with the relevant chain’s receipt and finality rules. A submission response is not an on-chain receipt. Define how many confirmations your product needs and how a reorganization affects the status presented to users.
Mokuna does not currently publish a latency or next-block inclusion guarantee. Discuss network-specific timing requirements before rollout.
Revenue attribution and settlement
Attribute captured MEV revenue to the agreed partner identity and accounting period. A user transaction’s transferred value or gas fee is not the captured MEV revenue used for the partner split.
Confirm the accounting basis, costs and settlement schedule in the revenue sharing guide.
Handling uncertain outcomes
- Timeout: reconcile the original submission before applying a retry policy.
- Pending transaction: check the agreed tracking signal and on-chain outcome before replacing or rerouting it.
- No revenue: separate execution success from the presence of a captured opportunity.
- Public fallback: evaluate how rerouting changes the privacy of the transaction.
The Preview API defines idempotency for submission retries. Replacement and cancellation endpoints are outside the v1 proposal.