Overview
Every grant this project has issued, what it spent, and what the covenant would not let it do.
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 | 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.
Notices
Derived from the readings on this page, every one of them checkable against the row it came from.
Recent activity
All →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.
Every grant —
| Agent | Budget | Spent | Left | On chain | Per payment | Per epoch | Payees | Depth | State |
|---|
Two numbers can end an agent, and the smaller one is the answer. Left is what the covenant would still permit; on chain 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.
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
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.
—
Sent at the top of the message. Yours, not generated.
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.
—
—
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.
—
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
—
Where it runs
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.
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.
—
—
—
after that the balance is the principal’s to reclaim
Two rates, and they are not the same number. Yours sizes the grant, because it is the one you actually traded at — Warda never fetches it. The market figure carries a source and a time, and nothing is ever enforced against it.
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.