Solana Execution Layer

Onchain settlement, wallet topology, and transaction control.

Solana Execution Layer

AgentWorld uses Solana as its execution and settlement substrate.

This does not mean every business action belongs onchain. It means high-value finality belongs onchain. Reasoning, planning, and most data enrichment should stay offchain. Settlement, treasury intent, policy-bound signatures, and certain proofs should use Solana.

What belongs offchain and onchain

Offchain

• planning and reasoning

• document generation

• external API reads

• state aggregation

• long-running workflows

• analytics and ranking

Onchain

The split matters because cost, latency, and reversibility are different on each side.

Wallet and policy topology

A business-grade agent system should not expose one hot wallet to one model.

A safer topology looks like this:

Treasury vault
   |
   +--> policy engine
           |
           +--> execution signer
                    |
                    +--> Solana transaction submit

The treasury vault holds authority. The policy engine decides whether a proposed action is valid. The execution signer performs only pre-approved actions within scoped rules.

Transaction lifecycle

A Solana action should pass through a strict pipeline.

1. Create a transaction intent.

2. Validate the intent against policy.

3. Simulate the transaction.

4. Confirm destination, amount, and account state.

5. Collect required approvals.

6. Sign with the scoped execution authority.

7. Submit and await confirmation.

8. Reconcile the confirmed result back into business state.

The critical property is that intent exists before signature.

Example intent object

{
  "intent_id": "intent_01",
  "business_unit": "ops",
  "action": "vendor_payout",
  "asset": "USDC",
  "amount": "1250.00",
  "destination": "approved_vendor_wallet",
  "approval_policy": "finance-tier-2",
  "reason": "invoice INV-2031"
}

An agent can propose this object. It should not unilaterally sign and submit it.

Idempotency and replay

Onchain submission must be idempotent from the business perspective.

A retried workflow must not duplicate a payout because the control plane lost an acknowledgment. Every transaction intent should have a stable business identifier and a clear final state:

• proposed

• approved

• signed

• submitted

• confirmed

• failed

• reconciled

Why Solana is a strong fit

Solana is useful here for three reasons.

First, confirmation is fast enough for business flows that feel interactive. Second, fees are low enough to record more events without turning every settlement into an expensive exception. Third, the ecosystem is composable enough to plug treasury, payments, and asset actions into the same runtime.

Program-facing posture

AgentWorld should be conservative with direct program access.

The safe default is to expose narrow execution adapters that prepare known transaction shapes, validate accounts, and attach policy metadata. This keeps the model away from raw unchecked authority.

Reconciliation

A confirmed transaction is not the end of the workflow.

The system should write a reconciliation event that links:

• business intent

• workflow ID

• agent run ID

• transaction signature

• final amount

• final recipient

• confirmation slot

This gives operators a clean chain from reasoning to money movement.

Never treat a model decision as equivalent to signing authority. Signing is a separate trust domain.