API overview
A proposed REST contract for private transaction submission and tracking.
The proposed REST API uses signed EVM transactions as input. Your application keeps control of signing, submits a transaction to Mokuna and tracks processing separately from on-chain inclusion.
Base URL & format
BASE URL
https://api.mokuna.xyz/v1Requests and responses use JSON over HTTPS. Send Content-Type: application/json for request bodies and an Authorization: Bearer … header for authenticated requests. Timestamps use UTC in ISO 8601 format.
Endpoint directory
| Method | Path | Purpose |
|---|---|---|
| POST | /v1/transactions | Submit a signed transaction for private processing. |
| GET | /v1/transactions/{id} | Retrieve the processing state and chain outcome. |
Download the OpenAPI 3.1 specification ↓
Request lifecycle
- Sign the transaction within your existing application flow.
- Submit it with a network identifier, bearer token and idempotency key.
- Persist the returned transaction ID and request ID.
- Query status until processing reaches a terminal outcome.
- Verify chain confirmations according to your application’s policy.
A 202 Accepted response means the submission was accepted for processing. It does not promise inclusion or captured MEV revenue.
Conventions
| Field or header | Convention |
|---|---|
| Network identifiers | base, robinhood, arbitrum, optimism, unichain, monad. Access is scoped to the integration. |
| Transaction identifiers | Opaque strings such as mtx_example_001. Treat IDs as case-sensitive. |
| Integers from the chain | Block numbers use decimal strings, avoiding JavaScript integer precision issues. |
| Unknown values | Use null until the outcome is available; do not interpret missing results as failure. |
| Diagnostics | X-Request-ID identifies each API request. Preserve it when reporting errors. |
Build the full path
Begin with authentication, then submit a transaction. Handle errors and limits before adding status polling.
Updated September 20, 2026 · Discuss this guide ↗