Transaction Broadcasting
Broadcast pre-signed transactions directly to the MultiversX P2P network for faster propagation. This bypasses the public API and delivers transactions directly to validators.
Overview
The broadcast action sends fully signed transactions to the network. Use this when you have:
Transactions signed by the user's wallet
Pre-signed transactions from a backend service
Batches of transactions to submit efficiently
Single Transaction
ws.send(JSON.stringify({
action: 'broadcast',
requestId: 'tx-001',
tx: {
nonce: 42,
value: '1000000000000000000',
receiver: 'erd1qqqqqqqqqqqqqpgq...',
sender: 'erd1abc...',
gasPrice: 1000000000,
gasLimit: 50000000,
data: 'c3dhcEV4YWN0QW1vdW50SW4=',
chainID: '1',
version: 2,
signature: 'a1b2c3d4...'
}
}));Batch Transactions
Send multiple transactions in a single message:
Transaction Object
nonce
number
Yes
Sender's transaction counter
value
string
Yes
EGLD value in atomic units
receiver
string
Yes
Receiver's bech32 address
sender
string
Yes
Sender's bech32 address
gasPrice
number
Yes
Gas price in atomic units
gasLimit
number
Yes
Maximum gas units
data
string
No
Transaction data payload (function + args)
chainID
string
Yes
Chain identifier ("1" for mainnet)
version
number
Yes
Transaction version (typically 2)
options
number
No
Transaction options flags
signature
string
Yes
Hex-encoded sender signature
guardian
string
No
Guardian address (guarded accounts)
guardianSignature
string
No
Guardian signature
Response
Success Response
Partial Success (Batch)
Complete Failure
Response Fields
action
string
Always "broadcast"
status
string
completed, partial, or failed
requestId
string
Your provided request ID
hashes
array
Transaction hashes of successful broadcasts
failed
array
Failed transactions with index and reason
Example: Complete Integration
Batch Processing Example
Error Reasons
Common failure reasons:
invalid signature
Signature doesn't match sender
invalid nonce
Nonce already used or too high
insufficient balance
Not enough EGLD for value + fees
invalid receiver
Malformed receiver address
gas limit too low
Gas limit below minimum
invalid chain id
Wrong network (testnet vs mainnet)
Broadcast vs Relay
Signing
Pre-signed by user
Co-signed by relayer
Use case
Standard transactions
Gasless/meta transactions
Speed
Faster (no signing step)
Slightly slower
Requirements
Full signature
Valid transaction structure
Best Practices
Include requestId - Always provide a unique requestId to correlate responses
Handle partial failures - Check both
hashesandfailedarraysValidate before sending - Verify signatures and nonces client-side
Implement retry logic - Retry failed transactions with corrected parameters
Monitor transaction status - Subscribe to
tx-status/{hash}after broadcasting
Related Topics
Transaction Relaying - Co-signed gasless transactions
Account Subscriptions - Monitor transaction confirmations
Gas Statistics - Optimize gas pricing
Troubleshooting - Common transaction errors
Last updated
Was this helpful?