From Smart Contracts to Persistent Financial Policies

Abstract

A smart contract provides deterministic state transition, but deterministic code is not yet a persistent financial policy. Long-lived automation also requires a durable policy model, bounded authorization, external triggering, revocation, observability, and failure handling. This comparative architecture analysis synthesizes academic DeFi literature, a digital-legacy prototype, and primary Ethereum documentation. It separates contract correctness from system reliability and proposes a policy lifecycle with proposed, active, paused, revoked, completed, and failed states. The analysis finds that executors, oracles, admin keys, interfaces, and token issuers remain material dependencies. Owner sovereignty is strongest when automation authority is narrow, inspectable, and revocable rather than when every component is labeled decentralized.

Keywords: smart contract automation; persistent financial policy; rule-based finance; revocation; oracle risk; blockchain observability

Research question

What architecture is required to turn isolated smart-contract functions into persistent, constrained, revocable, and observable financial policies?

Introduction

A contract function can be correct and the financial policy can still fail. The function may never be called. The oracle may be stale. The user may have revoked the instruction in an interface that did not update the contract. The executor may hold broader permissions than the policy intended.

These failures occur because a function answers a local question—what state transition follows this call—while a financial policy must survive time, operational outages, changing authority, and exceptional events.

Method

This paper uses comparative architecture analysis. It reviews Schär’s five-layer DeFi framework, a 2025 blockchain digital-will implementation, broader blockchain-finance literature, and current Ethereum documentation on contracts and oracles. It does not test deployed contracts or claim that the proposed lifecycle is a formal standard.

Smart contracts as execution components

Schär describes smart contracts as applications stored on a blockchain and executed by validators under deterministic consensus rules. Their code and state transitions can be independently inspected. Contracts can also hold assets and enforce customized release criteria.

The same analysis identifies dependencies that qualify “trustless” claims: external data, special administrator keys, upgrade powers, emergency shutdowns, and scalability constraints. A protocol may be transparent while still depending on concentrated authority.

Ethereum documentation adds another boundary. Contracts cannot retrieve off-chain events by themselves, and they do not run on a schedule without an external call. Oracles and automation services solve access and liveness problems while introducing correctness and availability risks.

A financial policy model

A policy should be an explicit object, not an informal interpretation of several contract variables. At minimum it contains:

• owner and authorized roles;
• scope of assets and actions;
• trigger and condition definitions;
• amount, frequency, destination, and time limits;
• activation and expiry;
• cancellation and revocation rules;
• oracle and executor requirements;
• current lifecycle state; and
• a version linked to an audit history.

This representation separates the owner’s instruction from the particular service that submits transactions.

Policy persistence

Persistence means the instruction remains available and evaluable across time, not that it can never change. An immutable instruction that no longer reflects the owner’s intent is a governance failure.

The system needs durable storage, a stable identifier, and version history. Every execution should identify the policy version it evaluated. A replacement policy should explicitly supersede the prior version rather than silently altering fields.

Persistence also depends on economic liveness. An automation can stop when an executor lacks fees or a token changes behavior. Funding, fee limits, and fallbacks belong in the policy’s operating model.

Event-driven triggers

Time, prices, balances, and on-chain events are directly or indirectly observable. Death, incapacity, legal entitlement, and many compliance facts are not.

The contract should distinguish a trigger report from a verified condition. A caller may announce that a review is due. Separate evidence and authority may be required before execution. This prevents one scheduler from becoming an unbounded decision maker.

For high-impact actions, multiple signals, freshness checks, a challenge period, and user notification can reduce false execution. These controls trade speed for safety and should be visible.

Authorization and executor risk

An executor needs permission to call a function, not ownership of every asset. Capability-style permissions can bind the executor to a policy, function, amount, destination, and time window.

Multiple executors can improve availability if execution is idempotent and nonces prevent duplication. They do not improve security if every executor has the same broad key.

Administrator and upgrade roles need similar limits. A timelocked upgrade can give users time to exit or object. Emergency pause can contain harm, but a pause key should not become a transfer key.

Cancellation and revocation

Cancellation removes one pending action. Revocation removes future authority. Both should be first-class state transitions with observable timestamps.

Revocation must compete safely with execution. A contract should define ordering when a revoke and execute transaction enter the same block. Delays can provide an intervention window for consequential policies.

Recovery is harder. If the owner loses the key needed to revoke, a guardian or multisignature process may rotate authority. Recovery controls need delays, notifications, and bounded power because they can become an alternative path to asset seizure.

Observability and auditability

Public transactions are not automatically understandable. A policy system should expose:

• last evaluation and result;
• source and freshness of external data;
• caller and policy version;
• transaction hash and confirmation state;
• remaining limits;
• current revocation status; and
• categorized failure reasons.

Events should support independent monitoring. Sensitive data should remain off-chain or be committed in minimized form. Auditability is evidence about decisions, not publication of personal information.

Failure handling

Failures can be temporary, permanent, or ambiguous. Network congestion may justify a bounded retry. A revoked policy should never retry. Stale oracle data should pause evaluation. A downstream token failure should not consume an allowance unless value moved.

State should distinguish failed submission from reverted execution and confirmed completion. Retry logic must be idempotent. Circuit breakers need a clear recovery path. Fallback oracles and executors must not silently weaken the original security requirements.

Owner sovereignty

Sovereignty is more than holding a key. The owner needs to understand active policies, inspect delegated authority, change instructions, and recover from predictable failures.

An interface that hides an upgrade key or executor dependency undermines that control. A non-custodial label does not cure opaque policy state.

The strongest architecture uses deterministic execution for bounded actions and keeps judgment outside the contract unless it can be represented as verifiable input under an accepted governance process.

Design implications

Design policy state before writing execution functions. Use least-privilege roles and explicit lifecycle transitions. Require versions, expirations, nonces, and destination limits. Treat oracles and schedulers as named dependencies. Make pause, revoke, retry, and recovery testable.

Testing should include adverse ordering, stale data, executor outage, fee spikes, duplicate calls, partial dependency failure, and compromised roles. Successful “happy path” execution is insufficient evidence of persistence.

Transaction, automation, and policy

A transaction is a bounded request to change state. A contract function defines conditions under which one class of request is accepted. Automation adds an external process that decides when to submit that request. A policy adds continuity of intent: it identifies the owner, scope, recipients, conditions, lifecycle, exceptions, and evidence needed to decide whether an automated action remains authorized.

These layers fail differently. A transaction can be malformed or reordered. A function can contain a bug or grant excessive authority. An automation can stop calling a correct function. A policy can remain executable after the owner's circumstances or intent have changed. Treating all four as “a smart contract” hides the control problem.

Deterministic execution is valuable because equal validated inputs produce the same state transition. It does not establish that the inputs are current, complete, or legitimate. A timestamp can be accurate while the intended recipient is wrong. An oracle can faithfully report a market price that is economically distorted. A signer can be technically authorized after its real-world mandate ended.

Policy lifecycle and state transitions

Creation should define a unique policy identity, owner, assets, limits, recipients, trigger types, expiry, and amendment rule. Authorization then grants only the permissions needed for that policy. Activation confirms that dependencies are available and that the policy can be simulated against current state. Execution consumes a valid trigger and records its result. Cancellation stops a queued action; revocation removes continuing authority; expiry makes a policy invalid without a separate owner transaction.

The states should be explicit. A policy may be draft, active, paused, execution-pending, completed, cancelled, revoked, expired, or failed. Transitions should be allowlisted. For example, a revoked policy should never return to active merely because an executor resubmits an old payload. A failed execution may be retried only if the action is idempotent or the system can prove that no partial effect occurred.

Amendment is not equivalent to overwriting configuration. Material changes should create a new version linked to the previous one, invalidate obsolete signatures, and pass through a fresh delay when they increase authority or change a recipient. This preserves the history needed to determine which instruction was operative at a given time.

Allowances and scoped authority

Many automations rely on token allowances or delegated signing. An unlimited allowance makes repeated execution convenient but expands the loss if the spender is compromised. A safer policy constrains asset, amount per action, cumulative amount, destination, time window, and callable function. The allowance should expire or be revoked when the policy ends.

Authorization scope should also distinguish proposing, scheduling, executing, pausing, and changing a policy. An executor that can call a permitted transfer does not need authority to select a new recipient. A scheduler that observes a time condition does not need custody. An oracle that supplies an external fact should not control the action taken in response. Separation of duties reduces the damage from one compromised role.

Recipient behavior can invalidate assumptions. A beneficiary may rotate an address, become ineligible, decline receipt, or be unable to use a token on the chosen chain. Policies need acceptance and fallback states rather than assuming that a successful transfer is a successful outcome.

Scheduler and executor architecture

Contracts do not wake themselves. A scheduler observes time, block height, or an event and determines that an execution attempt is due. An executor builds and submits the transaction. Combining both roles is simple but creates one availability and censorship dependency. Multiple executors improve liveness, yet they introduce duplicate attempts and competition for fees.

Executor rotation should be planned before failure. A policy can allow a new executor after a delay, require owner approval, or use a registry governed by bounded rules. Rotation must not change the policy's economic terms. The system should expose which executor is active, its last successful heartbeat, and the route for replacing it.

A dry-run mode evaluates current conditions and produces the proposed state change without authorization to broadcast it. Simulation can reveal expired allowances, insufficient balances, changed fees, rejected recipients, or oracle staleness. It cannot guarantee production execution: mempool ordering, state changes, and adversarial transactions can intervene between simulation and inclusion. The result should therefore include the state version and an expiry time.

Triggers, oracles, and synchronization

Time triggers differ from event triggers. A timestamp is available from the chain's execution environment within protocol tolerances, while an external event requires an attestation or oracle. Market prices, identity status, incapacity, and legal orders do not become trustworthy merely because a contract receives them. Oracle design must address source diversity, freshness, update failure, manipulation, and dispute.

Policies that span chains or off-chain accounts also face synchronization risk. One component may report an action as pending while another treats it as final. A chain reorganization can remove an event after an external system has acted on it. Finality thresholds, unique operation identifiers, and reconciliation are needed before dependent actions proceed.

Every trigger should bind to the policy version, relevant state, nonce, deadline, and intended chain. Otherwise an old signed instruction may be replayed after revocation or on another network. A consumed-operation registry can reject duplicates, but it must be updated atomically with execution.

Liveness, censorship, and transaction ordering

A valid policy has no effect if no executor submits it or validators censor the transaction. Redundant executors, permissionless execution with bounded rewards, and an owner-operated fallback can improve liveness. Each option changes incentives and attack surface. Permissionless execution should reveal no secret needed to redirect value, while rewards must not encourage premature or repeated attempts.

Frontrunning is relevant when an observer can profit from the pending action or change the state it relies on. Slippage bounds, commit-reveal techniques, private transaction routes, or batch execution may reduce exposure, but each adds dependencies. A policy that trades should state acceptable price impact and fail safely when the bound is exceeded.

Liveness and cancellation can conflict. A fast executor may submit before an owner's revocation is included. Designs can impose an execution delay after a trigger, prioritize cancellation nonces, or require the executor to reference the latest policy version. There is no universal solution; the delay should reflect the harm from late execution versus erroneous execution.

Observability, reconciliation, and recovery

An event log is not sufficient operational observability. Users need to know whether a trigger was detected, simulation passed, a transaction was broadcast, finality was reached, and downstream records agree. Monitoring should distinguish “not due,” “waiting for evidence,” “failed validation,” “submitted,” and “completed” rather than collapsing them into success or failure.

Reconciliation compares intended and realized state. It can detect partial execution, fee-on-transfer behavior, a changed token balance, or an off-chain record that did not update. Recovery then depends on the failure class. Transient infrastructure failure may justify a bounded retry. Invalid authorization requires revocation. A partially completed multi-step action may need compensation rather than repetition.

Emergency pause can contain an exploit but grants censorship power to its controller. It should be limited by scope and time, visible to the owner, and paired with a recovery route. A pause that can never be lifted without the same compromised key is not a recovery mechanism.

Auditability, sovereignty, and open questions

Auditability requires reconstruction of why an action occurred: the policy version, authorizing identity or key, trigger evidence, simulation result, executor, transaction, and final state. Verifiability means an independent reviewer can check those records against the rules. Neither requires exposing private documents publicly; commitments and access-controlled evidence can support later review.

Owner sovereignty means more than initial consent. The owner must be able to inspect permissions, revoke future authority, replace failed dependencies, and export sufficient state to continue without one interface. Sovereignty is weakened when a nominally non-custodial system controls the only scheduler, upgrade key, or readable policy record.

Future research should measure duplicate-execution prevention, cancellation latency, executor availability, oracle staleness, reconciliation accuracy, and recovery under partial failure. Formal verification can test state-machine properties, while adversarial simulation can test ordering and dependency failure. Neither substitutes for governance and operational evidence.

Praxifi supplies a disclosed design context for asking these questions. It is not evidence that a particular architecture satisfies them. Any implementation would require separate code review, threat modeling, legal analysis, and production monitoring.

Comparative architecture choices

A centralized scheduler can be simple to operate and easy to pause, but it is a single availability and censorship point. A permissionless keeper network can improve liveness while introducing incentives, public trigger visibility, and duplicate submissions. User-operated execution maximizes direct control but may fail precisely when the user is unavailable. A durable policy may combine these modes: routine execution by bounded operators, independent fallback after a delay, and owner cancellation throughout the pending period.

On-chain configuration maximizes shared verifiability but makes changing and private information difficult to protect. Off-chain policy storage is more flexible but depends on availability and authentic delivery. A hybrid can commit to a versioned policy on-chain while keeping sensitive details in access-controlled storage. The commitment proves integrity, not availability; redundant storage and export remain necessary.

Upgradeable contracts can repair defects and adapt dependencies, yet upgrade authority can change the rules after consent. Immutable contracts avoid that power but can preserve flaws forever. A constrained upgrade path should define who proposes a change, which properties cannot change, the delay, owner exit, and the treatment of queued actions.

Verification strategy

Testing should cover more than successful calls. Property tests can assert that revoked policies never execute, cumulative limits cannot be exceeded, and an operation identifier is consumed once. Stateful fuzzing can explore unexpected transition sequences. Forked-state simulations can test real token behavior and oracle conditions. Formal methods may prove selected invariants, but the proof covers the specified model and implementation, not external services or legal intent.

Operational drills should rotate an executor, pause a policy, restore from a failed scheduler, reconcile a partial action, and export the policy through a second interface. Results should be retained without secrets. Repeated drills turn recovery from a diagram into evidence about actual dependencies.

Future research

Empirical work should measure execution latency, cancellation races, retry behavior, keeper concentration, and user comprehension. Cross-chain policies need explicit study of inconsistent finality and bridge failure. Research on beneficiary-directed policies should test acceptance, refusal, changed addresses, and disputed triggers. These questions determine whether persistent automation preserves intent when normal assumptions stop holding.

Standards work should define portable policy receipts so an owner can verify scope and history across interfaces. Portability must include revocation state and consumed operations; exporting only human-readable settings can omit the facts needed to prevent replay.

Limitations

This conceptual analysis does not verify production code or compare automation networks empirically. Ethereum documentation describes one ecosystem, although the architectural problems are broader. Governance and legal requirements vary by application and jurisdiction.

Conclusion

Smart contracts make rules executable. Persistent financial policies make authority governable across time.

The additional architecture is not peripheral: policy identity, triggers, bounded roles, revocation, observability, and failure recovery determine whether deterministic execution remains faithful to an owner’s instruction. Automation should be judged by its behavior when inputs, services, and people fail—not only when the contract receives an ideal call.

Operational evidence should test these controls under realistic and adversarial failure conditions.

References

1. Schär, Fabian. 2021. “Decentralized Finance: On Blockchain- and Smart Contract-Based Financial Markets.” https://doi.org/10.20955/r.103.153-74
2. Ethereum.org. “Introduction to smart contracts.” Accessed 2026-07-30. https://ethereum.org/developers/docs/smart-contracts/
3. Ethereum.org. “Oracles.” Accessed 2026-07-30. https://ethereum.org/developers/docs/oracles/
4. Hernando-Corrochano, Jesus, Rafael Pastor-Vargas, and Roberto Hernández-Berlinches. 2025. “Trusted wills for digital assets using blockchain: a practical case.” https://doi.org/10.1016/j.bcra.2025.100289

Conflict disclosure

PraxiHub is associated with Praxifi. The author may hold roles or ownership interests in Praxifi, whose broader research interests include persistent and revocable financial automation. No Praxifi system was tested in this paper.

Publication history

Draft version 0.1, prepared 2026-07-30. Not peer reviewed.