Broadcast a Raw Signed Transaction
Once you have signed a transaction where you keep keys, you need it on-chain. This guide broadcasts the raw signed payload and returns the hash to track. Simulate first so you never spend fees broadcasting a transaction that reverts.
- A signed transaction produced where you control keys.
- An API key with C2 access for simulate and broadcast.
1Simulate the signed payload
Simulate before broadcast to confirm success and read any revert reason. This is the last checkpoint before fees are spent.
curl -X POST https://api.1st-node.com/v1/tx/eth/simulate \
-H "Authorization: Bearer sk_live_..." \
-d '{"raw":"0x02f8..."}'
> {"success":true,"revert_reason":null}2Broadcast the transaction
POST the signed bytes to /v1/tx/{chain}/broadcast. The response returns the transaction hash.
curl -X POST https://api.1st-node.com/v1/tx/eth/broadcast \
-H "Authorization: Bearer sk_live_..." \
-d '{"signed":"0x02f8..."}'
> {"hash":"0x9c1f..."}3Track the hash to inclusion
Poll the returned hash or wait on your webhook until it reaches your confirmation threshold, then mark the operation settled.
Frequently asked
Where is the transaction signed?
Wherever you keep keys — broadcast is non-custodial and only accepts already-signed bytes. Custodial signing is a separate opt-in primitive.
Why simulate right before broadcast?
State can shift between signing and sending. A final simulation catches a new revert or fee shortfall before you spend fees on a doomed broadcast.
Keep reading
Top up, get a key, ship.
Self-serve. Pay in crypto or card. Metered by credits — heavy primitives cost more, simple ones are cheap.
Get API key