Geodesics Technical Paper

Important information#

This paper explains the Geodesics product, its current integration model and the role of GEO within the platform. Geodesics publishes it for agent builders, wallet operators, developers and technical partners.

Geodesics publishes this document as a technical and product description. It is not a crypto-asset white paper prepared, notified or published under MiCAR, a prospectus, an investment document or an offer to acquire GEO or another asset.

Product behavior depends on the software, supported routes, connected networks and third-party infrastructure available when a user requests a swap. The live documentation and transaction details presented before signing control where they differ from this paper.

Typical timing and performance figures are observations, not service-level guarantees. Digital asset transactions can fail, settle late or lose value.

This paper does not provide financial, investment, legal or tax advice.

1. Executive summary#

Geodesics gives software agents one integration for same-chain and cross-chain swaps across EVM networks and Solana. An agent requests a quote, signs the resulting operation with its own signer and receives the output in a wallet it controls.

The product removes several tasks that make multi-network execution difficult for autonomous software. Independent infrastructure supplies route and quote data. Geodesics presents that data, constructs the exact operation for signing, forwards the final user-signed package to independent execution infrastructure and reports transaction status through a consistent interface. An agent does not need to maintain separate swap logic for every network or manually assemble bridge and venue steps.

The documented execution loop is:

quote -> build -> sign -> forward -> verify

Geodesics exposes this loop through an agent skill, a command-line interface, a TypeScript SDK and a REST API. The higher-level interfaces support chain activation, retries and status handling. The REST API leaves those choices to the integrator.

Geodesics is non-custodial. Users and agent operators control the wallets and signing policies used for each swap. Geodesics never receives or stores a signer private key or a wallet-admin key capable of signing user transactions.

Geodesics constructs the exact operation from the agent's requested parameters and the route supplied by independent routing infrastructure. The user reviews and signs the operation locally. The client returns the signature or signed transaction to the Geodesics API. Geodesics assembles the final package without changing the signed parameters. For EVM flows, Geodesics forwards that package to independent execution infrastructure and the independent solver broadcasts the blockchain transaction. For Solana-origin flows, Geodesics submits the user-signed transaction to the Solana network unchanged. Output assets settle to the address selected by the user.

GEO is the optional utility token connected to Geodesics. The GEO Token Disclosure contains the token's supply, distribution, launch mechanics, holder rights and risks.

2. The problem#

An agent that holds a token on one network may need another token on a different network. Completing that instruction can require several systems: a quote source, an exchange, a bridge or messaging layer, native gas on one or more chains, token approvals, wallet-specific signing and a way to track settlement.

Human-facing swap applications hide part of this complexity behind buttons and wallet prompts. Autonomous agents need an interface they can call as code. They also need structured errors, safe retry behavior and a result they can verify without a person watching each step.

Four constraints shape the Geodesics design:

1. Fragmented liquidity. Assets and venues sit across different chains. The useful route can change with liquidity, price, network conditions and provider availability.
2. Chain-specific execution. EVM networks and Solana use different transaction and signing models. Even EVM networks differ in token addresses, canonical stablecoins and available routes.
3. Gas management. A wallet can hold sufficient value for a swap while lacking the native token required to execute it.
4. Agent reliability. Automated systems must distinguish between an error that requires a new route, a one-time activation, a larger amount or a safe retry.

Geodesics turns those constraints into one swap interface and one status model.

3. What Geodesics provides#

Geodesics provides non-custodial software for obtaining swap quotes and preparing user-authorized same-chain and cross-chain transactions. Independent infrastructure supplies route and quote data. Geodesics presents that data, constructs the operation for signing, receives and forwards the user-signed package to independent execution infrastructure and reports observed transaction status.

The product supports:

• route and quote data from supported networks and connected providers
• EVM and Solana transaction construction
• forwarding of EVM user-signed packages to independent execution infrastructure and unchanged submission of Solana user-signed transactions
• gas recovery from the input amount for supported EVM flows
• one-time EVM wallet activation and destination onboarding through higher-level integrations
• user-controlled signing
• idempotency protection, identical-package retries and settlement-status reporting
• structured errors for automated recovery
• transaction references for onchain verification.

Geodesics does not take ownership of the assets involved in a swap. For EVM flows, the independent solver broadcasts the transaction authorized by the user. For Solana-origin flows, Geodesics submits the user-signed transaction to the network unchanged. Assets then move through smart contracts, exchanges, bridges, relayers or other route components. Those components remain independent third-party systems.

Route availability is dynamic. A supported chain does not guarantee a route for every token pair or transaction size.

4. Swap lifecycle#

4.1 Quote#

The agent supplies the origin network, destination network, input token, output token, amount and wallet information. Independent infrastructure generates route and quote data from those parameters. Geodesics returns the expected output, fee information, expiry time and a sealed quote token.

The quote is information for the user to review. No transaction operation has been authorized or forwarded at this stage.

Quotes expire after 30 seconds under the current API. A fresh quote reflects current prices, liquidity and route conditions. Integrators should not cache an old quote for later execution.

The sealed quote token carries route context to the build step. The API rejects a modified token or a token sent to the wrong endpoint.

4.2 Build#

For an EVM-origin swap, Geodesics turns the quote into an exact operation, a 32-byte GeoOp hash and a second sealed token. The hash binds the route, amounts, fees, destination, calldata and expiry that the wallet will authorize.

For a Solana-origin swap, Geodesics returns an unsigned Solana v0 transaction and a sealed operation token. The agent signs the transaction using its Solana signing environment.

4.3 Sign#

The user's wallet environment authorizes the built operation. An EVM wallet signs the GeoOp hash. A Solana wallet signs the origin transaction.

For a Virtuals/Privy wallet, the user configures the wallet and grants any required scope through that wallet environment. The signer private key remains within the Virtuals/Privy wallet environment and is never provided to Geodesics. For a self-managed wallet, the user's wallet signs locally with its own private key. Geodesics receives only the resulting signature or signed transaction.

4.4 Submit and forward#

The client sends the signature or signed transaction, sealed operation token and idempotency key to the Geodesics API. Geodesics assembles the final package from those inputs. Geodesics does not sign any blockchain transaction. For EVM flows the independent solver broadcasts; for Solana-origin flows Geodesics submits the user-signed transaction to the network unchanged.

The submitted request creates a swap identifier that the client can use for status checks.

If a request is interrupted, Geodesics can retry only the identical signed package. A changed route, amount, destination or call requires a new operation and a new user signature. The idempotency key causes a repeated request for the same package to return the existing swap instead of starting a duplicate.

4.5 Settle#

After the independent execution provider accepts the forwarded package, a swap moves through pending to one of 3 terminal states:

Status responses can include origin and delivery transaction hashes. Users should verify material transactions on the relevant block explorers.

The current documentation reports typical settlement of 5 to 15 seconds, including cross-chain routes. Network congestion, liquidity, provider outages, chain activation and other conditions can extend that time.

5. Execution architecture#

5.1 One interface, network-specific execution#

Geodesics keeps the external loop consistent while adapting the build, signing and submission steps to the origin network. Independent infrastructure provides the route. Geodesics constructs the exact operation and the user signs it. For EVM flows, Geodesics forwards the final package and the independent solver broadcasts the blockchain transaction. For Solana-origin flows, Geodesics submits the user-signed transaction to the network unchanged.

This separation lets an agent reason about the desired result instead of maintaining a complete execution stack for each chain.

5.2 EVM delegated account model#

An EVM wallet activates once on each origin chain before it can use the delegated smart-account flow. After activation, one signed GeoOp authorizes a normal swap.

Wallet activation and scoped wallet permissions do not give Geodesics a signer private key or wallet-admin key. The wallet environment retains the signing capability.

Higher-level Geodesics integrations can prepare activation when the signer supports transaction submission. The wallet must authorize and send the activation as an onchain action. Activation can take longer than a normal swap and may require a small stablecoin balance on the relevant chain.

The signed hash commits the material execution data. Changing the route or amount changes the hash and requires a new signature.

5.3 Solana execution#

Solana does not use the EVM delegation step. The agent signs the actual origin transaction returned by the build endpoint.

The client returns the signed Solana transaction to the Geodesics API. Geodesics submits the user-signed transaction to the Solana network unchanged and may re-submit the identical signed transaction while it remains valid.

Delivery into Solana can occur without an existing SOL balance in the destination wallet. A swap originating on Solana needs a small SOL balance for the origin network fee. The current integration checks for approximately 0.005 SOL and can guide the agent through a top-up route when required.

5.4 Route providers#

Independent routing infrastructure generates the route and quote data. Independent execution infrastructure can interact with exchanges, bridges, liquidity venues, relayers, RPC providers and other components. Provider availability and route composition can change between quotes.

Geodesics uses the route returned by independent infrastructure to construct the exact operation presented for signing. It does not provide a personalized recommendation about whether the user should buy, sell or hold a crypto-asset. Users receive the information needed to review and authorize the operation. The live documentation describes the public integration contract.

6. Gasless execution#

For supported EVM flows, independent execution infrastructure covers network gas and recovers the economic cost from the input amount. The wallet therefore does not need to maintain a separate native gas-token balance for the normal swap.

Gasless execution still has a cost. The quote can reflect network gas, platform fees, liquidity-provider fees, bridge costs, price impact and other route expenses. The quoted input and expected output show the economic result before authorization.

The term gasless applies to the wallet experience for the supported step. It does not mean that the blockchain performs work at no cost. It also does not remove the Solana-origin requirement described in Section 5.3.

This model helps agents avoid per-chain gas inventories. It also reduces a common failure mode in which an otherwise funded wallet cannot complete an operation because it lacks the correct native token.

7. Custody, signing and security model#

7.1 User authorization#

The user or agent operator controls the wallet and signing policy. For Virtuals/Privy wallets, the signer private key remains within the Virtuals/Privy wallet environment. Self-managed wallets sign locally with the user's own private key. Geodesics receives only the resulting signature or signed transaction. It never receives a signer private key or wallet-admin key and has no independent authority to sign another operation. Geodesics assembles and forwards the final package without changing the signed parameters. It cannot produce a replacement signature, change the authorized route, amounts, destination or calls, or access the user's wallet or assets. The independent solver broadcasts the blockchain transaction (EVM flows; see Section 5.3 for Solana origin).

Operators remain responsible for signer policies, allowlists, transaction limits, wallet security and the behavior of agents acting with their authority.

7.2 Credential handling#

Geodesics API keys are shown once when created. The service stores a hash of the API key rather than the plaintext value.

When a self-managed wallet is used through the Geodesics CLI, locally configured signer credentials remain in the operator's operating-system keychain where available. The CLI warns the operator before any local plaintext fallback. Server-side integrations can use a wallet provider or signing environment controlled by the operator. Geodesics servers do not receive the signer private key.

Users should never send recovery phrases or private keys to Geodesics support channels.

7.3 Sealed context and expiry#

Sealed quote and operation tokens preserve the route context between steps. The user signature binds the material operation parameters. Any change requires a new signature. Short quote expiry reduces the chance that a client submits stale pricing.

7.4 Retry safety#

Idempotency keys protect the forwarding step against duplicate execution caused by timeouts or retries. Geodesics can retry only the identical signed package. Clients should persist a unique key for each intended swap and reuse it only when retrying that same package.

7.5 Security boundaries#

The security model includes systems outside Geodesics' control. Wallet providers, smart contracts, RPC services, exchanges, bridges, relayers and blockchains can fail or suffer compromise. Non-custodial design limits Geodesics' authority over user funds, but it does not remove smart-contract, market or infrastructure risk.

8. Integration surface#

All 4 integration paths use the same quote, build, sign, forward and status lifecycle.

The console at console.geodesics.ai provides self-service API keys, swap history, transaction links and rate-limit information.

The live documentation remains the source for package names, endpoints, request fields, rate limits and setup commands.

9. Supported networks#

The current documentation lists 8 networks:

Each network can act as an origin or destination when a route exists. Same-chain routes use the same external interface as cross-chain routes.

Supported assets and canonical stablecoins differ by chain. Robinhood Chain uses USDG as its documented stablecoin, and BNB Smart Chain uses Binance-Peg USDC with 18 decimals. Integrators should use the current addresses and decimals published in the documentation.

Network coverage, assets and available routes can change as providers and liquidity conditions change.

10. Agent reliability and operational controls#

Autonomous execution needs machine-readable outcomes. Geodesics returns typed errors for common recovery paths, including:

• NEEDS_DELEGATION when an EVM origin chain requires one-time activation
• NEEDS_SOL_TOPUP when a Solana-origin wallet needs network gas
• NO_ROUTE when the requested pair or chain combination has no route
• NEEDS_LARGER_SIZE when an amount is too small for the route
• SLIPPAGE when price movement exceeds the allowed bound
• upstream timeout or provider errors that the client can retry with backoff.

The agent skill and CLI convert these responses into explicit next actions. JSON output lets an agent distinguish warnings from terminal failures without parsing human-oriented logs.

Quotes and builds happen before a swap receives a status. After the client sends the signed package and Geodesics forwards it to independent execution infrastructure, clients should continue polling until they receive settled, failed or refunded. Interrupting a local command does not cancel a forwarded transaction.

Operators should apply transaction limits, allowlists, slippage bounds and monitoring that match the value and autonomy of each agent.

11. GEO#

GEO is an optional utility token connected to the Geodesics platform. Geodesics publishes current GEO information at geodesics.ai/geo.

The GEO Token Disclosure contains the complete description of supply, distribution, launch mechanics, taxes, vesting, holder rights, administrative controls, utility terms and token-specific risks. Geodesics will publish the verified contract address at geodesics.ai/geo after deployment.

12. Development direction#

Geodesics uses a stable intent and settlement interface. Development can expand the networks, assets, routes and wallet environments behind that interface without requiring agents to learn a different execution model for each provider.

Current priorities are:

• improving route coverage and liquidity depth
• expanding support for agent runtimes and wallet providers
• strengthening automation around onboarding, recovery and monitoring
• improving reliability, observability and security controls

These priorities are directional and do not create a commitment to a release date, network, route, feature or commercial term. Geodesics will publish current capabilities through its documentation and official channels.

13. Risks and limitations#

Geodesics software supports user-authorized transactions across public blockchains and third-party services. Users should account for the following risks:

Market and liquidity risk#

Prices can move between quote and execution. Low liquidity can increase price impact, cause slippage or make a route unavailable. Digital assets can lose all of their market value.

Smart-contract and provider risk#

Contracts, exchanges, bridges, relayers, RPC providers, wallets and other route components can contain bugs, suffer exploits or become unavailable. A failure can delay, fail or misdirect a transaction.

Cross-chain risk#

Cross-chain execution depends on multiple networks and message-delivery systems. Differences in finality, congestion, validator behavior and destination conditions can affect completion.

Signing and automation risk#

An agent with signing authority can act within the permissions granted by its operator. Weak policies, leaked credentials, malware or faulty agent logic can cause unauthorized or unintended transactions.

Irreversibility and user error#

Blockchain transactions are generally irreversible. Incorrect token addresses, network selection, recipient addresses, amounts or decimals can cause permanent loss.

Timing and status risk#

The 5 to 15 second settlement range is typical, not guaranteed. Status data can lag the blockchain or a connected provider. Users should verify material results onchain.

Regulatory and tax risk#

Laws, regulations, sanctions and tax treatment can change. Users remain responsible for determining whether they may use the service and for meeting their own reporting obligations.

14. Official information#

Use only information and addresses published through official Geodesics channels:

• Website: geodesics.ai
• Product documentation: docs.geodesics.ai
• Console: console.geodesics.ai
• GEO information: geodesics.ai/geo
• X: @Geodesics_ai
• Contact: info@geodesics.ai

Token names and tickers are not unique. Verify the GEO contract address through geodesics.ai/geo before acquiring or transferring GEO.

References#

1. What is Geodesics?
2. Quickstart
3. Swap lifecycle
4. Gasless delegation
5. Solana swaps
6. Agent skill
7. TypeScript SDK
8. REST API
9. Supported chains
10. Authentication
11. Errors
12. Geodesics Terms of Service