Processing

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.

常见问题

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.

继续阅读

充值、拿密钥、上线。

自助开通。支持加密货币或银行卡。按额度计费——重型原语更贵,简单调用很便宜。

获取 API 密钥