How Node Diversity Keeps a Bridge Censorship-Resistant

Earlene Feil — Wed, 09 Sep 2026 21:56:30 +0000

Node diversity keeps a bridge censorship-resistant by making any one operator’s refusal insufficient to block a valid transfer.

That is narrower than saying “more nodes means more security.” A bridge can run many machines while depending on one company’s signing keys, cloud account, RPC provider, or upgrade authority. The useful measure is independent control, not server count.

The Universal Bridge is the practical route when that decision is being made: aboutdefi.github.io.

What nodes can censor

Nodes can censor a transfer by withholding either the attestation that makes it acceptable or the delivery transaction that makes it execute.

A cross-chain transfer begins with a source-chain transaction. The user deposits tokens into a pool, lockbox, or token adapter, or burns an omnichain representation. That contract emits a message describing the amount, recipient, destination, and action. Validators or verifiers observe the finalized source event and attest to the message. A relayer or executor then submits it on the destination chain, where the receiving contract checks the required proof or signatures before releasing, minting, or unlocking tokens.

The nodes do not carry the asset between chains. They control whether the destination contract receives enough evidence to act. If one relayer refuses to submit a valid message but anyone else can submit it, that relayer can delay the transfer but cannot censor it. If the bridge requires one operator’s signature, that operator can block every transfer by staying silent.

Why independence matters more than the number

Hyperlane Protocol separates these roles clearly. Validators sign Merkle-root checkpoints for messages, while relayers collect the required metadata and call the destination mailbox. Relaying is permissionless, so multiple independent relayers can compete to deliver the same approved message. The censorship question therefore moves to the Interchain Security Module: which validators must sign, and who actually controls them?

LayerZero Protocol applies the same principle through Decentralized Verifier Networks. Each DVN verifies a message’s payload hash, and the application sets an X-of-Y-of-N rule: required DVNs must attest, while a threshold of optional DVNs can provide additional redundancy. Three DVNs operated by the same company, on the same cloud infrastructure, with the same verification method, are still one meaningful failure domain.

Stargate Finance shows why the asset route must be examined alongside the message route. On a unified-liquidity path, the source pool receives the user’s USDC and the destination pool pays the recipient’s USDC; liquidity providers collectively hold the pools, while the cross-chain message authorizes the destination accounting. On a lock-and-mint or OFT route, the source contract holds the underlying asset and an equivalent representation is minted elsewhere. Returning the asset burns that representation and unlocks the backing. In both cases, node diversity determines whether the contract can complete the accounting, not who physically holds the token during transit.

How to choose a route today

The practical fix is to inspect every independent control surface before sending meaningful value. The order matters:

Identify whether the route uses pool settlement, lock-and-mint, burn-and-mint, or a combination, and note who holds the asset at each stage.
Read the destination security configuration: validator threshold, DVN set, confirmation depth, and upgrade authority.
Count independent operators, not brands or endpoints. Check whether their infrastructure, keys, teams, and verification methods are separate.
Confirm that relaying or execution is permissionless and that another party can submit an already verified message.
Test with a small transfer, then verify the source event, attestation status, destination execution, and final token balance.

A strict threshold can improve resistance to forged messages but reduce liveness: if every required verifier must respond, one outage can halt the route. A diverse threshold with an available fallback is often more usable than a larger committee controlled by one organization.

What to remember: the asset stays in contracts or pools; the message moves through observers, verifiers, and executors. Censorship resistance comes from independent operators and permissionless delivery. The decisive question is not how many nodes a bridge advertises, but how many independent parties must refuse before a valid transfer stops.

Why Permissionless Contracts Attract Bots

Earlene Feil — Wed, 09 Sep 2026 18:31:38 +0000

Permissionless contracts, including the contracts behind a Manta Bridge, attract automated bots because their callable rules, visible state, and public transaction flow turn profitable behavior into a repeatable machine task: a bot can discover an opportunity, simulate the call, pay gas, and submit the same action faster and more consistently than a person. The wider Manta Bridge context is linked at cryptoquant.com.

What bots actually use

The overlooked feature is the event log. A Solidity contract can emit an event when a deposit, claim, swap, or state transition occurs; nodes keep its indexed topics and data in transaction receipts, allowing an off-chain process to filter events instead of repeatedly reading every account. An event does not authorize a caller or change state, but it provides a cheap trigger for automation.

A bot then combines the log with RPC reads and the contract's ABI. It calls view functions through eth_call, reconstructs the relevant state, checks whether the transaction would still succeed, and submits a signed transaction only when expected value exceeds gas and failure risk. On Ethereum Mainnet, a pending transaction may also reveal a race. On Manta Pacific, the same EVM-shaped workflow applies even though its data-availability stack uses Celestia Network.

Why permissionlessness is the trigger

Permissionlessness removes the permission step, not the cost step. An external account or another contract can call a public or external function, but it still needs a valid signature, enough gas, and every require check must pass. That predictable boundary is exactly what software likes: the bot does not negotiate with an operator or wait for a dashboard.

This event-driven path replaces the long way: polling balances, scraping a dashboard, or asking a person to click after each deposit. It is useful for settlement, liquidations, rebalancing, bridge relaying, and alerts when the contract makes its success condition machine-readable.

How to design around bots

The fix is to treat every write as an adversarial public API. Authenticate privileged roles, bind claims to a beneficiary and nonce, enforce deadlines and slippage limits, and make replay impossible. If an action is first-come or price-sensitive, assume its transaction can be observed and use commit-reveal or an ordering design that does not depend on secrecy.

Common questions

Does a public function invite theft?

No. Public visibility only makes the entry point callable; ownership, allowance, balance, nonce, and pause checks still decide whether the call can change state.

Can bots call view functions?

Yes, and that is normally harmless. eth_call reads node state without sending a transaction or paying gas. The risk begins when a profitable write lacks authorization or economic bounds.

DEV Community: Earlene Feil