How the AutoHedge Execution Agent Generates and Executes Trades on Solana

The Execution Agent converts risk-adjusted trading theses into signed blockchain transactions by formatting structured orders via LLM prompts, retrieving unsigned swaps from Jupiter Ultra, and broadcasting them to Solana using wallet-based signing.

The Execution Agent serves as the final stage in AutoHedge’s multi-agent pipeline, transforming high-level trading recommendations into concrete on-chain actions. As implemented in The-Swarm-Corporation/AutoHedge, this agent orchestrates the journey from quantitative analysis to live execution on the Solana blockchain through a series of specialized tool calls and API integrations.

Agent Orchestration and Prompt Engineering

All agents in the AutoHedge system are instantiated in autohedge/workers.py. The execution_agent is created using the EXECUTION_PROMPT defined in autohedge/prompts.py, which instructs the LLM to output a structured trade request containing specific parameters required for on-chain execution.

The agent configuration uses GPT-4.1 with a single inference loop to prevent recursive reasoning:

from swarms import Agent

execution_agent = Agent(
    agent_name="Execution-Agent",
    system_prompt=EXECUTION_PROMPT.strip() + _SYSTEM_SUFFIX,
    model_name="gpt-4.1",
    output_type="str",
    max_loops=1,
    verbose=True,
    context_length=16000,
)

The system prompt mandates that the LLM format orders with the following components:

• Order type (market or limit)
• Quantity and entry price
• Stop-loss and take-profit levels
• Time-in-force parameters

Generating Unsigned Transactions via Jupiter Ultra

Once the Execution Agent produces the structured order text, the orchestration logic in autohedge/main.py (specifically within the AutoHedge.run method) parses this output and initiates transaction creation. The system calls get_order from autohedge/tools/ultra_tools.py to interact with the Jupiter Ultra API.

This function constructs a swap request without blockchain signing:

from autohedge.tools.ultra_tools import get_order

# Request unsigned swap: SOL → USDC

unsigned = get_order(
    input_mint="So11111111111111111111111111111111111111112",   # SOL

    output_mint="EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",  # USDC

    amount="10000000"                                           # 0.01 SOL in lamports

)

The get_order function POSTs to https://api.jup.ag/ultra/v1/order and returns a JSON payload containing:

• An unsigned, base64-encoded transaction
• A unique requestId for tracking

Signing and Broadcasting Trades

The unsigned transaction requires cryptographic signing before submission to the Solana network. The execute_trade function in autohedge/tools/ultra_tools.py handles this final step by retrieving the private key from the SOLANA_PRIVATE_KEY environment variable.

After signing locally, the function transmits the fully signed transaction to Jupiter Ultra’s /execute endpoint:

from autohedge.tools.ultra_tools import execute_trade

result = execute_trade(
    unsigned_transaction=unsigned["transaction"],
    request_id=unsigned["requestId"]
)

The response includes critical confirmation data such as the transaction signature, slot number, and error status codes, enabling verification of successful on-chain settlement.

Tool Registration and Framework Integration

To make these utilities accessible to the agent framework, both get_order and execute_trade are registered in autohedge/tools/tools_registry.py. This registration allows the Execution Agent—or any downstream orchestration code—to invoke these functions as abstracted tool calls rather than direct API implementations.

According to the AutoHedge source code, this modular architecture separates blockchain-specific logic from agent reasoning, enabling the Execution Agent to focus on order structuring while the tools handle protocol-level Solana interactions.

Practical Implementation Example

The following example demonstrates the complete flow from manual order generation to execution:

from autohedge.tools.ultra_tools import get_order, execute_trade

# Step 1: Generate unsigned swap transaction

order_info = get_order(
    input_mint="So11111111111111111111111111111111111111112",
    output_mint="EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
    amount="5000000"  # 0.005 SOL in lamports

)

# Step 2: Sign and broadcast to Solana

execution_result = execute_trade(
    unsigned_transaction=order_info["transaction"],
    request_id=order_info["requestId"]
)

print(f"Transaction signature: {execution_result.get('signature')}")
print(f"Execution response: {execution_result}")

For autonomous operation, instantiate the full AutoHedge pipeline:

from autohedge.main import AutoHedge

auto = AutoHedge()
logs = auto.run(
    task="Analyze AAPL and generate a trade if the thesis is positive."
)
print(logs)

Summary

• Agent Configuration: The Execution Agent in workers.py uses EXECUTION_PROMPT from prompts.py to mandate structured order formatting via GPT-4.1.
• Transaction Creation: The get_order function in ultra_tools.py interfaces with Jupiter Ultra to generate unsigned base64-encoded transactions.
• Cryptographic Signing: The execute_trade function signs transactions using the SOLANA_PRIVATE_KEY environment variable and broadcasts to Solana.
• Modular Architecture: tools_registry.py abstracts blockchain operations, allowing the Execution Agent to focus on high-level order logic while tools handle low-level Solana protocol interactions.

Frequently Asked Questions

What LLM model powers the Execution Agent?

The Execution Agent utilizes GPT-4.1 with a context window of 16,000 tokens and max_loops=1, ensuring deterministic, single-pass order generation without recursive self-prompting.

How does the Execution Agent interact with the Jupiter Ultra API?

The agent indirectly interacts through two specialized functions: get_order retrieves an unsigned transaction from https://api.jup.ag/ultra/v1/order, while execute_trade submits the signed transaction to the /execute endpoint for final broadcast to the Solana network.

What environment variable is required for transaction signing?

The system requires SOLANA_PRIVATE_KEY to be set in the environment. This private key is loaded within execute_trade to sign the unsigned transaction bytes before on-chain submission.

Can the Execution Agent handle limit orders or only market orders?

According to the EXECUTION_PROMPT specifications in prompts.py, the agent is designed to output both market and limit order types, along with stop-loss and take-profit levels, though the specific execution path depends on the Jupiter Ultra API’s support for the requested order type.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}