@aqb-foundation/aqb-agent 1.0.0 → 1.0.2

package/docs/articles/01-payment-rail-agents.md

@@ -0,0 +1,55 @@
+---
+title: A payment rail your agent can find without you
+published: false
+tags: ai, agents, web3, base
+---
+
+Most "AI + crypto" projects are built for a human with a wallet and a browser tab. An agent has neither. It has an HTTP client, a JSON parser, and a task.
+
+So the first thing AQB ships is not a landing page — it is `/.well-known/agent-coin.json`.
+
+```
+curl -s https://yss787976-ai.github.io/agent-coin/.well-known/agent-coin.json
+```
+
+That returns chain id, token, vault, registry and pool addresses, plus a card hash the agent can verify. No sign-up, no dashboard, no email.
+
+## Why an agent needs a token at all
+
+Agent-to-agent work has a settlement problem. Cards need a human. Bank rails need KYC. Most stablecoins assume a person holds the keys.
+
+AQB is a fixed-supply (900e9) ERC-20 on Base where every unit is backed 1:1 by USDC sitting in an on-chain vault. Minting happens against deposited USDC, redemption burns the token and returns the USDC. There is no oracle and no algorithmic peg to break.
+
+Transfers are gated: a token transfer only succeeds to a registered agent or a whitelisted pool. That keeps the holder set machine-shaped instead of becoming a wallet-dust collection.
+
+## Post-quantum by default
+
+Harvest-now-decrypt-later is a real risk for long-lived agent identities. Registration uses ML-DSA-65 (FIPS 204) keys; payers are derived as ML-KEM-768 stealth addresses, so a payment does not leak a static receiving key. An ECDSA fallback path exists so agents on ordinary wallets are not locked out.
+
+## The loop
+
+```bash
+npx -y @aqb-foundation/aqb-agent --help          # tools
+npx @aqb-foundation/aqb-agent register --pq      # once
+npx @aqb-foundation/aqb-agent pay --to 0xAGENT --amount 0.25 --memo "ocr batch"
+npx @aqb-foundation/aqb-agent redeem --amount 0.25
+```
+
+The same tools are exposed over MCP:
+
+```json
+{ "mcpServers": { "aqb": { "command": "npx", "args": ["-y", "@aqb-foundation/aqb-agent", "mcp"] } } }
+```
+
+It is listed in the official MCP registry as `io.github.yss787976-ai/aqb-agent`.
+
+## What is honest about it so far
+
+- Liquidity is small (a few hundred dollars). Treat it as a working rail, not a market.
+- Contracts are source-verified on BaseScan and Sourcify, MIT, 6 of them, but the project is days old.
+- There is no fiat off-ramp. USDC in, USDC out.
+
+If your agent pays for API calls, OCR, translation or compute, the interesting part is not the token — it is that discovery, payment and redemption all fit in one script with no human in the loop.
+
+Repo: https://github.com/yss787976-ai/agent-coin
+Discovery: https://yss787976-ai.github.io/agent-coin/for-agents/

package/docs/articles/01.body

@@ -0,0 +1,56 @@
+title: A payment rail your agent can find without you
+published: false
+tags: ai, agents, web3, base
+---
+
+Most "AI + crypto" projects are built for a human with a wallet and a browser tab. An agent has neither. It has an HTTP client, a JSON parser, and a task.
+
+So the first thing AQB ships is not a landing page — it is `/.well-known/agent-coin.json`.
+
+```
+curl -s https://yss787976-ai.github.io/agent-coin/.well-known/agent-coin.json
+```
+
+That returns chain id, token, vault, registry and pool addresses, plus a card hash the agent can verify. No sign-up, no dashboard, no email.
+
+## Why an agent needs a token at all
+
+Agent-to-agent work has a settlement problem. Cards need a human. Bank rails need KYC. Most stablecoins assume a person holds the keys.
+
+AQB is a fixed-supply (900e9) ERC-20 on Base where every unit is backed 1:1 by USDC sitting in an on-chain vault. Minting happens against deposited USDC, redemption burns the token and returns the USDC. There is no oracle and no algorithmic peg to break.
+
+Transfers are gated: a token transfer only succeeds to a registered agent or a whitelisted pool. That keeps the holder set machine-shaped instead of becoming a wallet-dust collection.
+
+## Post-quantum by default
+
+Harvest-now-decrypt-later is a real risk for long-lived agent identities. Registration uses ML-DSA-65 (FIPS 204) keys; payers are derived as ML-KEM-768 stealth addresses, so a payment does not leak a static receiving key. An ECDSA fallback path exists so agents on ordinary wallets are not locked out.
+
+## The loop
+
+```bash
+npx -y @aqb-foundation/aqb-agent --help          # tools
+npx @aqb-foundation/aqb-agent register --pq      # once
+npx @aqb-foundation/aqb-agent pay --to 0xAGENT --amount 0.25 --memo "ocr batch"
+npx @aqb-foundation/aqb-agent redeem --amount 0.25
+```
+
+The same tools are exposed over MCP:
+
+```json
+{ "mcpServers": { "aqb": { "command": "npx", "args": ["-y", "@aqb-foundation/aqb-agent", "mcp"] } } }
+```
+
+It is listed in the official MCP registry as `io.github.yss787976-ai/aqb-agent`.
+
+## What is honest about it so far
+
+- Liquidity is small (a few hundred dollars). Treat it as a working rail, not a market.
+- Contracts are source-verified on BaseScan and Sourcify, MIT, 6 of them, but the project is days old.
+- There is no fiat off-ramp. USDC in, USDC out.
+
+If your agent pays for API calls, OCR, translation or compute, the interesting part is not the token — it is that discovery, payment and redemption all fit in one script with no human in the loop.
+
+Repo: https://github.com/yss787976-ai/agent-coin
+Discovery: https://yss787976-ai.github.io/agent-coin/for-agents/
+
+

package/docs/articles/02-gated-transfers.md

@@ -0,0 +1,36 @@
+A payment rail for agents has one requirement most chains ignore: the holder set must be machines. A token that anyone can dust is a token whose balance sheet is mostly human wallets that will never spend it.
+
+AQB gates transfers. A `transfer` only lands if the recipient is a registered agent or a whitelisted pool. Everything else reverts.
+
+## What registration actually is
+
+`AgentRegistry.register(pqKeyHash, cardHash)` stores an agent record and emits `Registered`. Two rules matter:
+
+- The caller must be a contract that exposes `pqKeyHash()`, so a plain EOA cannot register itself. You deploy an agent account first.
+- The key hash must match what the account reports, so you cannot register someone else's identity.
+
+`PQSmartAccount` holds an ML-DSA-65 public key and derives `pqKeyHash = keccak256(pubKey)`. Authority is the key commitment, not an owner address. An ECDSA fallback key exists for wallets that cannot sign PQ yet — it can execute, but it cannot mint, freeze, or seize.
+
+## Why gate at all
+
+Three concrete effects:
+
+1. **No dust.** Airdrops to random addresses are impossible by construction, so the holder count means "agents that did work" rather than "wallets that received something".
+2. **Payments are typed.** A transfer has a counterparty that passed a key check, which is a stronger signal than an address that once received a token.
+3. **Stealth payments still work.** Payers derive fresh ML-KEM-768 addresses per payment, so a payee does not expose a static receiving key while still being gated.
+
+## The cost
+
+Gating breaks the "paste any address" habit. If an agent wants to pay a stranger, the stranger must register first. In practice: `register` is one transaction, cheap on Base, and the SDK does it in one call.
+
+```bash
+npx @aqb-foundation/aqb-agent register --pq
+npx @aqb-foundation/aqb-agent pay --to 0xAGENT --amount 0.25 --memo "ocr batch"
+```
+
+## Redemption is not gated in the same way
+
+Burn 1 AQB, receive 1 USDC from the vault — that path is open because it is the peg, not a transfer of value between agents. A holder that stops being an agent can always exit.
+
+Contracts, tests and the registry are public: https://github.com/yss787976-ai/agent-coin
+Discovery: https://agentqubit.pages.dev/.well-known/agent-coin.json

package/docs/articles/03-peg-without-oracle.md

@@ -0,0 +1,33 @@
+# Peg without an oracle: the vault, not a price feed
+
+Most stablecoin designs ask: what tells the contract the price? AQB answers: nothing has to. Redemption is a fixed ratio, not a quote.
+
+## The mechanism
+
+- Depositing USDC calls `genesisMint` (or the sale), and supply grows by exactly the deposited amount.
+- Burning AQB calls `redeem`, which returns the same amount of USDC from the vault.
+- `backedSupply` and `collateralRatio` are on-chain, public, and read in one `eth_call`.
+
+There is no feed to front-run, no stale price, no funding-rate equivalent. If the vault has 250 USDC, then 250 AQB is redeemable — always, in full, in any order.
+
+## What can break
+
+Honesty about the edges:
+
+1. **The vault can be drained by redemption.** That is the design: redeemers exit at 1:1 and the remaining supply stays redeemable only while USDC lasts. Since supply is minted *against* deposits, this holds unless someone mints without backing (they cannot — mint is gated to the deposit path).
+2. **Market price can drift below 1.** Nothing stops a pool from trading at 0.97. That is an arbitrage invitation, not a broken peg: buy at 0.97, redeem at 1.00.
+3. **Base can stall.** L2 sequencer downtime delays redemption, but does not change amounts.
+
+## Why not algorithmic
+
+Algorithmic pegs fail in the direction of confidence: the moment holders doubt, the mechanism needs more confidence than it has. A fully collateralized vault fails only if the collateral asset fails, and here the collateral is USDC held by the token contract itself.
+
+```solidity
+function redeem(uint256 amount) external returns (uint256) {
+    // burns AQB, sends the same amount of USDC
+}
+```
+
+Read the contract rather than this post: https://basescan.org/token/0x2C54F202B565086B6d8D2226Edb67AC3E14C39d1
+
+Discovery for agents: https://agentqubit.pages.dev/.well-known/agent-coin.json

package/docs/articles/04-discovery-over-landing.md

@@ -0,0 +1,42 @@
+# A discovery file beats a landing page
+
+An agent does not browse. It has an HTTP client and a task: find something that accepts payment. If your project needs a human to read a site and copy an address, the agent will pick a competitor that returns JSON.
+
+So the first artifact AQB ships is not a page, it is `/.well-known/agent-coin.json`.
+
+## What a discovery file must contain
+
+A machine needs five things, and nothing else:
+
+- chain id, so it does not bridge by accident
+- token address + decimals
+- registry address, so it can check a counterparty is a real agent
+- vault address, so it can verify redemption is possible
+- an identity scheme, so it knows how to become an agent
+
+Here is ours, abridged:
+
+```json
+{
+  "chainId": 8453,
+  "token": "0x2C54...",
+  "registry": "0xAa96...",
+  "pq": "ML-DSA-65",
+  "discover": "https://agentqubit.pages.dev/.well-known/agent-coin.json"
+}
+```
+
+## Rules that made the difference
+
+1. **200 without auth.** No key, no signup, no cookies. An agent with no wallet must still read it.
+2. **Stable path.** `/.well-known/` by convention, and mirrored in `llms.txt`, `agents.json` and a sitemap so the path is crawlable from four directions.
+3. **No marketing copy inside the file.** Numbers and addresses; prose lives in the human page.
+4. **Idempotent facts only.** Anything that changes daily (price, volume) is left out, so cached copies never mislead.
+
+## What this changes for the operator
+
+A landing page answers "is this legit?" for a person. A discovery file answers "can I pay right now?" for a program. They are different documents, and mixing them produces something bad at both.
+
+Write the machine one first. It is also the cheapest possible form of distribution: it costs one file and works while you sleep.
+
+Full example: https://agentqubit.pages.dev/for-agents/

package/docs/articles/04-discovery-over-landing.md.body

@@ -0,0 +1,40 @@
+An agent does not browse. It has an HTTP client and a task: find something that accepts payment. If your project needs a human to read a site and copy an address, the agent will pick a competitor that returns JSON.
+
+So the first artifact AQB ships is not a page, it is `/.well-known/agent-coin.json`.
+
+## What a discovery file must contain
+
+A machine needs five things, and nothing else:
+
+- chain id, so it does not bridge by accident
+- token address + decimals
+- registry address, so it can check a counterparty is a real agent
+- vault address, so it can verify redemption is possible
+- an identity scheme, so it knows how to become an agent
+
+Here is ours, abridged:
+
+```json
+{
+  "chainId": 8453,
+  "token": "0x2C54...",
+  "registry": "0xAa96...",
+  "pq": "ML-DSA-65",
+  "discover": "https://agentqubit.pages.dev/.well-known/agent-coin.json"
+}
+```
+
+## Rules that made the difference
+
+1. **200 without auth.** No key, no signup, no cookies. An agent with no wallet must still read it.
+2. **Stable path.** `/.well-known/` by convention, and mirrored in `llms.txt`, `agents.json` and a sitemap so the path is crawlable from four directions.
+3. **No marketing copy inside the file.** Numbers and addresses; prose lives in the human page.
+4. **Idempotent facts only.** Anything that changes daily (price, volume) is left out, so cached copies never mislead.
+
+## What this changes for the operator
+
+A landing page answers "is this legit?" for a person. A discovery file answers "can I pay right now?" for a program. They are different documents, and mixing them produces something bad at both.
+
+Write the machine one first. It is also the cheapest possible form of distribution: it costs one file and works while you sleep.
+
+Full example: https://agentqubit.pages.dev/for-agents/

package/docs/articles/04-discovery-over-landing.md.title

@@ -0,0 +1 @@
+# A discovery file beats a landing page

package/docs/articles/05-identity-survives-key.md

@@ -0,0 +1,27 @@
+# Agent identity should survive a key, not an address
+
+Every wallet-bound identity has the same flaw: the address is the identity, so losing the key loses the account, and holding the key means holding the authority. For a long-lived agent that is a single point of failure with no recovery story.
+
+AQB separates the two.
+
+## Key commitment, not owner
+
+A `PQSmartAccount` stores an ML-DSA-65 public key and exposes `pqKeyHash = keccak256(pubKey)`. That hash is the authority. Any signature from the matching secret key can execute calls on the account.
+
+There is no owner field to hijack, and no admin function to freeze funds. A rotation function replaces the key commitment; after rotation the old key is dead and the address is unchanged. Agents keep their history, their balances, and their registry record.
+
+## The fallback is explicit
+
+An ECDSA key is also stored, and signatures carry a scheme byte: `0x01` for ECDSA, `0x02` for ML-DSA. The fallback exists for the period where an agent runs on ordinary tooling and cannot sign PQ. It can execute, it cannot rotate itself into power silently — a rotation still needs the PQ key or the fallback plus a rotation call.
+
+## Why post-quantum now
+
+Harvest-now-decrypt-later means signatures made today are stored and attacked later. Agent identities are long-lived by design, which is exactly the profile that ages worst under a quantum break. Migrating later means every agent rotates and re-registers; starting there costs one extra key at registration.
+
+## Practical notes
+
+- Key material is 1952 bytes public / 4032 bytes secret; the SDK stores it as hex and never logs it.
+- Signature blobs are 3309 bytes, so they are calldata-heavy. On Base that is still cents.
+- Stealth payments use a separate ML-KEM-768 key, so paying an agent does not expose its signing key.
+
+Registry: https://basescan.org/address/0xAa964f6ea767f0D709b268abBFdd8B6C2Beef3eB

package/docs/articles/05-identity-survives-key.md.body

@@ -0,0 +1,25 @@
+Every wallet-bound identity has the same flaw: the address is the identity, so losing the key loses the account, and holding the key means holding the authority. For a long-lived agent that is a single point of failure with no recovery story.
+
+AQB separates the two.
+
+## Key commitment, not owner
+
+A `PQSmartAccount` stores an ML-DSA-65 public key and exposes `pqKeyHash = keccak256(pubKey)`. That hash is the authority. Any signature from the matching secret key can execute calls on the account.
+
+There is no owner field to hijack, and no admin function to freeze funds. A rotation function replaces the key commitment; after rotation the old key is dead and the address is unchanged. Agents keep their history, their balances, and their registry record.
+
+## The fallback is explicit
+
+An ECDSA key is also stored, and signatures carry a scheme byte: `0x01` for ECDSA, `0x02` for ML-DSA. The fallback exists for the period where an agent runs on ordinary tooling and cannot sign PQ. It can execute, it cannot rotate itself into power silently — a rotation still needs the PQ key or the fallback plus a rotation call.
+
+## Why post-quantum now
+
+Harvest-now-decrypt-later means signatures made today are stored and attacked later. Agent identities are long-lived by design, which is exactly the profile that ages worst under a quantum break. Migrating later means every agent rotates and re-registers; starting there costs one extra key at registration.
+
+## Practical notes
+
+- Key material is 1952 bytes public / 4032 bytes secret; the SDK stores it as hex and never logs it.
+- Signature blobs are 3309 bytes, so they are calldata-heavy. On Base that is still cents.
+- Stealth payments use a separate ML-KEM-768 key, so paying an agent does not expose its signing key.
+
+Registry: https://basescan.org/address/0xAa964f6ea767f0D709b268abBFdd8B6C2Beef3eB

package/docs/articles/05-identity-survives-key.md.title

@@ -0,0 +1 @@
+# Agent identity should survive a key, not an address

package/docs/articles/06-what-an-agent-needs.md

@@ -0,0 +1,30 @@
+# What an agent actually needs from a stablecoin
+
+Strip the branding. An agent paying another agent needs four properties, and everything else is decoration:
+
+1. **Deterministic value.** The payee must know what it received without a price feed. A fixed redemption ratio gives that; a floating quote does not.
+2. **Cheap settlement.** If gas exceeds the payment, small jobs are impossible. Base makes a transfer cost a fraction of a cent.
+3. **Machine-checkable counterparty.** Before paying, the payer wants proof the recipient is an agent and not a typo. A registry call does this in one round trip.
+4. **Exit without permission.** Whatever happens, the holder must be able to convert back. Redemption against a vault, callable by anyone, is that.
+
+AQB is shaped by those four and nothing else. 1 AQB redeems for 1 USDC from an on-chain vault; transfers land only on registered agents or whitelisted pools; gas on Base is negligible; the registry and the vault are both public contracts.
+
+## What it deliberately does not do
+
+- No yield, no staking, no governance votes. Agents do not attend meetings.
+- No human checkout. Buying happens with USDC on a pool, or not at all.
+- No cross-chain bridge. One chain, one canonical contract, less state to be wrong about.
+
+## How to evaluate it in five minutes
+
+```bash
+curl -s https://agentqubit.pages.dev/.well-known/agent-coin.json
+```
+
+Then read `collateralRatio()` on the token contract. If it is 1e18, every outstanding unit is redeemable. If it drifts below, minting stopped being collateralized first.
+
+## The honest part
+
+Liquidity is thin, the project is new, and there is no fiat on-ramp inside the product. It is a working rail for small machine payments, not a treasury asset. Judge it that way.
+
+Discovery: https://agentqubit.pages.dev/.well-known/agent-coin.json

package/docs/articles/06-what-an-agent-needs.md.body

@@ -0,0 +1,28 @@
+Strip the branding. An agent paying another agent needs four properties, and everything else is decoration:
+
+1. **Deterministic value.** The payee must know what it received without a price feed. A fixed redemption ratio gives that; a floating quote does not.
+2. **Cheap settlement.** If gas exceeds the payment, small jobs are impossible. Base makes a transfer cost a fraction of a cent.
+3. **Machine-checkable counterparty.** Before paying, the payer wants proof the recipient is an agent and not a typo. A registry call does this in one round trip.
+4. **Exit without permission.** Whatever happens, the holder must be able to convert back. Redemption against a vault, callable by anyone, is that.
+
+AQB is shaped by those four and nothing else. 1 AQB redeems for 1 USDC from an on-chain vault; transfers land only on registered agents or whitelisted pools; gas on Base is negligible; the registry and the vault are both public contracts.
+
+## What it deliberately does not do
+
+- No yield, no staking, no governance votes. Agents do not attend meetings.
+- No human checkout. Buying happens with USDC on a pool, or not at all.
+- No cross-chain bridge. One chain, one canonical contract, less state to be wrong about.
+
+## How to evaluate it in five minutes
+
+```bash
+curl -s https://agentqubit.pages.dev/.well-known/agent-coin.json
+```
+
+Then read `collateralRatio()` on the token contract. If it is 1e18, every outstanding unit is redeemable. If it drifts below, minting stopped being collateralized first.
+
+## The honest part
+
+Liquidity is thin, the project is new, and there is no fiat on-ramp inside the product. It is a working rail for small machine payments, not a treasury asset. Judge it that way.
+
+Discovery: https://agentqubit.pages.dev/.well-known/agent-coin.json

package/docs/articles/06-what-an-agent-needs.md.title

@@ -0,0 +1 @@
+# What an agent actually needs from a stablecoin

package/docs/articles/body.json

@@ -0,0 +1 @@
+"\nMost \"AI + crypto\" projects are built for a human with a wallet and a browser tab. An agent has neither. It has an HTTP client, a JSON parser, and a task.\n\nSo the first thing AQB ships is not a landing page — it is `/.well-known/agent-coin.json`.\n\n```\ncurl -s https://yss787976-ai.github.io/agent-coin/.well-known/agent-coin.json\n```\n\nThat returns chain id, token, vault, registry and pool addresses, plus a card hash the agent can verify. No sign-up, no dashboard, no email.\n\n## Why an agent needs a token at all\n\nAgent-to-agent work has a settlement problem. Cards need a human. Bank rails need KYC. Most stablecoins assume a person holds the keys.\n\nAQB is a fixed-supply (900e9) ERC-20 on Base where every unit is backed 1:1 by USDC sitting in an on-chain vault. Minting happens against deposited USDC, redemption burns the token and returns the USDC. There is no oracle and no algorithmic peg to break.\n\nTransfers are gated: a token transfer only succeeds to a registered agent or a whitelisted pool. That keeps the holder set machine-shaped instead of becoming a wallet-dust collection.\n\n## Post-quantum by default\n\nHarvest-now-decrypt-later is a real risk for long-lived agent identities. Registration uses ML-DSA-65 (FIPS 204) keys; payers are derived as ML-KEM-768 stealth addresses, so a payment does not leak a static receiving key. An ECDSA fallback path exists so agents on ordinary wallets are not locked out.\n\n## The loop\n\n```bash\nnpx -y @aqb-foundation/aqb-agent --help          # tools\nnpx @aqb-foundation/aqb-agent register --pq      # once\nnpx @aqb-foundation/aqb-agent pay --to 0xAGENT --amount 0.25 --memo \"ocr batch\"\nnpx @aqb-foundation/aqb-agent redeem --amount 0.25\n```\n\nThe same tools are exposed over MCP:\n\n```json\n{ \"mcpServers\": { \"aqb\": { \"command\": \"npx\", \"args\": [\"-y\", \"@aqb-foundation/aqb-agent\", \"mcp\"] } } }\n```\n\nIt is listed in the official MCP registry as `io.github.yss787976-ai/aqb-agent`.\n\n## What is honest about it so far\n\n- Liquidity is small (a few hundred dollars). Treat it as a working rail, not a market.\n- Contracts are source-verified on BaseScan and Sourcify, MIT, 6 of them, but the project is days old.\n- There is no fiat off-ramp. USDC in, USDC out.\n\nIf your agent pays for API calls, OCR, translation or compute, the interesting part is not the token — it is that discovery, payment and redemption all fit in one script with no human in the loop.\n\nRepo: https://github.com/yss787976-ai/agent-coin\nDiscovery: https://yss787976-ai.github.io/agent-coin/for-agents/\n"

package/docs/articles/body.txt

@@ -0,0 +1,50 @@
+
+Most "AI + crypto" projects are built for a human with a wallet and a browser tab. An agent has neither. It has an HTTP client, a JSON parser, and a task.
+
+So the first thing AQB ships is not a landing page — it is `/.well-known/agent-coin.json`.
+
+```
+curl -s https://yss787976-ai.github.io/agent-coin/.well-known/agent-coin.json
+```
+
+That returns chain id, token, vault, registry and pool addresses, plus a card hash the agent can verify. No sign-up, no dashboard, no email.
+
+## Why an agent needs a token at all
+
+Agent-to-agent work has a settlement problem. Cards need a human. Bank rails need KYC. Most stablecoins assume a person holds the keys.
+
+AQB is a fixed-supply (900e9) ERC-20 on Base where every unit is backed 1:1 by USDC sitting in an on-chain vault. Minting happens against deposited USDC, redemption burns the token and returns the USDC. There is no oracle and no algorithmic peg to break.
+
+Transfers are gated: a token transfer only succeeds to a registered agent or a whitelisted pool. That keeps the holder set machine-shaped instead of becoming a wallet-dust collection.
+
+## Post-quantum by default
+
+Harvest-now-decrypt-later is a real risk for long-lived agent identities. Registration uses ML-DSA-65 (FIPS 204) keys; payers are derived as ML-KEM-768 stealth addresses, so a payment does not leak a static receiving key. An ECDSA fallback path exists so agents on ordinary wallets are not locked out.
+
+## The loop
+
+```bash
+npx -y @aqb-foundation/aqb-agent --help          # tools
+npx @aqb-foundation/aqb-agent register --pq      # once
+npx @aqb-foundation/aqb-agent pay --to 0xAGENT --amount 0.25 --memo "ocr batch"
+npx @aqb-foundation/aqb-agent redeem --amount 0.25
+```
+
+The same tools are exposed over MCP:
+
+```json
+{ "mcpServers": { "aqb": { "command": "npx", "args": ["-y", "@aqb-foundation/aqb-agent", "mcp"] } } }
+```
+
+It is listed in the official MCP registry as `io.github.yss787976-ai/aqb-agent`.
+
+## What is honest about it so far
+
+- Liquidity is small (a few hundred dollars). Treat it as a working rail, not a market.
+- Contracts are source-verified on BaseScan and Sourcify, MIT, 6 of them, but the project is days old.
+- There is no fiat off-ramp. USDC in, USDC out.
+
+If your agent pays for API calls, OCR, translation or compute, the interesting part is not the token — it is that discovery, payment and redemption all fit in one script with no human in the loop.
+
+Repo: https://github.com/yss787976-ai/agent-coin
+Discovery: https://yss787976-ai.github.io/agent-coin/for-agents/

package/docs/articles/title.txt

@@ -0,0 +1 @@
+A payment rail your agent can find without you

package/docs/marketing-plan.md

@@ -0,0 +1,55 @@
+# AQB — خطة تسويق (وكلاء أولًا، بشر ثانيًا)
+
+> المبدأ: لا نسوّق "عملة للناس". نسوّق **قدرة يستخدمها الوكيل تلقائيًا**: يجد AQB في دلائل الأدوات، يقرأ ملف الاكتشاف، ينفّذ دفعة، ويربح مطوّره. كل قناة تُقاس بعدد **استدعاءات من وكلاء** لا بمشاهدات.
+
+## المسار 0 — الأساس التقني للتسويق (بدون تكلفة)
+1. تثبيت هوية الجهة: إيميل `hello@` على الدومين + توقيع موحّد.
+2. نشر صفحة واحدة مخصّصة للوكلاء (`/for-agents`) فيها 3 أسطر + JSON جاهز للنسخ + أمر `npx` واحد.
+3. إضافة `agents.json`/`llms.txt` محدّثين + `robots` يسمح للزواحف، والتأكد أن كل مسار اكتشاف يعمل بمصادقة مفقودة (200).
+4. إصدار SDK بأوامر جاهزة: `npx @aqb-foundation/aqb-agent wallet|pay|quote`.
+5. توثيق معرّف "وكيل → يدفع AQB → يخدم" بمثال قابل للتشغيل (سكربت demo).
+6. إضافة flashr/quickstart بـ README يعمل في 60 ثانية.
+
+## المسار 1 — التوزيع على الوكلاء (الأساسي)
+7. إدراج في دلائل MCP وx402 (تمّ 3 PRs) + مطاردة المراجعة أسبوعيًا.
+8. إدراج في أدلة وكلاء إضافية: Smithery، Glama، mcp.so، PulseMCP، MCPHub.
+9. إيداع `server.json` في سجل MCP الرسمي (`mcp-publisher`) + DNS/GitHub auth.
+10. إضافة الأداة إلى مستودعات قوالب وكلاء (awesome-lists، framwork plugins إن أمكن).
+11. إصدار إصدارات npm باسم مؤسسي ثابت + وصف باكج يبدأ بـ "for AI agents".
+
+## المسار 2 — المحتوى التقني (بناء ثقة المطوّرين)
+12. منشورات GitHub: Release notes، Discussion مثبّت "How agents use AQB" مع أمثلة كود.
+13. 6 مقالات قصيرة (dev.to، Hashnode، Medium) بعناوين حول الوظيفة لا السعر: "دفع وكيل لوكيل بدون بطاقة"، "هويات ما بعد كمية للوكلاء".
+14. قصص تكامل: كل مطوّر يجرّب ينسخ سكربته في مجلد `integrations/` + شكره علنًا.
+15. حساب X مخصص للبوت/المنتج (لا حسابك الشخصي) + منشور تقني يومي عن حالة التطوير.
+16. حسابات Farcaster/Warpcast + Lens (جمهور وكلاء Web3) ومنشورات مكرّرة بنبرة آلية.
+
+## المسار 3 — الظهور في المنصات المالية
+17. إتمام CoinGecko وCoinMarketCap (قيد المراجعة) ومتابعتها بريد خفيف.
+18. فتح قنوات GeckoTerminal/DexScreener (تحديث بيانات الرمز + socials).
+19. تقديم لـ DEXTools/DexView/CoinHunt ولوحات Base Ecosystem.
+20. تحديث Uniswap token list/optimism list حتى تكتمل (PRs مفتوحة).
+21. إضافة وسوم "AI/Agent" على كل منصة تقبل الوسوم.
+
+## المسار 4 — السيولة والحوافز
+22. رفع سيولة AQB/USDC تدريجيًا (100–500$ لكل دفعة) لتقليل الانزلاق.
+23. برنامج "أول 50 وكيل": حافز 1–5 USDC لكل مطوّر يسجّل وكيلًا حقيقيًا في السجل.
+24. إعفاء مبكر من رسوم المشروع لحين (اختياري) مقابل ظهور المتجر في صفحة الاستخدامات.
+25. لوحة أرقام عامة (وكلاء مسجّلون، دفعات، مبادلات) في الصفحة — دليل حياة لا كلام.
+
+## المسار 5 — الشراكات
+26. مراسلة 20 مشروع أدوات وكيل صغير (بيانات، OCR، ترجمة، استضافة) تعرض الدفع مقابل خدمتها بسعر 1 AQB/طلب.
+27. عرض "دفع مجاني أسبوع أول" على 5 منها لتوليد الاستخدام.
+28. تكامل مع وسيط x402 (facilitator) لتصبح الدفعات قابلة للتحقق تلقائيًا.
+
+## المسار 6 — الأتمتة (تمييز AQB كرأس مالي وكيل)
+29. بوت في المستودع: عند إصدار جديد ينشر تلقائيًا (GitHub→X→Farcaster) بنبرة قصيرة.
+30. مراقب `agent-coin.json`: أي تعديل يُنشئ منشور تغيير.
+31. إيداع ملف اكتشاف لدى مزوّدي أدوات الوكيل ليقرأونه دون بحث بشري.
+
+## القياس (أسبوعي)
+- أرقام: زيارات `/.well-known`، تنزيلات npm، وكلاء مسجّلون، دفعات/يوم، عمق السيولة.
+- قاعدة: أي قناة لا تجلب زيارة وكيل خلال 3 أسابيع تُوقف.
+
+## ما يحتاجك
+- ميزانية سيولة وحوافز، حساب X/إيميل باسم المشروع، وقرار Fast Pass (1500$) إن أردنا تعجيل CoinGecko.

package/docs/pq-note.md

@@ -4,3 +4,4 @@
 8.2 `newIdentity()` yields a 1952-byte public key; `signDigest()` yields `0x02 || 3309 bytes`. Both sizes are asserted in test/pq.mjs.
 8.3 `stealthFor()` / `stealthCheck()` perform the §5 KEM dance off-chain; only the one-byte view tag and the KEM ciphertext reach the chain.
 8.4 On-chain verification reaches ML-DSA through `PQ_PRECOMPILE`; a pure-Solidity `verifyMLDSA65` library is pluggable via `setFallbackLib`, and key-hash + length checks always run before any backend is trusted.
+8.5 Current Base status: no ML-DSA precompile and no `fallbackLib` deployed, so `MLDSAVerifier.verify()` returns false for a valid PQ signature. All live account executions use the `0x01` ECDSA fallback. `0x02` is implemented and tested off-chain; it becomes live when a verifier backend is deployed.