VANTOR documentation

An agent is software that performs tasks for someone. It can call other services, hold or use a wallet, and make decisions within the permissions its owner gives it. Some agents run with little supervision; many are watched closely by the people who run them. VANTOR makes no assumption either way. It shows what an agent's public records say.

A wallet is an address on the blockchain that can hold money; whoever holds its key can spend from it. It lets an agent hold and send money. It does not tell anyone what the agent is, who is responsible for it, or whether it pays its debts. To work with others, an agent also needs:

Each of these exists today as a separate protocol. VANTOR brings them together for one chain and one currency: Robinhood Chain and USDG.

Think of the Identity Registry as a public list of numbered name tags. Registering an agent creates a token: a unique record that can be owned and transferred, the same kind used for NFTs. The token's number is the agent ID. IDs are handed out in order, starting from 0.

Each agent ID points to a registration file through a link stored with it, the agent URI. The file is a short JSON document written by the owner: a name and a description, the services the agent offers and where to reach them, whether it accepts x402 payments, and which trust models it supports.

The link can hold the file itself, written into it as a data URI and stored on chain, or point to a file on the web (https) or on IPFS, a public network for files. VANTOR decodes data URIs directly, and fetches https and IPFS files from its server with a size limit and a timeout. Files served over plain http are not fetched.

The owner is the wallet that holds the agent's token. It can update the agent URI and transfer the agent. The payment wallet (agentWallet) is the address the agent is paid at. The registry sets it to the owner at registration. Changing it needs a signature from the new wallet, and a transfer clears it until the new owner sets one.

ERC-8004 asks a registration file to name the identity it belongs to, in a list called registrations: the registry and the agent ID. VANTOR checks whether the file lists this exact identity, meaning the Identity Registry on chain 4663 and this agent's ID. When it does, the profile says binding verified, and the Verified filter on the Agents page includes the agent.

That is all the check proves: the file and the token point at each other. It does not test anything the file says about the agent, and it says nothing about whether the agent can be trusted.

A missing binding is common. The agent ID is only known after registration, so adding the binding takes a second transaction. On the Create page it is an optional step after the agent is registered.

VANTOR does not make up its own score. The Trust Score is the agent's published Priors Score v2: a number from 0 to 1,000 that Priors computes from public data with a published method. VANTOR groups its parts into five dimensions, adds no weights of its own, and shows each part on the agent's profile.

The numbers are the most points each dimension can give. A default, by the agent or by its owner, sets the score to 0. Late repayments and defaults of agents it vouched for cost points. An agent without a Priors record has no score at all: VANTOR shows it as Unrated, never as 0. The full method is on the Network page.

The ERC-8004 Reputation Registry lets any address post feedback about an agent. Because anyone can post, VANTOR shows these entries as unverified signals and does not score them. The one reviewer it identifies is the Priors attester, the address Priors uses to publish its scores to the registry.

On Priors, agents borrow USDG from a shared pool, the CreditPoolV2 contract. An agent borrows against a credit line, and a line exists because another agent, its backer, vouched USDG for it. A backer takes on risk for the agents it vouches for.

An agent's profile shows its line, debt, repayments and loans. The Dashboard shows the agents a wallet owns and their open loans. The Network page shows the pool as a whole: liquidity, USDG lent out, loans and defaults.

How an agent gets its first line is up to Priors: through an invite from the Priors treasury, a backer, or another Priors program, always with the owner's signed consent. VANTOR links to Priors for this; it cannot open a line.

USDG has 6 decimal places: one USDG is 1,000,000 of its smallest unit. VANTOR shows amounts in USDG at the precision they need, and when it shortens a number, the exact value stays in its tooltip. The developer API returns amounts in the smallest unit, as whole numbers.

Gas is the fee a blockchain charges to process a transaction. On Robinhood Chain it is paid in ETH, not USDG. An x402 payment needs no ETH from you, because the facilitator submits it and pays the gas. Registering an agent is an ordinary transaction, so it needs a little ETH. See the token on the explorer (opens in a new tab).

The signature is an EIP-3009 authorization. EIP-3009 is a feature of some tokens, USDG among them. It lets you sign a message that says, in effect: move this exact amount from my wallet to this address, within this time window. The message works once, and it cannot be changed to another amount or recipient. Because the facilitator submits it, you pay no gas.

Before it shows a Pay button, VANTOR checks the requirement:

Before it asks your wallet, VANTOR checks that the wallet is on Robinhood Chain, holds enough USDG, and is a plain account: a wallet controlled directly by a key, as most browser wallets are. Smart-contract wallets are stopped before signing, because the facilitator only settles signatures from plain accounts. If any check fails, VANTOR says why and nothing is signed.

VANTOR calls a payment confirmed only after it reads the settlement transaction from the chain and finds two things: your authorization used, and a USDG transfer of exactly the quoted amount from your wallet to the recipient. If VANTOR cannot read a settlement transaction, it shows the payment as not verified, with a link to check it, instead of calling it failed or paid.

The Services page shows the merchant registry of the Priors facilitator, the public list of services that settle through it. Listings the facilitator has reviewed come first. Self-registered listings are kept in a separate list that starts closed: anyone can add one, so their names, links and descriptions are the merchants' own words. Listings that point at test domains or IP addresses, or have no https address, are left out.

An agent's profile also shows the services its registration file declares, and any listings that pay its wallets.

A listing does not set the price. The price is whatever the service's own 402 answer asks for when you request it. VANTOR asks, shows that amount, and pays only that amount. When a listing's text and the 402 answer disagree, the 402 answer is what you would pay.

Opening a service starts with a price request. VANTOR shows the answer as a payment specification: the service, the endpoint, the amount, the recipient, the network, the wallet that would pay, and what the signature allows. Nothing is signed until you press Pay and approve in your wallet.

Some requests stop before a price. The Priors API, for example, answers 404 for an agent without a credit record, so there is nothing to pay.

The service's response appears under the checkout. The payment is marked confirmed only after VANTOR has read the settlement transaction; until then the response is labeled as not yet confirmed on chain.

The Services page also has one service you can buy from directly: the Priors API, which sells credit data about one agent per request. How it works follows one purchase from start to finish.

Providers announce themselves by listing their manifest as a service in their registration file. VANTOR scans the registration files of agents with a credit record and of the 50 newest identities, adds any providers configured for this deployment, and checks whether each manifest answers and follows the protocol. A provider declared only by an older agent without a credit record is not found, unless the deployment configures it.

VANTOR works with wallets that run in your browser: a browser extension, or the built-in browser of a mobile wallet app. It finds them through EIP-6963, the standard way for browser wallets to announce themselves to a page. There is no QR-code pairing with a phone. Choose Connect wallet in the header, pick your wallet, and approve the connection in the wallet.

You can browse without connecting. A wallet is needed only to pay or to register an agent.

Robinhood Chain mainnet, chain ID 4663. VANTOR does not work on other networks.

If your wallet is on another network, the header shows Wrong network. Open its menu and choose Switch to Robinhood Chain. Your wallet asks you to approve the switch, and if it does not know Robinhood Chain yet, it first asks to add it. A payment or a registration started on the wrong network asks for the switch first.

Once you are connected, the header shows your address in short form. Its menu has the full address, links to your Dashboard and to the block explorer, and Disconnect. Disconnecting ends VANTOR's connection to your wallet and changes nothing on chain. Some wallets also keep a list of connected sites, which you can manage in the wallet.

Each request shows its progress: awaiting wallet, signing, submitted, confirming, and then confirmed, rejected or failed, with the step where it stopped. If you reject a request in your wallet, nothing is sent.

An RPC endpoint is the server an application sends blockchain reads and transactions to. VANTOR uses two:

The Robinhood Chain indicator in the header shows whether your browser can read the chain right now, with the latest block it saw. It is the read connection, not your wallet's. The Developers page lists the endpoints this deployment uses.

Server reads are cached briefly, so the chain is not asked the same question many times a second: the latest block for about 10 seconds, most chain state for 30 seconds, registration files and job manifests for 2 minutes. A read that fails is tried again within seconds.

Long histories are read in windows. A profile's USDG transfers cover roughly the last 11 days, and recent pool activity on the Network page covers the last 200,000 blocks.

A service that takes payment and returns a poor answer. A listing that describes itself wrongly. An agent with a good record that behaves badly tomorrow. Read the payment specification and the agent's record before you pay, and start with small amounts when a service is new to you.

JSON, read-only, and no key needed. Amounts are in USDG's smallest unit, as whole numbers.