Showing Warda’s own agents — public examples.
No published grant names this key yet
This console shows a grant when its reading is published and names your key as the principal that funded it, the revocation key that can stop it, or the agent that spends it.
Overview
Every grant this project has issued, what it spent, and what the covenant would not let it do.
Grants you track
Manage →Read from their grant.json and checked against the chain by the verifier just now — not published readings, so they carry no payment history here.
Spending over time —
—Every payment any of these agents recorded, by the day it settled. Cumulative, because a budget is a total and not a rate.
Where it went by agent
KAS only. There is no second asset here to split by — the covenant compares sompi, and a chart with one slice labelled “100% KAS” would be decoration.
Grants
All grants →| Agent | Spent of budget | Per payment | Payees | Expires | State |
|---|
Top payees
A payee is an address. Two addresses can serve the same host at different prices, so the host is the label and the address is what distinguishes the row.
Delegation one grant funding another
A grant can fund a child with a narrower allowlist and a smaller budget. The depth is compiled in, so the chain is what stops it going further.
Reconciliation
What the covenant says was spent, against what the agent’s own log names. A gap here is the only kind of missing money this design can produce.
Where they buy the registry
All services →Every endpoint these agents have paid, and how much has gone to each — counted from the same readings, by the URL the purchase recorded. A listing is a claim somebody made; the payments are what happened.
Notices
Derived from the readings on this page, every one of them checkable against the row it came from.
Recent activity
All →Export
Every payment in view, as it is on this page — the same range and the same filter. Nothing is re-derived on the way out, so a row here and a row on screen are the same row.
The readings themselves
Nothing on this page is typed in. Each figure comes from one of these, which anybody can fetch and check.
Grants
What the covenant permits each agent, and what is left of it. Budget and cap are fixed at creation and cannot be raised.
Grants you track
Manage →Read from their grant.json and checked against the chain by the verifier just now — not published readings, so they carry no payment history here.
Every grant —
| Agent | Budget | Spent | Left | In its account | Per payment | Per period | Payees | Helpers | Expires | State |
|---|
Two numbers can end an agent, and the smaller one is the answer. Left is what the covenant would still permit; in its account is what the coin at the grant’s address actually holds. Any grant that has paid for anything has spent fees out of the second and not the first.
Agent
—
Who it may pay fixed at creation
Compiled into the grant as the root of a tree. It can never be added to — changing it means issuing a successor and ending this one.
Payments —
| When | For | Paid | Outcome |
|---|
Rules in force derived
Not attempts. Each is a limit the covenant enforces on every spend, derived from this grant’s own terms.
Coins it has paid —
Still sitting at a payee, matched to this grant by the transaction id its own log recorded — a payee address serves whoever pays it, so the id is what makes the match mean anything.
Controls
—
What the network enforces
—
Reconciliation
—
Identity public halves only
This console has never seen a private key and has no way to sign.
Analytics
How fast each grant is being spent, where it goes, how close agents run to their limits, and what the covenant turned down. Figures are from on-chain spend and each agent’s own purchase log; where there is too little data to call something a rate, it says so instead of drawing one.
Daily spend
Settled payments from each agent’s purchase log, by the day they settled, stacked by agent.
Burn rate and runway
Rate is what each grant has spent on chain, divided by how long it has been open. The bar is how long the money lasts at that rate; the tick is where the term ends. Whichever comes first is the end.
Table view
| Agent | Spent | Used | Per day | Money lasts | Term ends | Ends by |
|---|
This week against last
From each agent’s purchase log, settled payments only. The coloured bar is this week, the grey one under it last week.
Budget used
Of the total each grant may ever spend.
How close to the limit
Every settled payment, as a share of its grant’s per-payment cap. Dots in the shaded band are within 20% of the cap — one price rise away from refusals.
Why payments did not go through
Attempts that did not settle, grouped by the reason recorded. The covenant’s standing rules are on Refused, not counted here.
When agents buy
Settled payments by day of week and hour, in your time zone. A bigger dot is more payments.
Cost by endpoint
—
| Endpoint | Payments | Total | Average | Share | Last |
|---|
Active and idle authority
Live grants that paid in the last seven days, against live grants that did not. Idle authority is capital sitting in a grant doing nothing — the first candidate to reclaim.
Cost by delegation tree
What each top-level grant and everything it delegated to has spent, together.
Cost per task
Grouped by the label an agent gave each payment with warda pay --task "…".
The label lives in the agent’s purchase log only — never on chain, never sent to the vendor.
Payments without one are counted as untagged, not left out.
| Task | Attempts | Settled | Total | Per settled payment | Last |
|---|
Your tracked grants over time
Authority left in each grant you track, one point an hour for the last 30 days. Your account reads them on the server every 15 minutes, so the line keeps going while this page is closed. A step down is spending; a step up is a top-up; a line that stops is a grant that moved and could not be followed.
Fleet
Every agent as one managed system: where the capital sits, who delegated to whom, which ones are close to a limit, and the controls to end, reclaim or renew them — one at a time or together.
Where the capital sits —
Authority still unspent in each live grant, and what your connected wallet holds outside any grant. Unallocated capital is only counted when a Kaspa wallet is connected; otherwise it is left out, not shown as zero.
Agents —
| Agent | State | Left | Per payment | Ends | Flags |
|---|
—
There is no pause. A covenant has no switch to flip, so “pause spending” is revoke: the balance goes home the next block, and a successor grant restarts the agent when you want it back.
Growth fleet —
Warda’s own team · weeklyThree agents on one weekly budget. The orchestrator is issued a grant that may pay Researcher and nobody else, hires Scout with a piece of it, takes back what Scout did not spend, and is revoked when the week is done. A fourth, Outreach, writes drafts for a person and holds no money at all.
Who delegated to whom
A child grant is funded out of its parent’s budget with a narrower allowlist. Revoking a child returns its remainder to its principal — that is how funds come back up the tree.
Templates kept in this browser
Common shapes for a new grant. Using one opens Create a grant with its limits filled in.
New template
Risk controls
The limits that bound the whole fleet are the ones in each grant; nothing here can loosen them. What the console adds is being told before one is reached.
Services
What agents can buy, from the Warda registry. Each listing is signed by its operator; paying one is a grant whose allowlist holds its payee, so the agent can pay that service and nobody else.
Known, not listed
Services agents here already pay that have never asked to be listed. Shown because a registry that shows only what it recruited hides the size of what it has not.
Your account
Your account is your key. Connect the wallet that holds it and this console shows the grants you issued, what your wallet can fund, and fills in your addresses everywhere else.
Not connected
Connecting shares your address and public key with this page, and nothing else. It cannot move a coin: it never asks your wallet to sign anything, and there is no server behind it to send your address to — it stays in this browser.
Kaspa wallets — can hold a grant’s key
Any other wallet — MetaMask, Rabby, Coinbase, Trust…
A Warda grant lives on Kaspa, so the key it names is a Kaspa key. An Ethereum-style wallet signs in here all the same: it keeps an account, tracks grants and funds a treasury from USDC on Igra — it just cannot be the key a grant names. For that, the same person adds a Kaspa wallet.
This wallet has two accounts.
Stablecoins in this wallet
Console account
—
Wallets on this account
Where alerts go
not connected
One tap: Telegram opens, you press Start, and alerts from the rules below come to your phone.
Kept for receipts and a later email channel. Not needed to sign in.
Plan
Rules this account runs
Beta: free while accounts are new. Stored: the wallet addresses above, the grants you sync, your rules and where alerts go. Never stored: a key, a seed, or money. Export everything · Delete this account
Grants you hold a key to —
Every published grant where your key is the principal that funded it, the revocation key that can stop it, or the agent that spends it. A grant’s address is a hash of its state, so it cannot be looked up from your address — only a grant whose reading names your key can be found.
Identity
Use it
Each of these fills in your address and opens the page. Nothing is sent or signed.
What signing in is not
Not a transaction. The only thing the console ever asks a wallet to sign is a plain-text sign-in message, checked by this site’s server and used once. If a page on this site ever asks your wallet to sign anything else, do not.
Grants you track
A grant this site does not publish can still be read. Give this page its manifest
— the grant.json that warda grant wrote — and it asks the
verifier whether the chain agrees with it, now. A manifest carries public keys and limits and
never a secret; it is kept in this browser and sent only to the verifier, which reads a node
and keeps nothing. No wallet is needed.
Connect a phone wallet
Scan with your phone’s camera. It opens Kaspire, which asks you to approve sharing your address and public key — the only two things this page requests. Nothing it asks for can move a coin.
Preparing a pairing…
Activity
Every payment these agents recorded, newest first, with the outcome each one actually had.
Payments —
| When | Agent | For | Paid | Outcome |
|---|
Refused
Two different things, kept apart on purpose — what actually went wrong, and what the covenant would refuse if anybody tried it.
Attempts that did not settle —
Recorded by the agent at the moment it happened. These are events, with a date.
Rules in force derived
Not attempts. Each is a limit the covenant enforces on every spend, derived from the grant’s own terms — a thing that cannot happen rather than a thing that did.
Alerts
Four steps. Compose a rule here; your own machine evaluates it and Telegram carries the message. Nothing about this is stored on a server.
What to watch
Three kinds. All of them tell you something; none of them does anything.
—
How the rule is remembered between runs.
When it fires
— reading the market price…
Where your sales land. A public address and nothing else — this rule cannot spend from it, and the tool that evaluates it holds no key.
—
—
What the console watches when it runs this rule for you. The path below is only for running it on your own machine.
“Usual” is the grant’s own spending over the week before, from hourly readings. It needs three days of them before it says anything, and says nothing rather than guess.
A path, relative to the repository. A grant’s address is a hash of its state, so this file is the only thing that knows where the grant currently is.
—
Given one, the message also says whether the next grant can be paid for, and whether it is in one coin. Left blank, nothing is claimed about it.
—
Sent at the top of the message. Yours, not generated.
Where the message goes
To Telegram, from a small script on the machine that runs your node. Set it up once; every rule after that is one entry in a file.
- Create a bot with @BotFather in Telegram and copy its token.
- Send the bot any message, then put the token and your chat id in
ops/alerts.env. - Send yourself a test, look at a dry run, and install the schedule:
cp ops/alerts.env.example ops/alerts.env ops/alerts.sh --test ops/alerts.sh --dry-run ops/install-cron.sh
It notifies. It never acts. Converting for you at your threshold needs a key that can move the coin, held unattended, forever — the hot wallet this project exists to not be. It holds no key, signs nothing and builds no transaction, and the build fails if that stops being true.
The rule
Add this to ops/alerts.json beside your node. That file is gitignored: a
published threshold is a number somebody knows to sit just underneath.
—
Only changes are sent, including the change back. A message every fifteen minutes for a condition that is still true is a message you learn to swipe away. A rule that cannot be read — the node is down, or the chain holds nothing where the manifest says the grant is — says so once, and is never reported as “fine”.
What the rule actually compares
- Measured
- —
- Against
- —
- Read from
- the chain, every 15 min
—
Fund an agent
Four steps. Pay with the stablecoin you already hold; it becomes KAS on Kaspa, and the KAS becomes the agent’s spending authority — a budget the network enforces. Warda holds none of it and takes nothing.
What you pay with
—
—
—
— reading the market price…
What the agent may do with it
The KAS becomes a grant. These are its limits, in dollars here and in KAS in the script — the covenant compares KAS, never dollars.
—
after that the balance is yours to reclaim
—
Checked here in full, because a bridge or a swap service checks only the prefix and the character set — this is the one place a transposed character is caught before the KAS is gone.
How it gets there —
Every route this chain has, best first. A route is only as open as its worst step, and the one with no custodian is preferred whenever it is open.
A swap fills at whatever the pool gives. This is how far below the quote you are willing to land.
—
Review —
The swap
Getting ChangeNOW’s quote…
Optional, and strongly recommended. Without it a failed swap is refunded by writing to ChangeNOW’s support.
Send exactly
—
to ChangeNOW’s deposit address
—
—
The steps you sign
Built by @warda_protocol/router, the same planFunding its tests
exercise, for the route through Igra. Every step that moves value is handed to you unsigned. This
page cannot sign any of them and has no way to.
What you get, and who can get it wrong
—
Warda’s part: none
Warda never holds this money, takes no fee on the crossing, and is not a party to the swap — the venue, the bridge or the swap service is, and each is named above. The day a router holds the float, its security argument becomes a balance sheet.
Already hold KAS?
Then there is nothing to cross. Fund a grant directly from your own wallet.
Create a grant
Four steps. You type dollars; what the network compares is the KAS underneath, shown beside every field.
What it may spend
Type dollars. The line under each field is what goes into the script that unlocks the coin, and that is the only figure any node will ever compare.
— reading the market price…
—
—
—
after that the balance is the principal’s to reclaim
The price is only used once. It turns the dollars you type into the KAS the grant carries, and it is named with a source and a time. After that the grant is KAS: if the price moves, the limits do not, and nothing is ever enforced against a price.
Who it may pay
One Kaspa address per line. This list is not a setting — its root is compiled into the grant, and it can never be added to afterwards.
—
A payee is an address, not a company. One key often serves several endpoints at different prices, and the covenant compares the address. If you need the agent to reach an x402 vendor through a relay hop, its own address goes on the list too — that costs the allowlist for that hop and nothing else.
Its keys, which this page never sees
Three powers, three keys, because they are three separate risks. The agent’s is
generated by the command in step 4, on your machine, and written to agent.key —
never typed, printed or sent anywhere. The revocation key you make yourself, and paste only the
public half of.
warda key --out revocation.key # can stop it at any moment, and receives nothing
Left blank, the stop is the funding key itself. One key to keep and one thing to lose — fine for a first grant, wrong for anything left running.
The revocation key is the one worth keeping cold. A revoke pays the principal rather than its own signer, so whoever holds it can end a grant and cannot take a sompi of it. That asymmetry is the entire reason the two are separate.
Funding it
You sell what you already hold, wherever it already has a market, and withdraw the proceeds. Warda does not touch the asset, does not quote the price and never holds the float.
—
Genesis takes a single input. The figure that matters is your largest coin, not your balance — an exchange that splits a withdrawal into two payments funds nothing, and nobody has any reason to expect that. This looks for the coin, not the total, and says which of the two you have.
Create it
One command, on your machine, with your key. It builds the grant locally, writes the manifest before it broadcasts, and prints the address the coin will live at.
—
Keep the manifest and the allowlist. A grant’s address is derived from the numbers in that file and nowhere else, and a spend rebuilds its proof from the allowlist. Lose either and the grant can be revoked, never spent.
What you are about to make
What the network will enforce
- Total it may ever spend
- —
- Any single payment
- —
- Per hour
- —
- Term
- —
- Who it may pay
- —
—
Not settings
None of the five above can be raised after the grant exists. A grant is not a policy your process agrees to follow; it is a script the network refuses to spend outside of. Changing any of them means issuing a successor and ending this one.
🔥 New agent new
Five steps. The runner holds the agent’s key and runs its jobs, inside a grant every Kaspa node enforces. You fund it from any wallet and keep the key that can stop it and take the money back.
Connect to the runner
The runner holds your agent’s key and runs its jobs, every minute, whether or not
you are here. Its key can create agents and run their jobs; it can never move your funds. (You can also
run one yourself: runner/tools/serve.ts.)
What it may spend
These become the grant. Once it exists they cannot be raised — not by the agent, the runner, or you. A new grant is the only way to change them.
letters, digits, - and _
after that, what is left is yours to take back
Who it may pay
One address per line. This list is compiled into the grant and can never be added to.
The first line is the Warda demo vendor, so the agent has something to buy. The runner adds its own fee address; nothing else can ever be paid.
Your key
It can stop the grant at any moment and takes back whatever is left. It never leaves your wallet; the runner only learns its public half.
Connect a Kaspa wallet, or paste your Kaspa address.
Fund it
Send exactly this, in one payment, from any Kaspa wallet or exchange.
The one moment you trust us. The runner turns your payment into the grant in a single transaction. All of it goes into the grant, and the grant’s stop-and-reclaim key is yours. Between your payment arriving and that transaction confirming — usually under a minute — the runner controls the deposit. After that, it cannot take a single sompi back out.
No KAS? Pay with USDC or USDT from Base, Ethereum, Arbitrum and more — it is swapped to KAS and lands at this deposit address in one payment.
Waiting for your payment…
Give it a job
Say it in a sentence. You get a card to check before anything is added — and whatever you write, it can only ever do what the grant allows.
Or pick a template
Tell me on Telegram
Low budgets, a grant about to end, anything that needs your signature — to your phone. The bot can only send you messages; it can never move your funds.
Let the agent pay by itself
Paste this into Claude, Cursor or any MCP client. The agent can then check its authority and pay inside its grant — with a key it never sees.
What it has done
What the network will enforce
- Agent
- —
- Total it may ever spend
- —
- Any single payment
- —
- Term
- —
- Who it may pay
- —
- Stopped and reclaimed by
- —
not created yet
Who holds what
The runner holds the agent’s key (in Turnkey), which can only pay inside these limits, and a one-time deposit key that can only create this grant or send your deposit back to you. You hold the key that stops the grant and takes back what is left. Nobody can raise a limit.
Operator
The hosted runner from the inside: who uses it, how their runs go, what is failing, and what it has
earned. Read from the runner’s own records, not the chain. Needs the runner’s admin secret
(RUNNER_ADMIN_SECRET in runner/.env), kept in this browser only.
Runs per day
ok refused failed or stuck skipped, missed, undecided
Agents
| Agent | Account | Funding | Left of budget | Jobs | Runs ok / failed / refused | Last run | Fees settled · owed | Last problem |
|---|
Problems
Accounts
| Account | Since | Agents | Telegram |
|---|
Your agents
Every agent the runner hosts for you: what it may still spend, what it does, and what it last did. Pausing a job is instant. Stopping the grant itself takes your key, and only yours.
Agents
RefreshSpending
Waiting for you
Statement
Every payment this agent made in a month — date, job, what it bought, amount, transaction — and the runner’s fees. For your records or your accountant.
Public receipt
A page anyone can open: what this agent bought, what it was refused, and what it may still spend — each figure checkable on the chain. Share it to show a client, a partner, or the world that your agent stayed inside its limits. Off until you turn it on.
Sub-agents
Give a helper part of this agent’s budget. It gets its own key, jobs and limits — never more than you hand it, never more per payment than this agent may pay, paying only the same payees — and every Kaspa node enforces the split. Your keys own both, so you can stop either.
Top up or renew
A grant’s budget and end date are fixed when it is made, so more money or more time is a new grant for the same agent: same key, same jobs, same payees, your keys as its owner. Send the deposit and the runner switches over; the current grant keeps working until then.
Jobs
Templates
RefreshJobs other people found useful. One click adds one to this agent; it is checked against this agent’s own limits first. Share yours with Share as template on any job above — your chat and private URLs are never included.
What it has done
Stopping it for good
The runner cannot end a grant — by design, it never holds the key that can. Your key can, at any moment, and the balance comes back to you: