Introduction
Smart contracts are frequently described as autonomous financial infrastructure.
At the policy level, this description can be accurate.
A contract can enforce rules such as:
execute only after a specified timestamp; transfer no more than a predefined amount; allow execution only when a particular condition is satisfied; prevent execution after cancellation; restrict the recipient; prevent the same instruction from being executed twice.
Once deployed, these constraints can be enforced independently of the application interface that originally created them.
But there is another question:
Who causes the transaction to happen?
A smart contract normally does not wake itself up when a condition becomes true.
Some external process must usually detect that the condition has been satisfied and submit a transaction that calls the relevant contract function.
This creates two separate properties:
Policy correctness describes whether the contract correctly enforces the financial instruction.
Execution availability describes whether an eligible instruction can actually reach the blockchain and be executed.
A system can have strong policy correctness and weak execution availability at the same time.
That distinction becomes increasingly important when smart contracts are used for scheduled transfers, recurring financial actions, inheritance mechanisms, portfolio rules, collateral management, automated treasury operations, and other time-dependent financial policies.
Scope and Review Approach
This technical review decomposes automated on-chain execution into functional layers and evaluates dependencies using primary protocol specifications and infrastructure documentation. It distinguishes custody, policy-correctness, and execution-availability failures; it does not estimate vendor reliability or network outage probabilities.
2. The execution path
A simplified automation sequence can be represented as:
User intent → encoded financial policy → on-chain contract state → condition detection → transaction construction → transaction submission → network inclusion → contract execution → verification
Only part of this sequence exists inside the smart contract.
The rest may depend on infrastructure.
This infrastructure does not necessarily control the user's assets. Nevertheless, its failure can affect whether the intended financial action occurs.
This is why custody risk and execution risk should be analyzed separately.
3. Dependency one: access to blockchain state
Before an automated system can determine whether an action is eligible, it often needs access to blockchain state.
Applications typically obtain this state through blockchain nodes exposed through JSON-RPC [2] interfaces.
The automation process may need to query information such as:
current block timestamp; contract state; token balances; allowance levels; execution status; nonces; emitted events; transaction receipts.
If the infrastructure responsible for retrieving this information becomes unavailable or returns stale information, the underlying contract may remain perfectly functional while the automation layer temporarily loses visibility into it.
The financial rule has not failed.
The observer has failed.
This creates an important architectural distinction between state integrity and state accessibility.
The blockchain may preserve the correct state while an application cannot reliably access it.
For high-reliability automation, depending on a single RPC endpoint [2] therefore creates a different type of risk from depending on the smart contract itself.
4. Dependency two: condition detection
Many financial automations require an external mechanism to determine when execution should be attempted.
Consider several examples:
a scheduled transfer becomes executable after a timestamp; an inactivity-based policy becomes eligible after a defined period; a collateral position crosses a threshold; an on-chain event activates another rule; an account requires periodic maintenance; a governance or treasury action enters an executable state.
The condition may be entirely verifiable on-chain.
But something still needs to check it.
That role may be performed by:
a protocol-operated executor; a decentralized automation network [5]; independent keepers; a relayer; a backend worker; an account-abstraction bundler; or any permissionless caller incentivized to execute the transaction.
These approaches have different trust and availability characteristics. Chainlink's documentation is used here as an example of this architectural class, not as evidence that a particular Automation version remains active: the documentation records the 2026 sunset of Automation v1.x and v2.1 and directs users to migrate to CRE. [5]
The critical question is therefore not simply whether the condition is deterministic.
It is whether the system remains executable when one detection mechanism disappears.
5. Dependency three: transaction construction and submission
Once an eligible action has been identified, a valid blockchain transaction must still be constructed and submitted.
Automation infrastructure may need to manage:
transaction encoding; transaction nonces; gas estimation; fee configuration; retries; replacement transactions; signing infrastructure; transaction expiration; RPC submission.
Relayer systems exist partly because these operational requirements become difficult to manage reliably at scale. OpenZeppelin's current Relayer documentation describes transaction submission responsibilities; its legacy Defender documentation is retained only as historical evidence and now directs migration away from Defender. [3] [4]
This illustrates an important point about automated finance:
The smart contract may simplify financial policy while the execution infrastructure remains operationally complex.
Complexity has therefore not necessarily disappeared.
Some of it has moved.
6. Dependency four: gas availability
An executable financial policy still needs computational resources.
For most blockchain architectures, this means gas.
An automation system may have a valid rule, a functioning contract, an available executor, and correct state information while still failing to execute because the transaction sender cannot fund the transaction.
This makes gas availability part of the operational security model.
The relevant questions include:
Who funds execution? How is the funding balance monitored? What happens when the balance becomes insufficient? Can another executor take over? Is the user required to maintain native gas assets? Can gas be sponsored? Can the rule remain pending until execution becomes economically possible?
Account-abstraction architectures make this dependency particularly visible.
ERC-4337 [1], for example, introduces infrastructure roles including bundlers and optional paymasters. These components can improve user experience and enable alternative gas-payment models, but they also expand the execution architecture beyond the smart account itself.
Gas abstraction therefore changes who manages execution costs.
It does not eliminate execution costs.
7. Dependency five: transaction inclusion
Submitting a valid transaction does not guarantee immediate execution.
The transaction still needs to enter the network and eventually be included in a block.
The exact path depends on the blockchain architecture.
On some networks, transactions may pass through additional infrastructure such as sequencers. Relayer documentation for rollups, for example, explicitly recognizes dependency on chain sequencers or aggregators.
This means an automation system can experience delays even when:
the contract is functioning; the execution condition is valid; the executor is online; the transaction is correctly constructed; and sufficient gas is available.
The failure has moved further down the infrastructure stack.
For financial automation, this distinction matters because execution may be time-sensitive.
The appropriate measure is therefore not merely whether execution eventually succeeds.
Systems may also need to consider execution latency and bounded delay.
8. Dependency six: post-execution verification
Automation does not necessarily end when a transaction is submitted.
Reliable systems often need to determine whether the transaction was:
accepted; included; reverted; replaced; dropped; confirmed; or reorganized.
Without this stage, an automation worker may incorrectly assume that an instruction has been completed.
This can lead to several problems.
It may retry an already executed operation.
It may stop monitoring an operation that actually failed.
It may show the user a state that differs from the blockchain.
Or it may initiate dependent actions based on an incorrect execution assumption.
Post-execution verification is therefore part of the automation lifecycle rather than merely an application-interface feature.
9. Non-custodial does not mean infrastructure-independent
One of the most important distinctions is between custody and availability.
An automation provider may have no ability to arbitrarily transfer user assets.
The contract may strictly constrain:
destination; amount; timing; authorization; execution state.
This significantly limits custody-related trust.
However, the same system may still depend on infrastructure operated by the provider to trigger transactions.
The provider therefore may not possess asset control, while still contributing to execution availability.
These are different trust surfaces.
A useful security analysis should ask both:
Can the infrastructure operator misuse the assets? Can the failure of the infrastructure operator prevent a valid policy from executing?
The first question concerns authority.
The second concerns liveness.
Strong financial automation requires attention to both.
10. Replaceability changes the risk
Not every external dependency represents the same level of risk.
A critical factor is whether the dependency is replaceable.
Consider two architectures.
In the first system, only one privileged server can execute a financial rule.
If that server disappears, execution stops.
In the second system, anyone can call the execution function once the contract verifies that the rule is eligible.
The protocol may still operate its own executor for convenience, but that executor is not structurally required.
The second system still has operational dependencies, but the consequences of losing one operator are very different.
This suggests that infrastructure should be evaluated across several dimensions:
Authority — what can the component change? Availability — what happens if it disappears? Replaceability — can another component perform its role? Observability — can failures be detected? Recoverability — how quickly can execution resume? Redundancy — are independent alternatives available?
The number of dependencies alone is therefore not a sufficient risk measure.
Their failure characteristics matter more.
11. Toward an execution dependency model
A practical model for evaluating financial automation can divide the system into four layers.
Policy layer
Defines what is allowed.
Examples include smart contracts, authorization logic, amounts, recipients, timestamps, and cancellation states.
Primary risk:
Incorrect or exploitable policy logic.
Observation layer
Determines whether the policy has become executable.
Examples include RPC infrastructure, indexers, event listeners, automation nodes, and monitoring workers.
Primary risk:
Failure to detect an eligible state.
Execution layer
Constructs, funds, signs where necessary, and submits the transaction.
Examples include executors, relayers [3] [4], keepers, bundlers, paymasters, and transaction managers.
Primary risk:
Failure to deliver a valid execution attempt.
Settlement layer
Determines whether the blockchain includes and finalizes the transaction.
Examples include validators, block builders, sequencers, and the underlying network.
Primary risk:
Delay or failure in transaction inclusion or finality.
This model makes it possible to discuss automation resilience without reducing the analysis to a binary distinction between centralized and decentralized systems.
12. Infrastructure minimization versus infrastructure resilience
There are two ways to reduce dependency risk.
The first is to remove unnecessary dependencies.
The second is to make necessary dependencies resilient.
These strategies are different.
Removing an application server from an execution path may reduce architectural complexity.
But some external mechanism may still be required to submit the transaction.
At that point the question becomes whether the remaining mechanism can survive failures.
Possible resilience strategies include:
multiple independent RPC endpoints; redundant execution workers; permissionless execution; multiple relayers; gas-balance monitoring; automatic executor failover; transaction retry policies; alternative submission paths; observable execution states; alerts for delayed rules; explicit incident procedures.
The objective should not necessarily be zero infrastructure.
For many applications, that is unrealistic.
A more useful objective is to prevent a single invisible dependency from becoming a permanent execution bottleneck.
Discussion
The distinction between contract logic and execution infrastructure becomes more important as on-chain systems move from interactive transactions toward persistent financial instructions.
When users manually initiate every transaction, temporary infrastructure failure is often visible immediately.
When a financial instruction is expected to execute days, months, or years later, the reliability requirement changes.
The system must preserve more than the rule.
It must preserve a credible path from eligible state to executed transaction.
This is especially important for long-duration policies such as:
inheritance instructions; scheduled asset transfers; recurring treasury operations; automated portfolio rules; long-term savings mechanisms; collateral management; institutional policy execution.
For these systems, persistence should be evaluated at both the policy and execution layers.
Limitations
This research is primarily architectural and conceptual rather than empirical.
It does not estimate historical outage probabilities for individual RPC providers, relayers, bundlers, sequencers, or blockchain networks. It also does not compare the reliability of specific infrastructure vendors.
Different automation architectures may remove, replace, replicate, or decentralize some of the dependencies discussed here. The dependency model should therefore be interpreted as a framework for evaluating systems rather than as a claim that every automated financial protocol contains every component described.
Conclusion
Smart contracts can make financial policies deterministic without making the entire automation stack autonomous.
Between an on-chain condition becoming valid and the corresponding transaction being finalized, multiple infrastructure components may participate in the process.
RPC endpoints expose state.
Workers and automation networks detect conditions.
Executors, relayers, or bundlers construct and submit transactions.
Gas funding makes execution economically possible.
Sequencers, builders, validators, and networks determine inclusion.
Monitoring infrastructure determines whether the result is understood correctly.
None of these dependencies automatically makes an automated financial system custodial or insecure.
But ignoring them produces an incomplete security model.
The relevant question for on-chain financial automation is therefore no longer only:
Can the smart contract enforce the rule?
It is also:
Can the system preserve a reliable path to execution when individual infrastructure components fail?
As financial instructions become more persistent, this second question becomes part of the financial policy itself.
AI-Assisted Research Process
AI tools assisted in selected stages of this publication process. Their role was limited to organizing infrastructure dependency categories, exploring related execution and availability terminology, reviewing the hierarchy of the article, and improving the clarity of technical explanations.
The authors developed the research questions, dependency framework, interpretation of technical documentation, conclusions, and final validation.
AI tools did not independently produce research findings, perform scientific validation, or replace human academic judgment.
References
- Ethereum Improvement Proposals. EIP-4337: Account Abstraction Using Alt Mempool. https://eips.ethereum.org/EIPS/eip-4337 (opens in a new tab)
- Ethereum.org. JSON-RPC API. https://ethereum.org/developers/docs/apis/json-rpc/ (opens in a new tab)
- OpenZeppelin. Relayer documentation. https://docs.openzeppelin.com/relayer/ (opens in a new tab)
- OpenZeppelin. Defender Relayers documentation (maintenance-era documentation). https://docs.openzeppelin.com/defender/module/relayers (opens in a new tab)
- Chainlink. Automation documentation. https://docs.chain.link/chainlink-automation (opens in a new tab)