Submission & Versioning

POST /v1/submit-tx

Submit a transaction directly to consensus.

Request:

Method: POST
Body: raw BCS-encoded Transaction (same format as /v1/incoming’s frames). Content-Type is ignored.
Maximum body size: 256 KiB.

Response:

Status	Body	Meaning
200	`ok`	Handed to consensus. Acceptance is pending and not guaranteed.
400	`invalid BCS transaction`	The body did not decode as a BCS Transaction
500	`transaction rejected`	Consensus refused the transaction
503	`consensus not ready`	Validator booting; retry later

A 200 response means the validator forwarded the transaction to its consensus adapter — it does not guarantee the transaction will be included in a committed block. Confirm via /v1/pending (for ordering) or /v1/executed (for execution).

Versioning policy

The /v1/* family is the supported, stable contract for external clients.
Future additive changes (new optional fields on serializable structs, new enum variants for system-only kinds) may land within /v1/* provided they preserve backward-compatible BCS deserialization for existing fields.
Breaking changes will be published under a new /v2/* prefix; /v1/* will continue to be served alongside for a documented transition window.
Each /v1/* route maintains its own independent subscriber pool.

What's next?

Syncro Data Hyperliquid Stream