Overview

This chapter follows AutoHedge’s Jupiter Ultra path from mint-and-amount inputs to an unsigned transaction, local signing, and a venue response. It separates recommendation, transaction material, signed authorization, and settlement, showing that the low-level functions reject malformed representations but do not visibly enforce policy, link model output to the order, or reconcile holdings.

Learning outcomes

AutoHedge’s `get_order` prepares unsigned transaction material; `execute_trade` decodes, signs, and submits it when required inputs and credentials are available.
Parsing and signing prove transaction representation and wallet authorization, not that the assets, amount, route, or policy match the intended trade.
A venue response is not necessarily settlement; the visible code does not show durable linkage, retry decisions, or holdings reconciliation.

Keywords

AutoHedgeSolanaJupitertransactionsigningsettlement

When a Recommendation Becomes a Transaction

AutoHedge's most consequential code is not a prompt but the Solana execution surface behind its trading ambition. This chapter traces what happens when that surface receives the inputs it expects: how an order request becomes unsigned transaction material, how a local wallet key signs it, and how the signed result is sent to the venue. The goal is to identify where authority changes hands and where the repository still does not show a safe connection from a model-generated recommendation to a state-changing action.

From an order request to a venue response

Four objects must be kept separate. An order recommendation is a statement about what someone or something believes should happen: an asset, a direction, an amount, and perhaps prices or limits. An unsigned transaction is different. It is transaction material prepared for a venue but not yet authorized by the wallet's signature. A signed transaction carries the authority of the key that signed it. A venue response is different again: it reports what the external service accepted, rejected, or otherwise returned. Treating those four stages as one “trade” hides the points at which a system can inspect, refuse, or lose control.

AutoHedge's Jupiter Ultra functions make those stages visible. The first function, get_order, expects an input mint, an output mint, and an amount. It checks that each value is present and nonempty. It then loads the wallet keypair from the environment, derives the wallet's public key, and sends a request to Jupiter's /ultra/v1/order endpoint. The same derived public key is supplied as the taker, receiver, and payer. The response is returned as JSON text and is documented as containing, among other values, an unsigned base64 transaction and a request identifier.

That function does not sign anything. Its result is a proposal prepared by an external route service, accompanied by material that a later function can use. The separation is important: an order response can be inspected before a private key is used. It can also be rejected if the asset, amount, route, or other terms do not satisfy an application's policy. In the visible AutoHedge code, get_order performs basic nonempty-input checks, but it does not receive a thesis or risk assessment and does not expose a local policy layer around the response.

The second function, execute_trade, crosses the authority boundary. It requires an unsigned transaction and a request ID. It first checks that both strings are present. It base64-decodes the transaction, parses the resulting bytes as a Solana VersionedTransaction, converts the transaction's message into versioned bytes, and signs that message with the locally loaded keypair. It then constructs a signed transaction, encodes it as base64, and sends the signed value and request ID to Jupiter's /ultra/v1/execute endpoint. The returned response is again serialized as JSON text.

The sequence is a lifecycle, not a single API call. Before get_order, the application must already have chosen the asset identifiers and amount. Between get_order and execute_trade, it has an opportunity to inspect the unsigned material. During execute_trade, the keypair turns a prepared message into an authorized transaction. After the HTTP request, the application has a venue response, but the local function does not itself establish the external settlement semantics or reconcile the response with a durable portfolio state. A separate get_holdings function can retrieve wallet balances, but the repository does not show it being used to close that loop.

Published by DeepMox

FAQ

What happens between `get_order` and `execute_trade` in AutoHedge?

The caller receives unsigned base64 transaction material and a request ID, which can be inspected before `execute_trade` decodes and signs the message.

What does AutoHedge’s local signing actually prove?

It proves that the locally loaded key signed the parsed versioned message; it does not prove that the transaction exchanges intended assets, remains timely, or satisfies policy.

Is an AutoHedge venue response the same as a settled position?

No. The response reports what the external endpoint returned, while settlement and agreement with wallet holdings require application-level interpretation and reconciliation that the repository does not show.

Previous11 minAutoHedge: Design, Not a Guarantee

Next11 minAutoHedge: Risk Controls Before Signing

AutoHedge: From Order to Signed Transaction

When a Recommendation Becomes a Transaction

From an order request to a venue response

FAQ