routr/

Documentation ·

How token trading funds
your agent’s AI calls.

How it works

The routr hook collects a separate compute fee on supported buys and sells of your token. Only this fee goes to routr to fund your agents’ AI model calls. Each token has its own budget.

routr receives only the compute fee, not all fees from trading your token. Any separate creator or launchpad fees follow their own settings.

Your agent sends prompts through the routr API. routr pays the model provider from your token’s budget and sends the answers back to your agent.

The budget pays for AI model calls. You choose what your agents do and where they run.

In development

The routr hook and model API are not live yet. We are testing the hook and preparing the Bordrless integration. This site explains the planned service.

Funding & fees

  1. Someone buys or sells your token. In the tested prototype, the hook collects the compute fee in your launched token. The production fee rate and available launch settings are still being worked out.
  2. Only the compute fee goes into routr’s holding account for that token. Other trading fees are not collected by this hook.
  3. routr sells the collected tokens for USDC. This happens separately from the original trade. We wait for the sale to complete before adding credit.
  4. routr keeps 10%; your token gets 90%. The split applies to the net USDC received after conversion. The remaining budget can be spent on AI calls; it cannot be withdrawn.
  5. Your agent spends the budget when it calls a model. We deduct the provider’s charge for that call. A trade does not automatically trigger an AI request.

For every $10 received after converting compute fees into USDC: $1 goes to routr and $9 goes to the token’s AI-call budget. routr’s charge is 10% of those net proceeds—not 10% of the trade value or of all trading fees.

The 10% comes out when we add the funds to the budget, before your agent uses them. We do not add another routr markup to model calls.

We are also evaluating a SOL-based funding route. Newer Bordrless source supports SOL-denominated hook fees and shared creator-fee payouts. Those payments follow different accounts and permissions. Our existing tests cover the token-fee prototype above, not these newer options.

Bordrless fee settings

How the fees fit together

Fees in the proposed integration
FeeHow it applies
Config author fee0%. The selected Bordrless config gives its author no share of the creator fee.
Token creator feeA separate Bordrless launch setting. It may be nonzero. It is not the compute fee and does not automatically go to routr.
Compute feeThe routr hook’s fee on supported buys and sells, collected in the launched token. Only this fee funds the token’s compute budget. The prototype uses a rate fixed in its build; the production rate and configuration options remain to be agreed.
routr service fee10% of the compute fees’ verified net USDC proceeds. Deducted when the budget is credited; the remaining 90% funds the token’s model calls.

The hook covers the supported native trade paths. Unsupported routing must reject rather than bypass the levy. Ordinary token transfers and authenticated liquidity or lifecycle operations have their own rules.

Launching on Bordrless

The planned experience is to launch your token on Bordrless’s website with the routr hook attached. You remain the token’s creator. routr holds only the fees allocated to compute. Receiving those fees does not grant creator or dashboard access rights. Authority to upgrade the hook’s code is separate and follows the upgrade rules below.

Bordrless supports custom launch configurations that can include a hook. We are preparing a routr configuration for that route, so it may be usable before routr appears as a built-in choice. The website steps and available fee settings have not been confirmed yet.

Why setup happens before the first trade

Our current prototype uses this order:

  1. Create the token without buying any during launch. This gives the token its own address on the blockchain. The first purchase happens after setup.
  2. Create and check the account that will receive its compute fees. This holding account is controlled by routr and linked to that specific token. It can only be created once the token exists.
  3. Begin trading once that account is ready. Buyers and sellers can then trade, and the hook sends each compute fee to the correct account.

If someone tries to trade before the fee account is ready, the hook rejects the trade. This prevents trades from going through without collecting the compute fee.

Bordrless’s token-launch website needs to support this sequence. It needs to create the token, allow the routr fee account to be set up and checked, and only then offer the first purchase. We have tested this order locally; we have not yet confirmed it through Bordrless’s live website.

A launch using a custom hook cannot also enable Bordrless kit modules. The integration must choose a compatible configuration.

Access your dashboard and API

Open the dashboard and sign in with MetaMask or Phantom. You can sign in before you launch a token.

  1. Connect your wallet. Choose MetaMask for an Ethereum-compatible account or Phantom for a Solana account.
  2. Sign a message to prove you control it. Signing in does not send a transaction, move funds or cost gas.
  3. Open your account. With no linked token, you see an empty dashboard with no budget or usage.

Token linking, API keys and paid model calls are still in development. Before granting access to a token’s budget, routr must check that the signed-in wallet is its current authorized controller. Signing a message proves wallet control; it does not prove token ownership.

Once that integration is ready, you will connect your agent using a token-specific API key. Your wallet signs you in; the API key lets your agent spend that token’s budget.

Your agent and its tools

Your agent can run on your computer or on a server. It sends prompts to an AI model through routr. When the model asks to use a tool, your agent’s software runs that tool and sends the result back.

For example, a research agent could search for a paper, read it and save a summary with sources. routr would pay for the model calls in that process. The agent’s server and any paid search tools are separate costs.

Tool calling, streaming and coding-tool compatibility are planned. The current local prototype returns text only; these integrations still need to be implemented and tested.

Integration sequence

The following is a developer preview of the tested token-fee prototype, not a runnable guide to the current Bordrless interface. It uses four separate phases. A SOL-based integration would need a different payment design and fresh tests.

Required setup and launch order
PhaseActionRequired before continuing
1. Prepare the hookBind the per-mint hook state and registry to the future mint and its canonical collector reference.Verify the code, authorities, derived accounts and finalized registry.
2. Create the configUse launch.createConfigTimelocked with zero author share, an explicit creator fee, the routr hook and matching rules.Verify the finalized config and the supported, idle timelock. The setup payer and new config account are signers.
3. Customer launchThe customer selects the config on Bordrless and requests zero initial buy. Review the complete unsigned transaction list before signing.Check the mint, customer, metadata, fees, accounts, hook and transaction contents against the launch intent. The customer and new mint account are the launch signers. Wait for launch finality.
4. Create the collectorCreate the canonical holding for the existing mint and configured routr collector owner.Verify its owner, mint, state and finality, then simulate the supported trade path before enabling trading.

The local SDK assembly creates one unsigned packet per phase, each containing a compute-budget instruction and one phase instruction. It creates no keys, signs nothing and submits nothing. Rebuild each later phase with a fresh verified blockhash after the preceding phase has finalized.

The local handoff verifier compares supplied unsigned launch transactions with the intended launch. It rejects changed accounts, permissions, metadata, fees or instructions, extra transactions and any signatures already present. A match establishes agreement with the expected launch; it does not establish that the response came from the Bordrless website or contains its complete transaction list.

Hook upgrades

For routr’s selected upgradeable-hook design, code changes must be scheduled publicly at least three days before they can take effect. The hook address and flags attached by this launch flow remain fixed. Updating that program’s code is different from adding or swapping arbitrary hooks on an existing token.

The pinned Bordrless program checks the timelocked config again at launch and rejects a pending proposal. The deployed program authority, timelock delay, idle state and upgrade process still need verification.

What has been tested

The evidence below comes from separate local verification runs. It is not a combined end-to-end test, a live deployment or an external audit.

Implementation status as of 13 October 2026
AreaVerified locallyStill open
Launch and first tradeLocal runtime passed

Compiled Bordrless Launch, Swap and Token programs run with the routr hook: zero-buy launch, rejection before collector setup, collector creation and exact first-buy levy receipt. The rejected buy preserves the checked token, mint, pool and launch state.

Tests use unsigned transactions with signature verification disabled, plus synthetic governance and quote-token issuance. Real signatures, production authority and funding remain unverified.
Launch transaction sizeLocal runtime passed

The measured v0 launch is 1,047 bytes, compared with 1,383 bytes for its legacy form and a 1,232-byte limit. The exact serialized v0 transaction executes using a locally created lookup table.

The production table and network finality need verification. Metadata and added instructions change packet size; 1,047 bytes is a fixture measurement, not a universal size.
Setup and SDK assembly37 checks passed

The setup and actual pinned SDK suites cover separate phases, signers, registry and timelock bindings, account permissions, declared lookup-table state and serialized size.

These checks use supplied public declarations. Live account state, authority, lookup tables and native-site acceptance remain unverified.
Unsigned website handoff19 checks passed

Actual-SDK fixtures are compared with regenerated launch intent. Changes to accounts, permissions, metadata, fees, blockhash or transaction contents reject, as do partial signatures.

No authentic live website export has been supplied. The verifier cannot establish the origin or completeness of a caller-supplied response.
Funding and model callsLocal prototype

Ledger simulations cover token attribution, duplicate-receipt prevention, recovery and atomic budget credits. Scoped-key model requests and simulated billing are implemented.

Real collector liquidation, verified net-USDC settlement, operational signing, live provider calls and commercial provider access remain pending.

Graduation, subsequent launch-pool sells and supported routing also need validation against the deployed revision. The trading hook and model gateway remain undeployed. The customer dashboard has a separate wallet sign-in service.

Model API

This is the local prototype contract. No production API base URL or public SDK installation command has been published. The public website does not serve model requests.

An API key is scoped to one budget. Use GET /api/v1/balance to read its balance, GET /api/v1/models to inspect model availability, and POST /api/v1/chat/completions to request a response. A request body cannot switch the key to another budget.

POST /api/v1/chat/completions
Authorization: Bearer <scoped demo key>
Idempotency-Key: <unique request ID>
Content-Type: application/json

{
  "model": "<ready demo model>",
  "messages": [{ "role": "user", "content": "Hello" }],
  "max_tokens": 128,
  "stream": false
}

The local client is RouteClient({ baseUrl, apiKey }), with balance(), models() and chat() methods. Chat currently supports non-streaming responses. Keep API keys on your application server.

Save a unique idempotency key for each request and reuse it with the same payload on retries. If the outcome is unknown, reconcile that request before starting a new paid operation.

Token and budget controls
  • Token control must be verified. A signed, expiring, single-use challenge proves control of a wallet. Token administration additionally requires the current authoritative launch/controller registration. Token holdings, mint authority and routr’s collector role are not substitutes.
  • Each token’s budget stays separate. Collected assets, settlement proceeds and credits must retain their token attribution. Any public token view should expose only opted-in budget information, never prompts, API keys or private usage.
  • Only verified proceeds become credit. A unique, finalized receipt must establish the correct asset, destination, token attribution and exact amount received before the ledger credits the budget once.
  • Model spending must be reconciled. The prototype reserves and settles simulated spending. Production calls must settle against verified provider billing; uncertain charges must remain reserved until resolved.

Pinned primary sources

The prototype tests refer to these exact revisions. Source behavior does not establish the current website’s behavior or imply Bordrless endorsement.

Newer source reviewed separately

We also reviewed SDK revision ce76276 and program revision b76cb3c. The SDK changelog reports mainnet availability; we have not independently verified deployed programs, the live launch interface or routr compatibility.