eth_sendRawTransaction is an Ethereum JSON-RPC method used to submit a signed transaction to a node or provider for propagation to the network. The payload already contains the sender’s signature, so the node checks transaction format and nonce rules rather than signing it itself.
What eth_sendRawTransaction does in Ethereum
eth_sendRawTransaction is the point where an externally signed Ethereum transaction enters the network lifecycle. It is a submission method, not a signing method, so the main security concern is whether the node, provider, or application is handling a valid signed payload from a trusted source and preserving its integrity in transit and storage.
Why raw transaction submission is security-sensitive
Because the payload already carries the sender’s signature, any compromise before submission can be enough to redirect value, change execution intent, or exhaust nonce order. The method itself does not create authority, but it exposes an already-authoritative action to whichever system, wallet, relay, or API call is allowed to pass it onward.
That makes this method sensitive to tampering, replay-like misuse, and exposure of signed payloads before broadcast. In practice, the risk is less about the RPC verb itself and more about the trust boundary around transaction construction, signature generation, and transport to the node or provider.
How to think about validation and trust boundaries
An Ethereum node receiving a raw transaction typically checks the transaction structure, signature validity, chain compatibility, gas settings, and nonce sequencing before accepting it for propagation. Those checks are important, but they are not a substitute for protecting the upstream signing workflow and verifying that the submitted payload matches the intended recipient, contract call, and value transfer.
For operators, the critical question is whether the path into eth_sendRawTransaction is restricted, logged, and observable enough to detect abuse. This includes wallet software, backend services, relays, and any automation that can submit signed transactions on behalf of users or treasury systems.
Operational implications for wallets, nodes, and applications
eth_sendRawTransaction is commonly used by wallets, custodial systems, and dApps that build a transaction off-chain and then broadcast it after signing. That architecture is efficient, but it also means the blast radius of a compromised signer, leaked signed payload, or misrouted request can extend directly into on-chain execution.
Good handling depends on clear separation between transaction creation, signing, and broadcast. If those functions blur together, it becomes harder to prove who authorized the action, whether the payload was altered, and whether the node accepted a transaction that was never meant to leave the local trust domain.
Detection and review after submission
After broadcast, teams should compare the submitted raw transaction with the intended action and review the resulting hash, nonce, destination, and emitted on-chain effects. If a suspicious transaction was sent, the question is not only whether it was mined, but whether the signing key, browser session, backend service, or host that produced it remains trustworthy.
When repeated unexpected submissions appear, the issue may be a compromised signer, malformed application logic, or an integration that is allowing unapproved transaction generation. The right response is to trace the full path from application intent to signed payload to network broadcast, then confirm that no other transactions were created from the same trusted context.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Manages the lifecycle of signing material that can authorize transaction submission. |
| AC-6 — Least Privilege | Limits which services or users can submit signed transactions through a node or provider. | |
| AU-2 — Event Logging | Supports traceability for raw transaction submission, rejection, and abnormal broadcast behavior. | |
| Recommendation — Protect, rotate, and revoke the secrets or keys that authorize transaction workflows. Restrict transaction submission paths to the minimum set of approved roles and services. Log transaction submission events so you can reconstruct who sent what and when. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Submission endpoints can be abused if callers can invoke transaction broadcasting without proper authority checks. |
| Recommendation — Enforce function-level authorization on any API that can broadcast signed transactions. | ||
| NIST CSF 2.0 | PR.AA-05 — Least Privilege | Ensures only approved identities and services can submit or relay signed transactions. |
| Recommendation — Apply least-privilege access to every transaction broadcast path. | ||
Practitioner Guidance
What to watch for: Treat raw transaction submission as a privileged action path. Protect the systems that build and sign the transaction, and make sure the broadcast step cannot silently alter the payload or substitute a different destination, amount, or calldata.
Governance implication: Ownership should be explicit across the wallet, backend, and node/provider boundary. Teams should know who can submit signed transactions, how those actions are recorded, and how failed or unexpected submissions are investigated.
Related resources from NHI Mgmt Group
- How should operators keep an ETH 2.0 validator running reliably on a cloud instance or always-on machine?
- What is the impact of starting an ETH 2.0 validator deposit before the beacon chain is fully synchronized?
- What breaks when a validator or beacon chain process is interrupted during ETH 2.0 testnet setup?
- What is the difference between running an ETH 2.0 validator on a physical computer and running it on a cloud instance?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org