Docs

Most wallets answer one question: can this transaction be signed? NFA is built around a second one: should it run right now? You write rules while you are calm; the system holds you to them when you are not, and leaves an auditable record of what happened.

It is made of three systems that work together:

1. 01

   Connect a wallet

   Open the app and connect a browser wallet. This is read-only: the app only asks for your address. Nothing is signed or sent.

2. 02

   Start from zero

   Your address gets its own simulated account, saved in this browser. It begins empty, with default guardrails.

3. 03

   Add simulated test funds

   On the Overview, press Add simulated test funds. These are not real tokens; they exist only in the simulation. More options are under Simulation controls in the top bar.

4. 04

   Look at your rules

   Open Guardrails. Try lowering the daily cap (applies at once) and raising it (becomes a pending change for 24 hours).

5. 05

   Propose an action

   On Sleep queue, propose a swap. Below your max trade value it executes; above it, it waits ten minutes. The right-hand panel shows the verdict before you submit.

6. 06

   Move time forward

   Waiting ten minutes or a day is not necessary. Open Simulation controls and advance the clock to unlock a queued action or let a delayed rule change take effect.

7. 07

   Read the receipt

   Each executed swap appears in Receipts. Open one, then download it as an SVG file.

Every guardrail change is classified before it is applied. Tightening applies immediately. Loosening creates a pending change that takes effect after the loosening delay (24 hours by default). While a change is pending, that rule cannot be edited again until the change is applied or canceled.

How changes are classified

• Numbers. A stricter value is a tightening: a lower max trade, a lower cap, a longer cooldown, a longer delay. A co-signer threshold of 0 means “off” and is the loosest setting.
• Allow lists. An empty allow list is not enforced. Adding the first entry, or removing entries, tightens. Adding entries, or clearing the list, loosens.
• Deny lists. Adding entries tightens; removing entries loosens.
• Guardian. Setting one where there was none tightens. Changing or removing it loosens, because it weakens oversight.
• Mixed edits. Adding and removing in one list edit cannot be compared safely, so it loosens.

An action goes to the queue instead of executing if its value is above your max trade value, or if it was proposed by an agent in ask-first mode. A queued action records the account, chain ID, a nonce, the target, value, calldata and the calldata’s SHA-256 hash, plus its unlock and expiry times.

Queued actions cannot be edited. To change one, cancel it and queue a new action. At execution the rules run again, so a revoked agent, a newly denied target, a cooldown, a missing co-signer approval or a freeze can still block it.

An agent is an autonomous signer (an EOA, or a contract account verified through EIP-1271 in a real deployment). Each permission defines:

• allowed target contracts and allowed function selectors;
• a per-action cap and a rolling 24-hour cap (in a normalized USD reference);
• an expiry (1–90 days) — every permission must expire;
• optional ask-first mode, which routes every action to your queue.

You can edit an active agent, or revoke it instantly. Revoking also invalidates that agent’s queued proposals.

The decision record

An agent action is rejected unless it carries a decision record with a reasonHash (or reasoning text to hash), a reasonURI and a model identifier. Limits apply: URI up to 200 characters starting with ipfs://, https:// or ar://; model up to 64; reasoning text up to 4,000.

When you give text, the hash is a real SHA-256 computed locally in your browser. A hash that does not match its text is rejected. Nothing is uploaded anywhere.

A receipt is produced only after a successful simulated swap. It captures the smart account, owner, optional agent, input and output assets and amounts, the entry price and its quality, a timestamp, a simulated block, an indicative return and a holding-time label. Balance snapshots before and after must match the amounts exactly, or no receipt is created.

Indicative return compares the entry price with the current price, and is shown only when the entry quote and both current price legs are fresh. If a source degrades later, the return disappears from existing receipts. Return bands: below −5%, −1% to −5%, within ±1%, +1% to +5%, above +5%. Holding labels: FRESH (under an hour), SHORT (under a day), MEDIUM (under a week), LONG (a week or more).

Every receipt can be downloaded as a standalone SVG file with its background photograph embedded. Receipts are not minted tokens and the transactions are not confirmed onchain.

The score is replayed day by day from the moment your rules were first set. Each completed day extends your streak only if your rules were meaningfully strict and no loosening took effect that day.

target = 100 × (0.25·age + 0.4·streak + 0.35·strictness)

age, streak   = 0 below 7 days; then (days − 7) / 53, capped at 1
strictness    = clamp((ratio − 1) / (2× − 1)); 0 until rules are 7 days old
ratio         = geometric mean of: baseline max trade ÷ yours, baseline daily cap ÷ yours, yours ÷ baseline cooldown
baseline      = 8,000 max trade · 32,000 daily cap · 5 minute cooldown

each completed day:  score = min(target, previous + 2)
a loosening taking effect resets the streak and drops the score to the new, lower target at once

Engaging panic does four things at once: it revokes every active agent, cancels every pending or ready queued action, freezes governed execution and starts a recovery countdown (24 hours by default). Panic never consults prices, so it works even when every price source is down. It is neutral for the Discipline Score. Rules can still be tightened while frozen.

Recovery unfreezes the account but does not silently restore agents. Revoked agents must be granted again.

1. 01

   Panic

   A frozen account rejects everything.

2. 02

   Input

   Amount above zero, valid target address, a 4-byte selector, known tokens.

3. 03

   Agent checks

   The agent exists, is not revoked or expired; the target and selector are allowed; a valid decision record; the value is priced; per-action cap; rolling daily cap.

4. 04

   Account lists

   Denied targets and tokens, then allow lists (an empty allow list is not enforced).

5. 05

   Valuation

   A needed price that is not fresh rejects the action with PRICE_UNAVAILABLE. A missing price is never treated as zero.

6. 06

   Routing

   An ask-first agent, or a value above the max trade value, sends the action to the queue.

7. 07

   Execution-time rules

   Cooldown, rolling 24-hour volume cap, the output price, balance, and — above the threshold — a matching, unexpired, unused guardian approval.

The verdict is one of allowed, queued, rejected or needs-guardian, with a stable reason code and a human-readable explanation. The composer on the Sleep queue page shows the same verdict live, using the same function the engine uses.

Simulated guardian approvals

An approval is an explicit record, not a cryptographic signature. It stores the account, a commitment (a SHA-256 hash of the exact action), the signer, a nonce, a 30-minute deadline and a consumed flag. It is valid only for that exact action, once, before its deadline, while the signer is still the configured guardian. Real EIP-712 / EIP-1271 verification belongs to the future contract integration.

All logic lives in pure functions: reduce(state, action) returns a new state and a typed result, never mutating its input and never reading the wall clock or randomness. A single store holds the state and every screen reads it, so a revoked agent, a canceled queue item or a new receipt shows up everywhere at once.

Time is simulated. Open Simulation controls in the top bar to advance one minute, ten minutes, an hour, a day or a week, run the clock at 1×, degrade a mock price source to see how unreliable prices are handled, add simulated test funds, load an example dataset, or reset the account to empty.

Block numbers advance with simulated time. Prices come from a swappable price-source interface with fixed mock values; fresh sources re-poll on every tick, degraded ones stay degraded until you change them.

The app asks your browser wallet for the account address (EIP-1193 eth_requestAccounts) and nothing more: no signature requests, no transactions, no chain switching, no token approvals and no balance reads. Your address is used as a local key for your own simulated account.

• Each address gets its own account, stored in this browser’s localStorage, starting from zero.
• Disconnecting returns you to the gate; reconnecting the same address restores that account.
• There is no server, no analytics and no network call by the application.
• Clearing site data deletes everything.

The planned system uses ERC-4337 smart accounts with ERC-7579 modules that enforce the guardrails onchain. A user or agent submits an operation; validation and policy modules evaluate it; it is then queued or executed against a supported target; verified trades mint a receipt; and discipline state follows from rule events.

The prototype mirrors this flow in software so the product can be designed and tested before any contract exists. See BACKEND_INTEGRATION.md in the repository for how each simulated part maps to a real component.

Risks a real implementation must solve

• Module uninstall or downgrade: removing protections must itself be delayed and guardian-gated.
• Execution bypass: direct EOA signing, alternative modules, delegatecall and third-party approvals defeat guardrails unless the account architecture prevents them.
• Oracle manipulation and staleness for value-based limits, and slippage.
• Guardian compromise or collusion, and griefing by withholding approvals.
• Replay of approvals across accounts or chains: production needs full domain separation.
• Frontend trust: a malicious frontend can mislead users; contracts must stand on their own.

NFA does not predict prices, promise returns, or offer staking, prediction markets or token sales. Nothing here is financial, investment, legal or security advice.

No partners, audits, metrics, funding or deployed addresses are claimed anywhere on this site, because none exist yet.

Nothing in this project is financial, investment, legal or security advice.