Kyrona

Kyrona is a spending desk for a NEAR account. You name who you pay, set a cap per payment and a cap per day, and lock spending when you want everything to stop. For NEAR, those rules live on rules.sithunyein.near. A payment has to call pay. The contract checks the list, the lock, and the caps, and only then sends the NEAR. A payment outside the rules can be asked for with request instead: it waits on the rules account until you approve or reject it, and nothing moves before that.

The point is that the AI does not have to behave. On 10 November 2026 an AI agent on NEAR AI Cloud read an invoice with a hidden instruction and obeyed it: it tried to pay 5 NEAR to outside.near, and the contract refused. It then filed a request with a note claiming the owner had pre-approved it, and the owner rejected it on the desk. Nothing reached outside.near. The whole run is in An AI agent, told to pay someone else, and every check can be repeated without a wallet in Check it yourself. The demo video shows the same run in 90 seconds.

The problem

Sending NEAR is easy. Sending the wrong amount, to an account you did not mean, is also easy. A wallet asks you to approve a transaction. It does not know your daily budget, your list of people, or that you wanted spending frozen.

Kyrona sits in front of that approval. Once the rules are on their own account, pay still checks them even if the page is skipped.

NEAR lets a function-call key be limited to named methods on one contract. The payment program holds a key scoped to pay and request on the rules account, so it cannot transfer NEAR, add a key, deploy code, change the rules, or approve its own requests. That limit is enforced by the chain, not by the page.

How a payment moves

sequenceDiagram
  actor You
  participant Desk as Kyrona
  participant Chain as NEAR mainnet
  participant Rules as Rules account

  You->>Desk: Person, asset, amount
  Desk->>Chain: Read the balance and the rules
  alt A check fails
    Desk-->>You: Do not send
    Note over Desk: Nothing is signed
  else NEAR, and the rules account exists
    Desk->>Rules: pay, signed by the limited key or the wallet
    Rules->>Rules: List, lock, caps
    Rules->>Chain: Transfer
    Chain-->>Desk: Transaction hash
  else NEAR, outside the rules
    Desk->>Rules: request, signed by the limited key
    Note over Rules: Waits. Nothing moves
    You->>Rules: approve or reject, signed by your wallet
  else USDC, or no rules account yet
    Desk->>Chain: Wallet signs the transfer
    Chain-->>Desk: Transaction hash
  end

The checks, in order:

Check	Pass means
Spending lock	The desk is open
Asset	NEAR or USDC is allowed
Recipient	The account is on your list
Per payment	The amount is within that cap
Today	Today’s total would still be within the daily cap
Balance	The chain balance covers it

On the rules account, pay repeats the lock, the list, and both caps. If a transfer fails on the way, the NEAR comes back and is taken off today's total. USDC does not go through pay.

Check it yourself, no wallet

npm run judge

This starts a local NEAR node (nearcore 2.14.0, downloaded on the first run) and deploys contract/v1/kyrona-v1.wasm, the exact code on rules.sithunyein.near, the same way the desk does. It upgrades that account in place to public/kyrona.wasm and gives an agent a key that may only call pay and request. Then the agent tries to break the rules. No wallet, no keys and no funds are needed. It needs Node 20 or newer on Linux x86_64 or Apple Silicon macOS; on Windows, run it in WSL. If you cannot run the local node, the same command runs on a clean GitHub machine for every commit: open the latest Judge run, and the annotations on its summary page list each line of the table below as it happened. The CI workflow also runs what a reviewer runs after cloning: npm ci, npm test, npm run build, and npm run dev answering on port 8080. After npm install at the root, the run also uses scripts/upgrade.mjs and scripts/agent.mjs, the programs that run on mainnet, against the local node.

What you should see (the run exits 1 if any line differs):

여기까지가 README 앞부분입니다. 나머지는 원문에서 읽을 수 있습니다. README 전문 보기 ↗