Bounded authority and fault-aware execution for autonomous financial agents.

00

Abstract

Autonomous software systems are becoming capable of performing increasingly sophisticated financial tasks. Modern agents can continuously observe market conditions, process structured and unstructured information, formulate trading hypotheses, select tools, coordinate specialized reasoning processes, and generate executable trading decisions without requiring synchronous human participation. These capabilities make autonomous agents potentially useful participants in financial markets, but they also introduce a fundamental systems problem. An agent may need the authority to initiate financial actions without requiring unrestricted control over the account, capital, credentials, or administrative permissions associated with those actions.

Existing trading interfaces do not generally provide an adequate solution to this problem. Exchange API credentials and wallet-based signing mechanisms typically grant authority according to relatively coarse venue-defined permissions. At the application layer, finer constraints are frequently expressed as instructions given to the agent itself: trade only certain markets, do not exceed a specified leverage level, limit position size, avoid excessive order frequency, or stop trading after a particular loss threshold. Such instructions can influence the behavior of an autonomous system, but they do not constitute an independent authorization mechanism. The same process that decides what it wants to do remains responsible, directly or indirectly, for respecting the constraints intended to govern it.

Oppen addresses this problem by separating decision authority from execution authority. An autonomous agent may determine which financial action it wishes to perform, while an independently controlled local execution system determines whether that action falls within the authority delegated by the operator. The execution system evaluates requests against operator-defined policy, current account state, market state, and outstanding execution commitments before producing a cryptographic signature. An agent therefore does not require possession of the signing credential that ultimately authorizes its requests at the trading venue.

We model this relationship using an authorization function

where $a_t$ is an action proposed by agent $A_i$, $x_t$ is the relevant execution state observed at time $t$, and $P_i$ is the authority policy assigned to that agent. For every transaction signed through the guarded Oppen execution path, the intended invariant is

This model extends beyond simple request filtering. Because financial execution is asynchronous, Oppen treats an order as a persistent state transition rather than a synchronous request-response operation. A venue may accept an order even when the local system never receives the corresponding acknowledgement. Orders may partially fill, cancellation requests may fail, connections may be interrupted, and application processes may restart while positions remain live. Oppen therefore records execution intent durably, represents uncertain outcomes explicitly, maintains reservations for outstanding risk, and reconciles its local execution model against venue state.

Oppen is designed as a local-first system. Signing credentials, policies, execution state, and enforcement logic remain under the operator's control rather than depending on an Oppen-operated custody service. The initial implementation targets perpetual futures markets and uses Hyperliquid as the first execution venue. The broader architecture, however, is intended to define a venue-independent capability model through which autonomous software can receive precisely bounded financial authority.

This paper describes the system model, authority representation, guarded execution protocol, concurrency semantics, execution state machine, reconciliation mechanism, credential architecture, security properties, threat model, and operational limitations of Oppen. It does not assume that autonomous agents make profitable decisions, nor does it claim that execution constraints eliminate financial loss. Its scope is narrower: to provide an enforceable boundary between autonomous reasoning and financial authority.

01

Introduction

Automation has been present in financial markets for decades. Order-management systems automate transmission and cancellation, execution algorithms automate the decomposition of large orders, quantitative strategies automate the production of trading signals, and market-making systems continuously update orders according to deterministic models. Although these systems can be highly sophisticated, they have traditionally been constructed around relatively narrow operating assumptions. Their input spaces, permitted actions, and decision procedures are usually defined explicitly by their developers.

The emergence of general-purpose autonomous agents changes this model. Rather than executing a predetermined function over a fixed set of inputs, an agent may dynamically determine which information is relevant, which tools should be invoked, which intermediate tasks should be delegated, and which actions should ultimately be taken. A single autonomous system may consume price data, funding information, order-book state, news, research reports, portfolio information, and natural-language instructions while continually revising its behavior according to the environment it observes.

This flexibility is precisely what makes autonomous systems attractive for financial applications. It is also what makes conventional approaches to authorization increasingly inadequate.

Consider an operator who wishes to allow an autonomous agent to trade BTC and ETH perpetual futures using at most USD 25,000 of allocated capital, never exceeding five times leverage and never creating more than USD 50,000 of aggregate notional exposure. The agent may be free to determine when to trade, which of the two markets to trade, whether to provide or consume liquidity, and how to manage the resulting position. The operator, however, does not intend to delegate the authority to increase the capital allocation, trade an unrelated market, change the risk limits, expose the account-owner credential, or disable the controls constraining the agent.

A conventional API credential rarely expresses this complete authority boundary. The credential may permit trading broadly, while the intended restrictions exist only in application logic or natural-language instructions. If those restrictions are evaluated by the same autonomous process that produces the execution decision, the security model becomes circular: the process being constrained is also relied upon to respect the constraint.

Oppen is based on the premise that this is the wrong abstraction.

The fundamental problem is not merely how an agent should trade. It is how an operator can delegate a subset of financial authority to software while retaining independent control over the boundary of that delegation.

We therefore distinguish two concepts that are frequently treated as equivalent:

and

Decision authority is the ability to determine that a particular action should be taken. Execution authority is the ability to cause that action to become effective at a financial venue.

An autonomous agent may possess the former without possessing the latter directly.

Under the Oppen model, an agent generates an execution request. That request is submitted to an independently controlled execution system. The execution system authenticates the requesting agent, determines the capital domain associated with it, obtains the state required to reason about the consequences of the proposed action, evaluates operator-defined policy, and only then produces the cryptographic signature required by the venue.

The desired flow is therefore

where $A_i$ is an autonomous agent, $E$ is the Oppen execution system, and $V$ is the trading venue.

The important property of this architecture is not simply that Oppen exists between the agent and the exchange. A conventional proxy can also occupy that position. The important property is that the authorization mechanism inside $E$ is not controlled by $A_i$, and that the signing credential required to convert a request into an exchange action remains outside the agent's execution context.

This gives Oppen the role of a reference monitor for financial execution. In classical computer-security terminology, a reference monitor mediates access by subjects to protected objects according to an independently enforced authorization policy. In the Oppen model, the autonomous agent is the subject, financial actions are the protected operations, and the signing mechanism constitutes the final authority boundary through which those operations become effective.

The analogy is useful because it changes the design objective. The goal is not to make an agent incapable of generating an undesirable request. In a sufficiently general system, that assumption is neither realistic nor necessary. The goal is to ensure that undesirable requests exceeding explicitly delegated authority do not acquire a valid signature through the protected execution path.

This distinction becomes particularly important for language-model-based systems. Large language models can be influenced by incomplete context, contradictory instructions, model updates, tool errors, or malicious external content. Prompt injection provides a concrete example: external data can carry instructions that alter an agent's behavior. An agent that reads untrusted information may encounter content designed to alter its effective behavior. Attempting to solve such a problem entirely within the reasoning context asks the same model to distinguish trusted instructions from adversarial instructions in every relevant situation.

Oppen does not attempt to solve prompt injection at the reasoning layer. Instead, it assumes that the agent may eventually produce an unwanted request and asks a narrower systems question: what authority can that request exercise?

If an injected agent attempts to open USD 500,000 of exposure while its independently configured authority permits USD 50,000, the execution layer should refuse the request irrespective of why the agent generated it. If the same compromised agent generates a harmful trade that nevertheless lies entirely within its USD 50,000 authority boundary, Oppen may permit it. This residual risk is deliberate and unavoidable within the stated model. Oppen constrains delegated authority; it does not determine whether every authorized decision is economically desirable.

This observation motivates the concept of bounded authority.

A bounded authority is an explicitly defined subset of possible financial actions that a software process may cause the execution system to authorize. Rather than treating an exchange account as a binary object that an agent either controls or does not control, Oppen treats authority as a multidimensional policy over markets, capital, exposure, leverage, action type, execution frequency, price conditions, loss conditions, and operator supervision.

The remainder of this paper develops this model formally and describes how it interacts with asynchronous financial execution.

02

System Model

Oppen consists conceptually of four principal actors: the operator, the autonomous agent, the Oppen execution core, and the external trading venue. A fifth abstraction, the container, associates an agent with an isolated capital domain, delegated signing authority, policy, and execution history.

Let $O$ denote the operator. The operator is the ultimate administrative authority within the Oppen system. The operator determines which autonomous processes may interact with the system, how much capital is allocated to each process, which execution constraints apply, and whether a particular agent is active, suspended, or revoked. Oppen does not assume that the operator participates synchronously in every trading decision. Indeed, one of the purposes of the architecture is to permit meaningful autonomy. The operator instead defines the boundary within which autonomous execution may occur.

Let $A_i$ denote autonomous agent $i$. Oppen intentionally places few requirements on the internal architecture of $A_i$. It may be a large-language-model agent, a deterministic quantitative strategy, a collection of specialized agents, a human-controlled client, or another software process capable of invoking the Oppen interface. This abstraction is important because the execution system should not derive its security properties from the correctness of a particular model architecture.

With respect to authorization, $A_i$ is treated as untrusted.

This does not mean that Oppen assumes the agent is malicious. Rather, it means that correct policy enforcement must not depend on the agent voluntarily enforcing its own restrictions. A correct agent, a buggy agent, and a compromised agent traverse the same authorization boundary.

Let $E$ denote the Oppen execution core. $E$ forms the principal trusted computing base of the system. It authenticates requests, resolves agent identity, loads policy, obtains external state, projects the effect of proposed operations, accounts for concurrent commitments, records authorization decisions, constructs venue-specific transactions, controls access to the delegated signing credential, submits signed actions, processes execution events, and reconciles local state with the venue.

Let $V_j$ denote trading venue $j$. The initial implementation targets Hyperliquid, but the system model distinguishes the venue from the Oppen execution layer because venue semantics are not universal. Different exchanges expose different account structures, credential models, order types, cancellation semantics, margin systems, nonce rules, and failure behaviors. Oppen therefore uses venue adapters rather than assuming that an authorization decision or execution property automatically generalizes across exchanges.

Finally, let $C_i$ denote the execution container assigned to agent $A_i$. Conceptually,

where $Account_i$ is the venue account or isolated trading domain associated with the agent, $K_i$ is the delegated trading credential used by Oppen for that account, $P_i$ is the authority policy assigned by the operator, and $\mathcal{J}_i$ is the durable execution record maintained locally.

The container is important because policy alone is not sufficient to establish isolation. Suppose two agents use independent Oppen policies but ultimately sign transactions against the same unrestricted venue credential and the same margin account. Local software may distinguish the agents logically, but compromise of the credential collapses that distinction. Where the venue permits it, Oppen therefore prefers capital and credential isolation at the venue-account level.

This gives the architecture two complementary control mechanisms. Oppen policy provides fine-grained local authorization over each request, while venue-level account and credential separation reduce the authority retained by a credential if the Oppen enforcement path is bypassed.

The execution relationship can therefore be represented as

The agent requests an operation. The Oppen core mediates the request according to the container's policy and current state. The venue decides the final execution outcome.

At no point does this model imply that Oppen becomes the final system of record for financial positions. The venue remains authoritative for whether an order exists, whether it filled, how margin is calculated, and what account state ultimately results. Oppen maintains a local execution model in order to authorize and supervise actions, but that model must continually be compared with external venue state.

This distinction becomes central when failures occur.

03

Authority as a Capability

Traditional exchange authorization is commonly identity-centric. An API key proves that a request originates from a credential authorized to perform a class of operations. Oppen adds a second authorization layer concerned not merely with who is requesting an operation, but with which subset of financial authority has been granted to that requester.

For agent $A_i$, we represent this delegated authority using policy $P_i$. In a simplified form,

Here $\mathcal{M}_i$ represents the set of markets in which the agent may operate. $Q_i$ represents a per-order notional constraint. $N_i$ represents an aggregate exposure constraint. $L_i$ represents a leverage constraint. $R_i$ represents rate limits over execution requests. $S_i$ represents execution-price or slippage constraints. $D_i$ represents loss-related conditions capable of disabling new risk. $H_i$ represents an operator-controlled halt state.

This tuple is not intended to imply that these are the only possible policy dimensions. More generally, Oppen treats a policy as a conjunction of predicates over an action and the state relevant to its consequences.

Let $a_t$ denote an action proposed at time $t$, and let $x_t$ denote the execution state used to evaluate it. The authorization function is

where each $\phi_k$ represents one independently evaluable constraint.

The request is authorized when

The value of this formulation is that policy becomes a computational property rather than a behavioral expectation.

Consider a market constraint. If the allowed-market set is $\mathcal{M}_i$, then a proposed action satisfies the constraint only if

A request to trade any other market evaluates to false regardless of the explanation provided by the agent.

A per-order notional constraint can similarly be represented as

where $q$ is order quantity and $p_r$ is the policy-defined reference price used to estimate the order's notional value. The choice of $p_r$ is itself important. For a marketable order, a stale midpoint cannot be treated as though it were a guaranteed execution price. The venue adapter and policy specification must therefore define what price source is used for authorization and what uncertainty that approximation introduces.

Aggregate exposure requires more care because the relevant state is not necessarily the position currently reported by the venue. An account may have resting orders that have not yet filled, and Oppen may have authorized requests whose outcome has not yet been observed. If these commitments are ignored, a nominal USD 50,000 exposure limit could be exceeded by submitting several individually valid orders before the venue state reflects them.

We therefore distinguish observed exposure from outstanding commitments.

Let $E_v(x_t)$ denote exposure already reflected in venue state. Let $E_o(x_t)$ denote exposure that may arise from relevant open orders. Let $E_r(x_t)$ denote authority reserved for locally authorized concurrent operations that have not yet been resolved.

The effective commitment becomes

For a request adding potential exposure $\Delta E(a_t)$, the constraint is

For the conservative gross-notional policy described here, position exposure is the sum of absolute position quantities valued at policy reference prices across markets. Long and short positions in different markets do not offset one another. Opening buy and sell commitments are accounted for independently; opposing resting orders do not cancel each other's reserved authority. The adapter must classify any risk-reducing portion using venue-enforced order semantics and the current position. If that classification cannot be established, the request receives no reduction credit.

The three terms must be disjoint. An acknowledged order moves from local reservation into open-order commitment; a confirmed fill moves its filled quantity into position exposure while only the unfilled remainder remains committed. For example, after three units of a ten-unit opening order fill, three units belong to the position and seven remain committed. A cancellation request releases nothing until cancellation or another terminal outcome is established. A fill observed before its position snapshot must remain covered by local accounting until the snapshot incorporates it. Matching execution identifiers and a consistent reconciliation boundary prevent the same quantity from being released early or counted twice.

These rules define a conservative authorization bound rather than exact future exposure. Reference prices, freshness limits, fees and margin inputs must be specified by each adapter. Section 15 distinguishes these requirements from demonstrated implementation behavior.

This definition illustrates a general property of Oppen policy: authorization must reason about potential state transitions, not simply current account snapshots.

Let

represent a locally projected post-action state. Certain policy predicates are naturally expressed over $\hat{x}_{t+1}$. A leverage constraint, for example, may require

The projection $F$ does not imply that Oppen can predict the exact state produced by the venue. Market orders may execute at multiple prices, partially fill, or fail. Instead, the projection represents the conservative state estimate required for authorization.

This distinction is particularly important for the language used in the paper. If Oppen refuses to authorize projected leverage above $5\times$, that does not establish the invariant that venue-reported leverage can never later exceed $5\times$. Price movement, collateral changes, funding, liquidation mechanics, or execution at a different price may change leverage after authorization. Oppen can guarantee the behavior of its authorization algorithm under specified inputs; it cannot guarantee future market state.

Bounded authority should therefore be interpreted precisely as a restriction on what the Oppen signer is permitted to authorize, not as a guarantee about every future financial outcome.

04

Capital Isolation and Failure Domains

Software policy can constrain an execution path, but effective containment also depends on the authority of the underlying credential.

Suppose two autonomous agents, $A_1$ and $A_2$, operate through different local policies but share a single venue account and credential. As long as every request passes through the Oppen core, the policies can distinguish the agents. However, if the shared credential is extracted, an attacker may bypass both policy domains simultaneously.

Oppen therefore treats capital isolation as part of the authority architecture rather than merely as an accounting convenience.

Let total delegated capital be partitioned into containers

Where venue primitives permit independent accounts or equivalent isolated trading domains, Oppen aims for

This separation produces an important containment property. Under correct venue configuration and assuming the credentials associated with other containers remain uncompromised,

The statement is intentionally about authority rather than loss. Oppen cannot generally establish

under all conceivable venue and market conditions. Leveraged instruments may be subject to liquidation, fees, funding payments, oracle failures, protocol defects, and other mechanisms outside the Oppen policy layer. A compromised account-owner credential may also possess authority that supersedes the delegated trading credential.

The relevant architectural property is narrower: the trading authority intentionally assigned to one agent should not automatically include capital assigned to another.

Capital isolation also improves attribution. When positions, fills, fees, and funding from several autonomous strategies coexist in a shared account, determining which agent produced a particular economic outcome can require reconstructing the relationship between orders and strategy state. With isolated accounts, the venue itself contributes to the attribution boundary.

The cost is reduced capital efficiency. Collateral cannot necessarily be netted across agents. Opposing positions maintained by different containers do not automatically offset each other's margin requirements. Funding and withdrawal operations may become more operationally complex. More credentials must be created, protected, revoked, and recovered.

Oppen accepts these costs because they correspond to a broader systems principle: stronger isolation typically trades efficiency for a smaller and more comprehensible failure domain.

For autonomous financial software, that tradeoff is often desirable.

05

Guarded Execution

The central security-sensitive operation in Oppen is the transition from an untrusted request to a signed venue transaction.

The system is designed so that the agent never needs direct access to the signing credential associated with its container. Instead, the agent submits a structured request to the Oppen gateway. The gateway authenticates the client and resolves the request to an agent identity. The execution core then determines which container and policy govern that request.

At this stage, Oppen does not immediately ask whether the request is syntactically valid and then forward it. It must first establish sufficient execution state to evaluate the consequences of the action.

Suppose agent $A_i$ requests a BTC perpetual buy order. The relevant policy may constrain the market, maximum order size, aggregate exposure, leverage, and execution frequency. Determining whether the order is permitted may therefore require current collateral, current positions, open orders, locally outstanding reservations, market price information, and possibly previous execution events.

Let this state be $x_t$.

Once the required state is available, the request is normalized into an internal action representation $a_t$. Oppen then constructs whatever conservative post-action projection is needed by the applicable predicates and evaluates

If the result is false, no signature is produced. The refusal is recorded along with the relevant policy condition and state information required to explain the result.

If the result is true, Oppen still cannot necessarily sign immediately. The requested action may compete with another concurrent request for the same remaining authority. The core therefore reserves the relevant capacity atomically before proceeding. This issue is examined in Section 6.

After successful reservation, the authorized execution intent is written durably before the request crosses the point at which external side effects can occur. The venue-specific transaction is then constructed and signed using the credential $K_i$ associated with the container.

The principal guarded-signing invariant is

The scope of this invariant matters. It applies to signatures produced by the protected Oppen signing path. It does not imply that the underlying venue credential is cryptographically incapable of signing an action that violates $P_i$. If the credential is extracted and used outside Oppen, local policy can be bypassed.

The placement of authorization immediately before signing is deliberate.

A common but weaker architecture exposes a preflight endpoint. An agent submits an action, the system reports that the action currently appears permissible, and the agent subsequently submits it for execution. This creates a time-of-check/time-of-use problem. The state used to determine that the action was permitted may no longer be valid when the transaction is actually signed.

Suppose an account has USD 80,000 of exposure under a USD 100,000 limit. A preflight call approves an additional USD 15,000 order. Before the agent submits the order, another existing order fills and increases exposure by USD 10,000. Executing the previously approved action would now produce USD 105,000 of exposure.

For this reason, Oppen may expose policy information or advisory preflight results to help an agent plan, but those results do not constitute reusable authority.

The authorization decision that controls the signer must be evaluated against the state and reservations associated with the actual execution attempt.

06

Concurrency and Authority Reservation

Concurrency introduces one of the more subtle problems in policy-constrained execution.

Assume the maximum permitted exposure is

and current effective exposure is

Suppose two execution requests arrive nearly simultaneously. Each would independently add

units of exposure.

If both requests evaluate against the same initial state, each satisfies

A naive policy engine therefore authorizes both.

If both subsequently execute, however,

The policy has been violated even though every individual authorization returned a valid result.

This is not primarily a problem with the predicate. It is a problem with concurrency control.

Authorization consumes scarce authority. Remaining exposure capacity, rate budget, or other bounded resources cannot be treated as though they are independently available to multiple concurrent requests.

Oppen addresses this using reservations.

Let $R_t$ represent authority already reserved by authorized but unresolved operations. Effective exposure for a new authorization becomes

For an action $a_t$, reservation is permitted only if

The transition that checks this inequality and updates $R_t$ must be atomic relative to other operations competing for the same constraint.

After reservation, subsequent requests observe the reduced remaining authority immediately, without waiting for the venue to acknowledge or fill the original transaction.

The reservation persists until Oppen obtains sufficient evidence to determine what became of the corresponding execution. If the venue rejects the order, the reserved capacity can be released. If the order becomes a live resting order, the reservation is converted into open-order commitment. If the order fills, the resulting position is reflected in venue exposure. If the outcome is uncertain, the capacity must remain conservatively accounted for until reconciliation resolves it.

This mechanism has an important consequence for autonomous execution systems: the authorization state is not merely the state reported by the exchange.

It is

The second term exists because distributed systems contain intervals during which Oppen knows that it has authorized an external side effect but does not yet know how that side effect is reflected in the external system.

Any robust authority model must represent that interval explicitly.

07

Execution as an Asynchronous State Machine

Trading APIs are frequently presented as request-response interfaces. A client submits an order and receives a response indicating success or failure. This abstraction is convenient for application development, but it is insufficient as a model of financial execution.

Consider the following sequence. Oppen constructs and signs an order. The signed request is transmitted to the trading venue. The venue accepts the order and updates its internal state. Before the acknowledgement reaches Oppen, the network connection fails.

From the venue's perspective, the order exists.

From Oppen's perspective, the final result of the submission is unknown.

If Oppen maps the network failure to REJECTED, it creates false certainty. If it subsequently retries the economic action, two orders may exist. If it assumes the order succeeded without verification, it may reason about exposure that was never actually created.

The correct representation is neither success nor failure.

It is uncertainty.

Oppen therefore models each execution as a persistent state machine. An execution may pass through states conceptually corresponding to request creation, authorization, signing, submission, acknowledgement, partial fill, complete fill, cancellation request, confirmed cancellation, venue rejection, and unresolved outcome.

The transition

is particularly important.

UNKNOWN means that local evidence is insufficient to determine the canonical venue outcome. It does not mean that the venue failed to process the transaction.

Formally,

Similarly,

A cancellation is itself an externally executed operation. The original order must continue to be treated as potentially live until cancellation is confirmed or reconciliation establishes otherwise.

Partial fills require the same discipline. Suppose an order for ten units fills three units before the connection is lost. Oppen must not continue reserving all ten units indefinitely if venue evidence later confirms that only seven remain open, but it also must not release the entire reservation merely because an initial fill was observed.

The execution model therefore evolves according to evidence.

This makes execution state different from application state in a conventional user interface. It is not merely a display of what Oppen believes happened. It directly affects subsequent authorization decisions.

A position whose existence is unresolved consumes risk capacity differently from a confirmed rejection.

A cancellation request that has not been confirmed still represents potential exposure.

A submission whose acknowledgement was lost may prevent a duplicate action from being issued until reconciliation is complete.

In this sense, the state machine is part of the safety architecture.

08

Reconciliation

Because Oppen does not control the trading venue, its local execution model can become temporarily inconsistent with external state. Reconciliation is the process through which those differences are detected and resolved.

Let $L_t$ denote Oppen's locally reconstructed financial execution state at time $t$, and let $V_t$ denote the venue state observable at approximately the same time.

Neither object is necessarily a single value. Each may contain positions, open orders, fills, collateral information, order identifiers, execution statuses, and venue-specific metadata.

We can define a conceptual discrepancy function

that describes differences between the locally expected state and the externally observed state.

Under normal steady-state operation, Oppen seeks

for every venue-observable dimension represented by the local model.

A nonzero discrepancy does not always indicate a defect. Temporary disagreement is expected in asynchronous systems. An acknowledgement may arrive before an account-state stream reflects the change. A fill event and a position update may arrive through different channels. Venue indexing systems may expose slightly different update latencies.

The reconciliation mechanism must therefore understand venue semantics rather than merely compare snapshots byte-for-byte.

The more important property is that persistent or materially ambiguous disagreement is not silently ignored.

Suppose Oppen has a submitted order in UNKNOWN state. During reconciliation, the venue reports a live order with the corresponding client identifier. The local execution can then transition to an acknowledged/open state.

If the venue instead reports the order as filled, the corresponding fill and resulting position can be incorporated.

If no evidence of the order exists, Oppen may require additional checks before concluding that the submission failed, depending on venue guarantees around historical order visibility.

Reconciliation also matters following process restart.

Oppen cannot safely assume that the last local event written before termination represents the last external event that occurred. If the process terminated after transmitting a transaction, the venue may have continued executing while the local process was unavailable.

Restart therefore requires reconstruction from durable local intent followed by comparison with venue state.

For risk-increasing actions, uncertainty may require the system to fail closed. If the account state required to determine available authority cannot be established with sufficient confidence, the safer authorization result is

This yields the intended property

The system may still permit actions that clearly reduce risk, depending on venue semantics and policy configuration. However, such exceptions must be designed explicitly. A simplistic assumption that every reduce-only request necessarily reduces all relevant forms of risk would itself require verification.

The purpose of reconciliation is therefore not simply bookkeeping. It is to restore the state assumptions on which authorization depends.

09

Execution Provenance and the Local Event Ledger

Autonomous systems create an additional observability problem. A human trader can often explain why an action was taken because the decision and execution process occurred within the same human workflow. An autonomous agent may produce a natural-language explanation, but that explanation is not a reliable execution record.

The model may omit events, reconstruct them incorrectly, or generate an explanation after the fact using incomplete context. Moreover, an execution can continue evolving at the venue after the agent has finished reasoning about it.

Oppen therefore separates narrative explanation from execution provenance.

Every material step in the guarded execution process is represented as a durable event. Such events may correspond to an agent request, policy evaluation, authorization refusal, capacity reservation, signature production, submission, venue acknowledgement, fill, cancellation, reconciliation result, policy modification, revocation, or operator halt.

Let event $e_i$ be represented by

where $h_{i-1}$ is the hash of the preceding event.

Oppen can compute

creating a sequential hash chain.

This mechanism provides tamper evidence under the assumption that the verifier and relevant integrity state have not also been compromised. An alteration to an earlier event changes all subsequent hashes and can therefore be detected when the chain is verified against a trusted checkpoint.

It is important not to overstate this property.

A local hash chain is not an independently immutable ledger.

If an attacker fully compromises the host, modifies the historical records, and reconstructs all later hashes, the resulting local chain may be internally consistent. Oppen therefore does not equate local hash chaining with blockchain consensus, remote notarization, or hardware-backed attestation.

The useful property is more modest: ordinary corruption and inconsistent historical modification become detectable, the causal relationship between execution steps can be reconstructed, and externally observable events can be compared against venue state.

This record allows an operator to distinguish questions that are frequently collapsed into one another:

What did the agent request?

What did Oppen permit?

What did Oppen sign?

What did Oppen submit?

What did the venue report?

What ultimately filled?

Those are not equivalent facts.

A technically useful execution system must preserve the distinction.

10

Credential Architecture and Local-First Execution

The authority model described above depends ultimately on control of the signing credential.

Let $K_O$ denote the account-owner credential and $K_i$ denote a delegated trading credential associated with agent container $C_i$.

Oppen's intended design keeps $K_O$ outside the Oppen execution environment. Owner-level authority should remain with the operator's wallet or equivalent external custody mechanism.

This gives

The delegated trading credential $K_i$, by contrast, must be available to the Oppen signer if the system is to execute transactions autonomously. The intended relationship is

while

The agent therefore receives the ability to request signatures under defined conditions without receiving the key itself.

This is the core capability separation.

The operator delegates a venue credential to Oppen. Oppen delegates a constrained execution interface to the agent.

The resulting authority chain can be expressed as

The direction of administrative control is opposite the direction of execution requests.

The agent can request an action upward through the capability boundary, but it cannot use the intended interface to rewrite the policy that defines the boundary.

Local-first architecture is important here because it determines who must be trusted with the delegated credential. In Oppen's model, the credential and enforcement system execute on infrastructure controlled by the operator rather than requiring an Oppen-operated remote signing service.

This reduces Oppen's custody role but does not eliminate trust assumptions.

A compromised local machine can still compromise local credentials.

A malicious process running with sufficient operating-system permissions may be able to access memory, credential storage, IPC mechanisms, or application files outside the intended agent interface.

For this reason, the statement

must be interpreted at the Oppen application interface, not as a universal guarantee against a process with arbitrary host access.

Where stronger isolation is required, the agent process and Oppen signer should execute in security domains appropriate to the threat model, such as separate operating-system users, containers with appropriate hardening, virtual machines, dedicated machines, hardware-backed signing environments, or future threshold-signing architectures.

MCP itself does not provide this isolation.

It is an interface protocol with a host-client-server architecture.

The operating environment remains part of the security model.

11

Security Properties and Limits

The value of a technical security architecture depends on stating both the properties it intends to establish and the assumptions under which those properties hold.

The first and most important Oppen property is guarded signing. For every transaction signed through the protected Oppen signer,

This property requires correct policy implementation, correct state acquisition, correct venue transaction construction, correct concurrency handling, and uncompromised execution software. It does not survive arbitrary modification of the trusted computing base.

The second property is policy non-escalation. An agent interacting through the intended execution interface must not be able to modify the authority policy governing itself. If $P_i$ is the policy associated with $A_i$,

Increasing authority is therefore an administrative operation controlled by the operator rather than an execution operation controlled by the agent.

The third property is credential non-disclosure through the application interface. Oppen exposes operations that use $K_i$ to sign authorized transactions but does not expose an operation that returns $K_i$ to the requesting agent.

This resembles a capability-oriented signing service: possession of access to the service is not equivalent to possession of the underlying signing secret.

The fourth property is isolation between agent capital domains. Assuming independent venue accounts or credentials and no compromise of common administrative authority,

for $i\neq j$.

The fifth property is fail-closed authorization for unavailable state. If Oppen cannot establish the state required to determine whether a risk-increasing transaction satisfies policy, the transaction should not be authorized merely because no explicit violation has been observed.

Absence of evidence is not evidence of available authority.

These properties should not be interpreted as a claim that Oppen makes autonomous trading safe.

Consider an agent whose policy permits USD 50,000 of BTC exposure. The agent may continuously buy at unfavorable prices, repeatedly cross the spread, maintain a losing position, or adopt a fundamentally flawed strategy while remaining perfectly compliant with the policy. Every Oppen security property could hold while the strategy loses its entire assigned capital.

This is not a contradiction.

The system distinguishes between

and

Oppen concerns itself primarily with the former.

12

Threat Model

The threat model begins with the autonomous agent itself. Oppen assumes that an agent may generate malformed, repetitive, economically harmful, or intentionally adversarial requests. Such behavior may arise from ordinary software defects, incorrect reasoning, prompt injection, model instability, or compromise of the agent process.

The architecture attempts to constrain this class of failure through typed execution requests, identity scoping, deterministic policy evaluation, rate limits, exposure limits, and signing-time enforcement. These mechanisms do not guarantee that a malicious agent cannot cause financial harm. They guarantee only that requests exceeding the configured predicates should not receive a signature through the guarded path.

Prompt injection deserves particular attention because it illustrates the distinction between reasoning security and authority security. An agent may ingest an external document containing instructions designed to manipulate its behavior. If the injection succeeds, the resulting agent state may be treated as compromised. Oppen does not need to determine which tokens in the model's context caused the behavior. It receives the resulting execution request and subjects it to the same authority boundary as every other request.

A second threat class is communication failure. Oppen depends on network communication with external venues. Requests may be delayed, responses may be lost, connections may disconnect, and market/account streams may become stale. These failures are addressed through explicit execution states and reconciliation rather than assumptions of synchronous delivery.

A third threat class is credential extraction. If an attacker obtains $K_i$, the attacker may be able to interact with the venue directly. Because Oppen policy is enforced locally rather than cryptographically embedded in the venue credential, this bypasses the policy engine.

Accordingly,

Capital isolation and venue-native credential restrictions therefore remain important even when Oppen itself functions correctly.

A fourth threat class is full host compromise. If an attacker gains sufficient control over the operating system hosting Oppen, the assumptions underlying local policy, credential secrecy, event-ledger integrity, and agent isolation may all fail simultaneously.

Oppen does not claim Byzantine security against its own fully compromised host.

A fifth threat class is venue failure or malicious venue behavior. The trading venue determines the actual order book, margin system, liquidation engine, and account state. Oppen may detect inconsistencies relative to its expectations, but it cannot independently force the venue to execute correctly. Venue-specific cryptographic or on-chain guarantees remain properties of the venue itself rather than Oppen.

This distinction is particularly relevant when integrating systems with different trust models. Oppen may connect to a centralized exchange, an application-specific blockchain, or a provable rollup. The guarantees of those systems differ substantially. Oppen's authority layer should therefore be understood as complementary to venue security rather than as a replacement for it.

13

Failure Semantics

A robust execution architecture must specify how it behaves when components fail, not merely how it behaves during successful execution.

One important failure occurs when a transaction is accepted by the venue but the acknowledgement is lost. As described previously, the system must preserve an unresolved state rather than retrying blindly.

Another occurs when Oppen loses connectivity while an order remains live. Local policy may prevent the creation of new risk while disconnected, but it cannot stop the market from moving against an existing position. Nor can it guarantee that a cancellation request will reach the venue.

A local halt must therefore not be confused with a venue-level guarantee.

Setting

can ensure that Oppen refuses further risk-increasing signing operations. It does not itself imply

or

Those outcomes require successful external actions.

Application crashes create a similar distinction. If Oppen terminates after recording authorization but before signing, recovery behavior differs from termination after signing but before transmission, or after transmission but before acknowledgement.

These transitions need to be distinguishable in the durable ledger.

The recovery procedure must reconstruct local execution history, determine which transactions may have crossed an external side-effect boundary, query the venue for the latest recoverable evidence, and restore reservations accordingly.

A system that simply reloads the latest position snapshot loses important causality. It may discover that an account has a position but be unable to determine which locally authorized action created it or whether another unresolved transaction remains outstanding.

For autonomous execution, causal provenance is necessary because future policy decisions depend on the relationship between local intent and external outcome.

14

Evaluation Methodology

A technical authority system should be evaluated according to properties that can be falsified experimentally.

The first class of tests concerns policy correctness. For each policy predicate, Oppen can generate actions around the exact authorization boundary and verify that no action outside the permitted domain reaches the signer. Randomized and property-based testing are especially appropriate because many failures occur at combinations of state rather than at individual input values.

For a test corpus $\mathcal{T}$, one useful metric is the false-allow rate

For authority enforcement, the desired value is

False denials also matter operationally, although their security implications differ. Excessively conservative authorization can render the system unusable without violating the safety boundary.

Concurrency requires a separate class of tests. Multiple execution requests should be issued simultaneously against shared constraints such as exposure capacity. The test should verify that the set of actions obtaining reservations cannot collectively exceed the configured authority even when each request observes similar underlying venue state.

Failure-injection testing is equally important. The process should be terminated deliberately at different stages of execution: before authorization persistence, after authorization, after signing, during submission, after venue acceptance, and during cancellation. Following restart, the system should reconcile to the externally observable venue state without creating unexplained duplicate risk.

Network fault injection should simulate dropped acknowledgements, delayed websocket updates, reordered events, temporary partition, and stale market/account state. The intended behavior is not always continued execution. In many cases the correct behavior is refusal to create new risk until sufficient state confidence has been restored.

Revocation should also be measured empirically. Let $t_r$ be the time at which the core accepts an authenticated operator revocation request, and let $t_e$ be the time at which that revocation becomes effective at the signing boundary, including requests already in flight. Using the same monotonic clock for both events, define

The effective event must represent an enforced barrier: no signature for the revoked authority may be produced after it. Tests should continue concurrent requests across that barrier and report any post-barrier signatures as failures, separately from latency. If the barrier is never reached, the trial is a failure or timeout, not a zero-latency result. This definition remains meaningful when no request succeeds after revocation is requested.

Local revocation stops new Oppen signatures. It cannot retract an already produced signature, cancel an accepted order, or flatten a position by itself. Previously signed but unsubmitted actions require explicit handling, and venue-level credential revocation is a separate operation.

Performance evaluation should separate Oppen overhead from venue latency. Policy evaluation, reservation, persistence, transaction construction, and signing all add local execution time. These components should eventually be benchmarked independently at multiple percentiles rather than represented by a single average.

No numerical performance claims should be included until the assembled implementation has been benchmarked under reproducible conditions.

15

Implementation Scope and Evidence

As of 8 September 2026, Oppen remains pre-alpha. Version 1.0 identifies this document, not a production software release. Statements of invariants and execution behavior in this paper describe the architecture's requirements under the stated assumptions; they are not claims that every requirement has passed assembled venue acceptance.

The initial implementation targets perpetual futures on Hyperliquid. Signing, policy enforcement, durable execution records, reconciliation and portions of the operator console exist in source. The current development roadmap records local regressions for guarded execution, concurrent commitments, partial fills, cancellation failures and restart recovery. It also records local activation tests. Those checks establish evidence within their tested environments, including mocks and loopback transport; they do not establish successful activation or execution against the real venue.

Operator activation remains unaccepted, with aggregate review and remaining race proofs pending. Real testnet identity/activity authorization and the authorized venue run remain open gates. No numerical performance results or completed live-execution acceptance are claimed here. The public Status page provides release context; the development roadmap records implementation checkpoints and remaining gates.

15.1Hyperliquid adapter requirements

Hyperliquid API wallets can sign for their approving account and its subaccounts. Separate local policies therefore do not narrow a shared key's venue authority. Oppen's intended isolation uses a dedicated venue account and delegated key per agent; account binding must be checked independently of caller-supplied fields.

Nonces belong to the signer, including when that signer serves multiple subaccounts. Allocation must coordinate all uses of that key. Hyperliquid also warns that pruning an API wallet's nonce state can make old signed actions replayable, so rotation should generate a fresh wallet address.

The exchange supports client order identifiers and order time-in-force semantics. Oppen must persist identifiers, nonce and intent before submission, correlate responses and fills, and reconcile an uncertain result before issuing a fresh economic action. A client identifier alone is not proof of exactly-once execution. These are adapter acceptance requirements, not additional venue guarantees.

15.2Scope beyond the first venue

The implementation is intentionally narrower than the general architecture presented in this paper.

A multi-venue authority system introduces additional problems. A portfolio constraint may span positions held on multiple exchanges with different update latencies. A position opened on one venue may hedge exposure on another, causing a local per-venue risk model to overstate or understate economic exposure. Credential models differ, and a policy meaningful on one venue may not map exactly to another.

For that reason, Oppen does not treat venue adapters as interchangeable transport modules.

Each integration must define its own execution semantics and demonstrate that the assumptions required by the Oppen policy layer remain valid.

The same principle applies to agent interfaces. MCP is the initial integration mechanism because it provides a standardized tool interface suitable for autonomous clients. The architecture itself does not depend on MCP. Future clients may use different local or remote protocols while preserving the same separation between authentication, authorization, and signing.

16

Limitations

Oppen's authority model has several important limitations.

First, Oppen does not verify the correctness of an agent's reasoning. If a policy permits an action, Oppen may authorize that action even when the underlying economic reasoning is poor.

Second, the policy engine can only evaluate constraints expressible from the state available to it. If external risk depends on information not represented in $x_t$, the authorization decision does not account for that risk.

Third, local policy enforcement can be bypassed if the underlying delegated signing credential is extracted and the venue accepts direct use of that credential.

Fourth, full compromise of the Oppen host invalidates many local security assumptions. A hostile host may access credentials, alter policy code, tamper with records, intercept operator actions, or impersonate agents.

Fifth, policy limits are not equivalent to economic loss guarantees. An exposure limit constrains authorized exposure according to the policy's measurement methodology. It does not guarantee maximum realized loss.

Sixth, Oppen depends on external venues for canonical execution. Venue outages, protocol failures, oracle defects, liquidation behavior, or other venue-level risks remain outside the principal Oppen enforcement boundary.

Seventh, local-first execution shifts operational responsibility toward the operator. Device security, backups, credential recovery, runtime isolation, and system availability become important parts of the deployment model.

These limitations are not secondary disclaimers. They define the boundary within which the security properties described in this paper should be interpreted.

17

Future Work

Several extensions follow naturally from the architecture.

One direction is stronger credential isolation. Hardware-backed signing could reduce exposure of delegated keys to the general-purpose host environment. Threshold-signature schemes could separate execution authority across multiple processes or devices, requiring policy approval and cryptographic participation from distinct components before a valid venue transaction can be produced.

A second direction is formal verification of the policy engine. Because the principal guarded-signing property is naturally stated as an invariant, portions of the authorization logic may be suitable for model checking, property verification, or mechanically checked specifications.

A third direction is venue-independent policy representation. A sufficiently general authority language would allow an operator to define constraints semantically while venue adapters translate those constraints into conservative venue-specific execution rules. Achieving this without masking important differences in exchange semantics is nontrivial and requires further research.

A fourth direction is portfolio-level authority. The current container model naturally isolates agents, but sophisticated operators may wish to delegate capital across multiple cooperating agents while enforcing aggregate portfolio constraints. Such a system requires coordination between otherwise independent execution domains and introduces distributed reservation problems.

A fifth direction is remote and distributed execution. Local-first execution minimizes reliance on Oppen-operated infrastructure, but some operators may require always-on execution nodes. A future architecture could allow remotely deployed Oppen nodes while preserving operator-controlled credentials and verifiable policy configuration.

A sixth direction is richer provenance. Local hash chaining provides tamper evidence but not independent immutability. Remote checkpointing, hardware-backed attestations, or cryptographically committed execution receipts could provide stronger guarantees without requiring that Oppen itself custody user funds.

These directions preserve the same underlying principle: increasingly capable autonomous software should not require correspondingly unrestricted financial authority.

18

Conclusion

Autonomous agents change the abstraction through which software interacts with financial systems.

A deterministic trading program can often be secured by constraining the code itself. A general autonomous agent is different. Its behavior may emerge from model reasoning, external information, dynamic tool selection, changing context, and interactions with other software. Attempting to make the entire reasoning process itself the authority boundary therefore creates a fragile dependency between what the system decides and what it is allowed to do.

Oppen separates these concerns.

An autonomous agent may determine that it wishes to trade. It may choose the market, side, timing, execution method, and strategy according to whatever reasoning architecture produced the request. But the request does not become a financial action merely because the agent has decided upon it.

The action must cross an independent authority boundary.

That boundary observes the agent's assigned policy, the relevant financial state, outstanding commitments, concurrency reservations, and operator controls. Only after the action satisfies those constraints may the protected signer convert it into a venue transaction.

The resulting relationship can be summarized as

The architecture does not require agents to be trusted with unrestricted credentials. It does not require Oppen to determine whether their strategies are profitable. And it does not assume that distributed financial execution behaves like a synchronous API call.

Instead, it treats authority as an explicit computational object and execution as a fault-prone asynchronous process whose intermediate states matter.

The broader implication extends beyond trading.

As autonomous software gains the ability to act on economically consequential systems, the question of what an agent can reason about becomes increasingly separate from the question of what an agent can cause to happen.

Oppen is an attempt to provide that separation for financial markets.

Intelligence proposes. Authority constrains. Execution commits.