Hold the owner's Bond
The owner deposits tokens into a vault for their agent. The Base configuration names USDC, WETH, and cbBTC. The Solana program holds USDC and wrapped SOL. The deposit credits that vault. It does not send the tokens to Agentics.
How the Bond works on-chain
A Bond is money behind a receipt if something goes wrong. This page says what the code does today, and what the vault contracts will do once deposits open.
What the Bond is today
Backed by money the owner keeps in their own wallet. Agentics reads that balance on-chain before it allows pay-later. Agentics does not hold that money.
When a seller opens pay-later, that read is not taken from a saved copy. If the read fails, pay-later does not go through. A seller's earlier check can show the last successful read. That read is refreshed when it is more than 10 minutes old. It is not a new chain read on every check.
The vault contracts on this page are not part of either step. The live check does not call them, and pay-later does not call them.
What the vault contracts will do
Four jobs, from the source. Neither vault is on mainnet, and this page publishes no address.
Check capacity before an authorization
A new authorization is recorded only when the covered balance can take the amount. If prices fall, new authorizations fail that check. An authorization already recorded is not unwound.
Pay a valid seller claim
After the due time, the named seller can open a claim. The Base configuration gives the owner 72 hours to pay or dispute. Silence lets the seller take the payout. On Solana the response window is set when the program is initialized, from one second up to 14 days, and the payout waits for that window.
Let the owner withdraw free collateral
On Base, free collateral waits 7 days, and what remains must still cover what is open. On Solana there is no wait. A withdrawal is one transaction, and it goes through only when what remains still covers what is open.
What the contracts can't do
Only limits the source enforces. Where the two chains differ, the card says which one.
Not upgradeable, on Base
The Base vault is not a proxy. There is no upgrade function, no delegate call, no self-destruct, and no rescue or sweep. A fix is a new deployment. The vault runtime in this source is 24,150 bytes.
No role takes the Bond, on Base
No function lets the attestor, the governor, or the resolver move a Bond's tokens to itself.
Three ways out, on Base
Tokens leave a Bond only to the owner, as a withdrawal; to the seller named on that authorization; or to the fee recipient, as the fee on that payment.
The attestor cannot charge alone
Recording an authorization needs the owner's policy, or a co-signature from the owner or a session key. The attestor's signature by itself is refused. The Solana program has the same rule, and it also refuses a seller that is the same key as the owner.
Pause stops only new exposure
Pause blocks new deposits and new authorizations. It does not block withdrawals or payouts. This is true on Base and in the Solana program.
An unresolved dispute ends
On Base, 14 days after a dispute is opened, anyone can release it. Nothing is paid, and the tokens stay in the Bond. On Solana the same release exists. The wait is chosen at initialization, from 1 day to 30 days. On both chains the seller can release a disputed claim, and nothing is paid.
The fee is saved when the authorization is recorded
The fee starts at 0. The code rejects a fee above 3%. A change waits 48 hours. On Base, the fee stored on the authorization at record time is the fee used when that authorization is paid. A later change does not reach it. The Solana program stores the rate the same way. The fee recipient on Solana is still the recipient in force at payout, and changing that recipient waits 48 hours. The fee comes out of the seller's side of a payment.
A signature can expire
On Base, the authorization and the owner co-signature both include a deadline. Recording is refused once the clock is past that deadline. The deadline is inclusive: the last second named in the signature still counts. On Solana, the signed attestation is 173 bytes and includes an expiry. Recording is refused unless that expiry is still ahead, and not later than the due time.
The Solana upgrade key
The Solana program's upgrade key can replace the program today. Replacing the program can change where tokens go. Before deposits open, that key moves to a multisig or is removed.
Chains and addresses
Neither the Base vault in this source nor the Solana Bond program is deployed to mainnet.
Solana
Address published at launch
The program in this source is not deployed to mainnet. This page does not publish a program id or an explorer link.
Base
Address published at launch
A test deployment of an earlier vault runs code from before the fee snapshot and the signed deadline. It is not this source, so this page does not publish that address or an explorer link.
Source code
Source published with the audit report.
The repository that holds this source is private. A public link appears here when that URL is set.
Audit status
The audit pack is ready for auditors. Vault deposits stay closed until that review is done.
No auditor is named on this page. A name goes here only when it is in the repository or the legal text. The items below are still open in the source. The fee snapshot and the signed deadline are fixed in this source. They are not in the earlier test deployment.
Receipts on-chain
Every five minutes, a job fingerprints receipts that are not yet posted. That fingerprint is a Merkle root. When the posting key is configured, the job sends it to Solana mainnet with the Memo program. The post is the fingerprint, not the text of the receipts.
On Base, the vault stores no receipt. An authorization records the Bond, the seller, the amount, the due time, the fee saved at record time, and the inclusive deadline. A claim is stored against that authorization and has no receipt field.
On Solana, the authorization account stores a 32-byte receipt, and the claim account points at that authorization. The signed attestation is 173 bytes. It carries that receipt and an expiry. A claim reaches the receipt through the authorization. The program is not deployed to mainnet, so that link is in the source, not in a live vault.
The receipt a person can check today is the signed record, then this fingerprint. The vault does not write that record.
The latest post is read from the same check the status page uses.