Blockchain Security Best Practices in 2026: 12 Essential Steps for Web3 Developers

Use 12 controls to secure a Web3 application in 2026. Start with the keys that can move funds, then the RPC path, the transaction itself, and how the team ships and watches production. A leaked signing key does damage before a slow node does.

Tatum can sit on the RPC layer: key restrictions, routing, failover, and usage reports. It does not custody assets, audit contracts, or decide when a deposit is final. This page does not rank RPC vendors. For a buying checklist, use how to choose an RPC provider.

Major losses in 2026

The largest is Binance. On October 29, attackers drained exchange hot wallets. Elliptic counts $6.43 billion across 11 blockchains. Binance estimated about $6.3 billion. Chainalysis puts the unauthorized transfers at about $6.4 billion and calls it the largest crypto theft on record. The FBI attributed the attack to North Korea's TraderTraitor group. Binance first pointed to a compromised engineer laptop, then said the investigation found more than one breach point.

April had already put two smaller failure modes on the record. These three are not a complete list of the year. The amounts are the ones the companies and the incident writeups published. This page did not redo their forensics.

Binance was an operator and hot wallet failure: someone could move funds the exchange did not intend to send. Drift was an admin and signer failure. KelpDAO was an RPC and verifier failure: poisoned node responses, plus a bridge that accepted one verifier. A reviewed contract does not cover those paths.

What is blockchain security?

Verdict: Blockchain security is the set of controls around a chain, not a property the chain grants your app.

A network uses signatures, consensus, and distributed validation to protect its ledger. Those controls stop at the protocol boundary. Your wallet, contract, RPC node, backend, oracle, and bridge each add a way to lose funds or serve bad data.

• Wallets and signing systems authorize transactions and control assets.
• Smart contracts run application logic onchain.
• RPC nodes serve chain data and accept signed transactions for broadcast.
• Backend APIs coordinate users and services.
• Oracles and bridges bring in external data and other networks.
• Infrastructure keeps the app available, watched, and recoverable.

The job is to protect that whole path. Securing "the blockchain" and stopping there leaves the path open.

Best for: where to start

Same 12 controls. Different first failure. This is a workload fit, not a score and not a vendor rank.

1. Start with a blockchain security threat model

Verdict: Name the asset and the trust boundary before you write the contract or pick an RPC URL.

A threat model for a blockchain app lists assets, attack paths, and who is allowed to initiate, approve, and broadcast. A custodial wallet has to assume private key theft, unauthorized withdrawal, manipulated chain data, and a confirmation that later vanishes. An analytics product is more exposed to bad RPC responses, missing data, endpoint outages, and leaked API credentials.

• List sensitive assets and privileged operations.
• Map requests across clients, servers, wallets, and nodes.
• Define who can initiate, approve, and broadcast.
• Apply least privilege on every service.
• Repeat the review when a new chain or integration arrives.

Keep a written map of assets, callers, and approval rights. Pick one privileged action, such as a withdrawal, and name every system that can trigger it. If you cannot, the model is not done. The map does not patch a contract or rotate a key. It tells you what to fix first.

2. Protect private keys and transaction signing systems

Verdict: Anyone with a usable private key can authorize what that account is allowed to do. Keep that key out of the app.

Do not hardcode a private key, commit it, ship it in a browser bundle, or write it to logs. Production signing belongs in a hardware security module, a key management service, or an MPC wallet whose client share you encrypt and store yourself. For higher value moves, add a multisignature policy, a spend limit, and a separate admin role. More wallet patterns are in wallet security for Web3 apps.

• Store signing keys in dedicated infrastructure.
• Separate development, staging, and production credentials.
• Require more than one approval for sensitive operations.
• Never send a seed phrase through ordinary app workflows.
• Test backup, recovery, and key compromise on a schedule.

Signing keys live in an HSM, KMS, or MPC setup, with policy checks before authorization. Search repos, logs, and frontend bundles for key material, and confirm a production transaction can be signed only by that system. Storing the key does not prove the signer understood the payload, and an RPC API key is a different secret.

3. Secure blockchain API keys and credentials

Verdict: An exposed RPC key spends quota, raises cost, and can reveal whatever that key is allowed to read. It still cannot sign a transaction by itself.

Treat API credentials as server side secrets. Tatum documents per key IP allowlists and origin restrictions. For a server, an IP allowlist is stronger than an origin check, because a client that is not a browser can forge an Origin header. A browser key is exposed by design. Send the key in the x-api-key header, not in the URL, where logs and referrers keep a copy.

• Store keys in a secret manager or a protected environment.
• Use a separate key per application and environment.
• Rotate on a schedule and immediately after suspected exposure.
• Allowlist IPs for server side access when the provider supports it.
• Keep privileged keys out of frontend JavaScript.
• Alert on unexpected request spikes.

Tatum docs: API key access restrictions and handling exposed API keys.

Server keys are IP restricted, stored outside the repo, and sent in a header. Call from an address outside the allowlist and expect a refusal. Confirm access logs do not contain the raw key. Restricting a key does not validate chain data and does not protect the signing key.

Private keys vs RPC API keys

Verdict: These secrets fail in different places. Protect both. Do not swap the procedures.

4. Secure RPC endpoints and blockchain node access

Verdict: The RPC interface is part of application security because it is how the app reads state and publishes a signed transaction.

An open endpoint can be used for expensive queries, for methods you did not mean to expose, or for denial of service. On a self hosted node, do not publish an admin JSON-RPC port to the internet. Put authentication, network controls, TLS, and method filters between callers and the node. The Geth security documentation warns against exposing an unprotected JSON-RPC interface to an untrusted network.

A managed RPC layer can remove the work of running every node. It does not remove application authorization, safe signing, or credential management. Provider failover improves availability when an upstream is unhealthy. It is not a guarantee about the honesty of RPC data, and it is not a substitute for an audit or for key management.

• Require authentication on protected RPC services.
• Use HTTPS, and secure WebSocket connections where you stream.
• Restrict sensitive methods and namespaces.
• Cap request rate and request size per client.
• Limit expensive batches and deep historical queries.
• Watch unusual traffic and error rates.
• Keep node software current and its admin port private.

Tatum docs: RPC Gateway and RPC nodes.

Callers authenticate, admin methods stay off the public internet, and traffic has a ceiling. From an untrusted network, confirm admin and debug methods are refused, and confirm the app URL is HTTPS. Authentication does not prove the node is on the chain you expect.

Public RPC vs private RPC

Verdict: A private endpoint improves access control. It does not, by itself, improve data integrity or signing safety.

5. Validate blockchain networks and RPC responses

Verdict: A fast response is not a correct response. Check the chain, then check the fields you will act on.

Multichain apps are the usual place this fails. The wrong network yields wrong balances and transactions aimed at an address that means something else on another chain. On Ethereum compatible networks, eth_chainId identifies the chain. Ethereum mainnet is chain id 1, returned as 0x1. Compare that value with the network you meant to use before you build a transaction.

For security critical reads, also check contract addresses and deployment versions, transaction and block identifiers, token decimals and metadata, block height, and whether the node is synced. If a wrong answer is expensive, compare a second independent provider.

curl https://ethereum-mainnet.gateway.tatum.io \
  -H 'content-type: application/json' \
  -H 'x-api-key: YOUR_KEY' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'

Expect 0x1 on Ethereum mainnet. Any other value means you are not on the network you configured. The placeholder YOUR_KEY is not a credential. RPC availability and RPC integrity are related and still distinct.

The app refuses to sign or credit when the chain id, contract address, or decimals do not match configuration. Point a staging config at a different chain id and confirm the write path stops. A matching chain id does not mean the latest block is final.

6. Handle transaction finality and blockchain reorganizations

Verdict: Inclusion in a block is not finality. Credit and release rules have to name the confirmation they require.

A reorg replaces recent blocks with a different canonical history. Apps that credit a deposit on the first inclusion can honor a transaction that later disappears. On Ethereum, block tags express different confidence. These tags are Ethereum consensus semantics. Confirm the equivalent on every other network before you copy the policy.

• latest: the newest block the node has seen. It can still change.
• safe: a block treated as very unlikely to be reorganized.
• finalized: a block with stronger consensus finality.

• Separate pending, included, safe, and finalized in your own state machine.
• Pick a confirmation policy that matches the value at risk.
• Store block hashes and inclusion, and handle removed blocks.
• Make processing idempotent so a replay does not double credit.
• Reconcile deposits and withdrawals after a disruption.

Layer 2 networks and bridges can finalize on a different clock than Ethereum mainnet. Tatum docs: EVM block finality and confidence.

Deposits and releases wait for the confirmation policy written for that chain and that amount. Replay a test deposit notification twice, and drop a recent test block from your local view. Balances should not double, and a removed inclusion should reverse. Finality rules do not inspect what the user meant to sign.

Five checkpoints before a transaction is complete

Five checks, in order. Skipping one is how a valid key signs a bad action, or a broadcast gets treated as final too early.

7. Verify transaction intent before signing

Verdict: A valid signature proves a key signed bytes. It does not prove a person, or a policy engine, meant the effect.

A compromised interface, a swapped calldata payload, or an unexpected contract call can collect a perfect signature on a harmful action. Check destination, chain id, token amount, function, spender allowance, and expected state changes before you ask for a signature. For high value transactions, simulate the call first. Production signers should enforce approval thresholds. The Blockchain Security Standards Council publishes standards oriented context for transaction security and operations.

The signer, human or automated, sees the decoded action and the chain id, and policy can reject it. Submit a staging payload with a changed spender or amount. The signer should stop, not broadcast. An intent check does not keep the key material safe.

8. Audit smart contracts and follow secure coding practices

Verdict: A deployed contract is hard to change. Review it before it holds funds, and assume the review missed something.

Common failures include broken access control, reentrancy, wrong business logic, oracle price manipulation, unsafe external calls, and weak input checks. The OWASP Smart Contract Top 10 is the category list. Ethereum.org documents smart contract security from the protocol side. A longer application view is in smart contract security for Web3 apps.

Before deployment, run unit tests, integration tests, fuzzing, and static analysis. Prefer reviewed libraries over fresh cryptography and fresh accounting. An independent audit matters when the contract holds user funds. An audit is not a promise that no bug remains. Keep monitoring after deploy, and keep a pause or response path where the design allows one.

Tests, analysis, and an independent review exist before the contract custodies value, and admin powers are inventoried. Match the deployed bytecode to the reviewed source. List every address that can upgrade, pause, or move funds. A clean audit does not secure the RPC key, the signer, or the next oracle you trust.

Blockchain security vs smart contract security

Verdict: Contract security is one slice of blockchain security. The rest is keys, RPC, finality, and operations.

9. Secure oracles, bridges, and external integrations

Verdict: A contract can execute exactly as written and still be wrong, because the price or the inbound message was wrong.

Lending that trusts a manipulated price liquidates honest positions. A bridge that trusts a message without checking origin or finality imports another chain's failure. Document how each feed is produced, how fresh it must be, and what range is absurd. Add a circuit breaker for the absurd case. Do not let one unverified source be the only input to a critical action.

Every external dependency has a written trust assumption, a freshness rule, and a stop condition. Name the oracle or bridge on the critical path, and state what happens if it stalls or jumps outside the band. A good oracle policy does not audit your own contract or your signer.

10. Protect your development and deployment pipeline

Verdict: Attackers do not have to break the contract if they can ship a different one.

Dependencies, developer accounts, build systems, deploy scripts, and admin environments are in scope. Require review on security sensitive changes. Protect production branches and deploy credentials. Pin dependencies and scan them. Verify the artifact you deploy. Separate deploy rights from everyday access. Rehearse upgrades on a test network. Keep an inventory of live contracts and the roles that control them. See also enterprise controls around blockchain infrastructure.

Production deploy requires a reviewed change and a credential that everyday laptops do not hold. Try to deploy from a personal token. It should fail. Compare deployed bytecode with the build you intended. A locked pipeline does not watch the contract after it is live.

11. Monitor RPC traffic, transactions, and application behavior

Verdict: Monitoring is a set of alerts with owners. A dashboard nobody pages is not a control.

Watch unusual transaction volume, unexpected admin calls, authentication failures, RPC error spikes, and nodes that fall behind the tip. On the RPC path, track request rate, error rate, auth failures, rate limit responses, sync status, timeouts, and sudden volume changes. Tatum gateway usage reports show requests and routing so you can see traffic shift between providers. Those reports are operational visibility. They are not a certified detection product.

Where webhooks are involved, verify the HMAC digest. Do not trust a request only because it reached your URL. Tatum documents the x-payload-hash header for that check.

Tatum docs: Gateway usage and analytics and authenticating notification webhooks.

Alerts exist for auth failures, error spikes, stalled sync, and privileged calls, and each alert has an owner. Trip one alert in staging, including a webhook with a bad digest. Confirm it pages a person and the bad digest is rejected. Usage charts do not rotate keys or pause a contract.

12. Build redundancy and an incident response plan

Verdict: Assume a node stalls, a provider blips, or a key leaks. Write the recovery before the week it happens.

One RPC URL is an availability risk. Keep a backup for critical workloads. Check chain identity and sync before you send traffic to the backup. Use timeouts, backoff, and circuit breakers. Do not blindly rebroadcast a transaction after a timeout: read the hash first, because the first send may have landed. Practice credential rotation and a recovery path for compromised keys and contracts.

Tatum documents priority failover and load distribution across configured upstreams, including endpoints you bring. That is resilience of connectivity. It does not replace wallet management or a contract audit. Tatum docs: routing strategies and RPC Gateway.

A second endpoint is configured, and an incident note names who rotates keys, who pauses contracts, and who talks to users. Disable the primary in a test. Confirm the app still reads a fresh block from the chain you expect, not only that HTTP succeeded. Failover does not replay a dropped WebSocket for you, and it does not undo a reorg.

Blockchain security checklist for production applications

Use this before launch, then again when volume, chain coverage, or infrastructure changes. Security is not a launch day event.

How to reproduce these checks

There is no incident dataset on this page. The original work is a procedure and a documentation check you can rerun.

On November 2, 2026 the nine Tatum documentation URLs in the cards below each returned HTTP 200. The sentences on those cards follow a documentation map dated October 26, 2026: IP and origin allowlists, regenerate versus expire, gateway routing and failover, Ethereum latest / safe / finalized, HMAC via x-payload-hash, two share MPC with the client share stored by the developer, usage reports, and notification filters. That is a link check plus that map. It is not a penetration test and it is not an uptime study.

How Tatum fits, and where it does not

Verdict: Use Tatum for controlled blockchain connectivity. Keep signing, contract review, and finality policy in your own systems.

Signing infrastructure authorizes transactions. Contract testing protects onchain execution. Application code checks user intent. The RPC layer is the controlled path to nodes. Tatum documents API key restrictions, gateway usage, and routing across upstreams you configure. Teams still write the threat model, the signer policy, and the confirmation rule.

Treat a gateway as one piece of defense in depth. Failover is an availability tool. It does not certify RPC responses, and it does not hold a private key. Supported networks are not identical: confirm the chain, the method, and the finality rule in the docs before you generalize an Ethereum example. Gateway usage is observability, not a detection certification.

Nine Tatum references for these controls

Each card is one documentation page. The RPC Gateway card is marked because this guide's infrastructure examples use it. The other eight are equal parts of the same checklist, not a ranking.

FAQ

Secure the keys. Verify the transactions. Protect the RPC layer. Prepare for failure.

Those four lines are the operating summary of the 12 controls. Least privilege, an independent check on chain data, an alert with an owner, and a tested backup will do more than a slogan about the chain being secure.

Checked November 2, 2026. This is the first published version, so the updated date matches the published date.

Technical references

• Tatum API key access restrictions
• Tatum handling exposed API keys
• Tatum RPC Gateway
• Tatum RPC routing strategies
• Tatum block finality and reorgs
• Tatum webhook authentication
• Tatum gateway usage and analytics
• Tatum Smart Wallet SDK
• Tatum notification conditions and filters
• Tatum RPC nodes
• OWASP Smart Contract Top 10
• Ethereum smart contract security
• Geth node and RPC security
• Blockchain Security Standards Council
• How to choose an RPC provider in 2026