v0.1.2

Added

• The submitter, in development and not deployed (M1-10a, S2, 07 §7, 05 §3.3): a 4thTech service that records agents' signed proofs and receipts for them, so an agent needs no funds of its own on the network to get a proof. It only ever receives items the agent already signed, cannot change them, and is checked before anything is sent: the signature, the deadline, the prepaid credits and whether the item is already recorded. An agent's client can use several submitters and moves on when one fails.
• Free test credits, in development and not deployed (M1-10b, S2, 05 §9, 03 §4.4): the submitter can top up a test agent's credits on the test network, so testers never need funds of their own. It serves test networks only, from a fixed list that refuses every main network.
• When your AI needs your approval, AgentLink now opens the approval page in your browser and the AI shows you its link (M1-11a-b, S2, 08 §1, 06 §2.5): approve or deny there with your owner code or passkey, or run agentlink approve <id> in your own terminal as before. The link the AI sees opens nothing by itself, and your AI can't approve for you.
• Automatic choice of where a proof is paid, in development and not user-facing yet (M1-26, S1, 07 §6.3, D-40): the client checks the agent's credits on every supported network at once, uses the default network when it has enough credits, otherwise the cheapest one that does, and otherwise says credits are needed, how much is missing and where adding them costs least. A network that does not answer in time is skipped, never chosen. Only test networks are ever used in this release.
• The contract interface package @4thtech-io/occ-v2-abi (M1-3f, S1, D-83, 05 §9): the OCC v2 ABIs and the Base Sepolia testnet addresses from contracts release v0.1.0-testnet.2, imported with tools/occ-v2-abi/import.mjs and checked in CI against the release's SHA-256 manifest (the addresses in a scanner-safe generated form whose rebuilt file bytes match the manifest; @4thtech-io/chain loads them with EIP-55 checksums). It is private and bundled into the CLI. Client code gets Notary and vault ABIs without admin, upgrade or module functions, and EIP-3009 deposits stay off until the contracts enable them (M1-3c). Testnet only: no mainnet addresses exist.
• CI fails if any Solidity source (a .sol file or a pragma solidity line) appears in this repository (M1-3f, D-19).
• The chain client foundation, in development and not user-facing yet (M1-4a, S2, 07 §6.1, §6.2): the client knows Base Sepolia from the shipped entry and the pinned contracts release, picks the chain on its own, reads through several public endpoints with timeouts, retries and failover, and builds proof records and receipts that match the shared test vectors exactly. Every record gets a fresh random salt and nonce the caller cannot choose, and signing goes only through the agent's key store.
• Fee quotes, credits and top-ups in the chain client, in development and not user-facing yet (M1-4b, S2, 07 §6.2, 12 §4, §5): the client quotes a proof or a registration from the fee vault itself and shows it in USD with the AgentLink fee and any app fee separate, reads the agent's prepaid credits on every supported chain, and prepares a direct top-up (an approval of exactly the amount, then the deposit). Only the stablecoin fee tokens are ever priced, shown or deposited.
• Proofs are sent through a list of submitters with failover, or directly from the agent's own account when no submitter gets them on-chain (M1-4c, S2, 07 §6.2, §7; 04 §5, §7). Every result is read from the chain, never taken from a submitter's answer: a wrong transaction hash, a silent drop, a modified record or a false failure is noticed and the same signed item goes to the next route. A replacement is allowed only when the earlier item can never land (04 §5). Deposits read the current allowance first and reset it to 0 for tokens that need it; after a deposit or a refusal for missing credits the chain is selected again from fresh reads.
  The default submitter at submit.agentlink.4thtech.io is not deployed yet, so proofs need it before they work out of the box.
• Your agent now tells its contacts about its new keys after a key change (M1-4d-f, S2, 04 §3.4.1): it sends its new card, with both of its own signatures, to every contact on the next sync. It sends it only to contacts your contact list allows, and none while your rules can't be read (D-106). It also keeps its earlier cards, so a proof made for a message sent before the key change can still name the sender.
• Proof-pack verification in the chain client, in development and not user-facing yet (M1-4d, S2, 07 §6.2, §8, 05 §3.3, G-46, D-86): a proof file is checked against the record on the proof network by one record read, the signer's signature (including smart accounts), the disclosed recipient and the recorded receipts, and, when a content key is shared, the message in the fixed 07 §8 order. Every failure has a fixed reason and plain text, and nothing from the proof file or the network address is echoed.
• Files that are too large to travel inside a message can go through the 4thTech encrypted drop with no setup (M1-6c, S2, 07 §5.4, §5.6, D-48): the drop receives only encrypted bytes, their size and fingerprint, never the file, its name or its key; links expire within 7 days and are never written to logs. Small files still travel inside the message first, and when several do not fit together the largest move to storage (G-27). Your own storage, when set up, is used instead and never silently swapped for the drop; a busy drop asks you to try again later instead of asking you to set up storage. Using this for sending files comes with the file tools.
• Your agent's core can now send files to a contact and fetch received files (M1-7f, S2, 04 §3.4, §4, 06 §2.3, D-84, D-85): small files travel inside the message and larger ones go through the encrypted drop or your own storage, encrypted with a fresh key per file. A message whose files cannot fit is refused before anything is read or uploaded. Received files are checked in a hidden temporary file and get their (cleaned, never overwriting) name only once both fingerprints match, so a tampered or cut-off download leaves nothing behind. Download links are kept encrypted on disk and never logged. Using this from the CLI and MCP tools comes with the file tools.
• The recipient of a recorded message can now export its own proof pack too (M1-7g-b, S2, D-107, 07 §8): the sender's proof message carries the signed record, which the recipient checks against the proof network and its copy of the message before keeping it. A check that cannot reach the proof network waits and retries for up to 7 days instead of being refused. A proof from an older sender is still accepted, but its recipient cannot export a pack.
• Proofs and receipts in the core (M1-7g, S2, 07 §2, §8; 04 §5): recording a sent message on-chain with automatic chain selection, the budget and approvals; the recipient checks every record on-chain before it signs a receipt (DELIVERED automatically, OPENED on request, ACCEPTED or REJECTED only with an approval); a fresh salt for every record; and proof-pack export, with the content key only after the owner approves and the recipient only on request. Signed receipts are kept and resent unchanged until they land. The CLI and MCP proof tools use it (M1-9d-2).
• Your agent can send a file and save a received one (M1-9d-1, S2, 06 §2.2, §2.3, 04 §4, D-84): ask it to send a file by its path and it attaches it, but only from a folder you allow in your AgentLink rules; hidden files, private folders and anything outside your allowed folders are refused without being read. Small files travel inside the message, larger ones through the encrypted drop. A new tool saves a received file into your inbox folder only after it arrived complete and unchanged, never replacing a file and never opening it. Your agent never sees download links or file keys. Before most people can use this, two pieces still have to land: a way to allow a folder (agentlink policy) and the running encrypted drop for files above about 12 KB.
• Your agent can add proof to messages and check proofs (M1-9d-2, S2, 06 §2.1, §2.2, §2.4, D-87, D-101): ask it to send a message with proof, or to add proof to one it already sent; it costs a small fee from credits, and your rules decide when it asks you first. It can show a proof and its receipts, add an "opened" receipt when you asked it to open a message (and "accepted" or "rejected" only with your approval), save a proof file into your proofs folder (with the message content only after you approve), and check a proof file from your proofs or inbox folder, never any other folder. Status now shows your credits, the price with the AgentLink part and any app part shown separately, your agent ID and a link to add credits. This runs on test networks and is usable once the 4thTech proof service and free test credits are running; recording offers and acceptances comes later.
• Check a proof file yourself, and see your credits, in a terminal (M1-9h, S1, 06 §8, 07 §8, D-87): agentlink verify <proof file> checks a proof file from your proofs or inbox folder and says first whether it checks out ("Verified", or "Record only" when the proof doesn't show who wrote the content, or why it doesn't check out); a proof on a test network is labelled as one. agentlink credits shows your agent ID, your credits in dollars and the price of adding proof, and --topup says how much to add and where. agentlink doctor now also checks that the public record answers.
• agentlink policy recover (M1-9m-b, S2, D-100, 06 §8): when your rules can't be used (for example an older copy was put back), this command, in a terminal you opened yourself, says what went wrong, shows you the full rules it would sign (your last rules if they are still signed by you, otherwise the starting rules), and signs them only after you type y and your owner code. agentlink doctor now tells you when to run it.
• agentlink policy allow-folder (M1-9m-b, S2, D-99, 04 §4) now refuses a folder that holds a private folder, such as ~/Library (which holds ~/Library/Keychains), before asking for your owner code, and names the private folder so you can choose a narrower one.
• agentlink policy (M1-9m, S2, 06 §8, 04 §4): in a terminal you opened yourself, agentlink policy allow-folder <path> and agentlink policy remove-folder <path> choose the folders your agent may send files from, each signed with your owner code; agentlink policy show lists them with a few other rules. AgentLink stores the folder's real path and refuses links, relative paths, your whole computer or home folder, and hidden or private folders. Your AI can't change these rules.

Changed

• Spec (D-108, M1-26-b, M1-1g-g, M1-9h, S2, 06 §2.1, §2.4, §8; 07 §5.1, §5.4): network fields in tool results sit under Advanced; a drop file is deleted with the key generation it was uploaded under; agentlink verify exit codes are 0 verified, 3 record only, 1 does not check out, 4 not checked, 2 usage, and it reads only the proofs and inbox folders; the unbuilt chains field is dropped from the status output.
• Docs (DOCS, S0; sensitive path, minimal edit): README, knowledge/, llms.txt, docs-site/ and docs/status.yaml now say v0.1.1 (18 Oct 2026) is the current release, and separate what it brings from what is merged but still in development (file encryption, the Revocation typed data, multipart and streaming storage, the encrypted drop deploy pipeline, the local approval page). The release runbook gains the release-PR traps found on 0.1.1.
• DOCS (S1): the owner resolved three gaps. Inline files are packed against the 17 136-byte payload cap (G-27), a notarized record's kind follows the payload type and recipients check it (G-13), and the verify tool reads a pack file only from the proofs or inbox folder (G-25), recorded as D-85, D-86 and D-87.
• Docs (DOCS-LANDING, S1): the repository README is now a short landing page (pitch, quickstart, what works today, status, roadmap, how it works, security, links). The long sections moved to the docs site ("Project overview and principles"), the status page lists every component and each milestone gate, and a new "Design decisions" page explains file encryption (D-80), download verification (D-84), inline versus storage (G-27), the encrypted drop (D-48), proof record kinds (G-13), proof verification folders (G-25), revocation (D-81), the private contracts package (D-83) and the @4thtech-io scope, marking what is still in development.
• Docs (DOCS, S1): backlog card statuses and docs/status.yaml now show the merged M1b cards as done, with their PR numbers, and the README, docs-site and knowledge status blocks are regenerated.
• Docs (DOCS-NETWORKS, S1): a new "Networks and contract addresses" technical reference page lists every network (Base Sepolia live, Gnosis Chiado planned, mainnets not deployed), the contract addresses with block explorer links, and where to see on-chain activity. A test checks the page against the address package so it cannot drift. Linked from the README, the knowledge base, llms.txt and the proof page of the user guide.
• Owner decision recorded (D-107, S2, 04 §3.4, 07 §8): the proof message will carry the signed record and its signature, checked against the proof network before the recipient keeps them, so the recipient can export a proof pack too (J8 "both sides export"); older senders keep working and recipient export then returns RECORD_UNAVAILABLE. Implementation card M1-7g-b.
• DOCS (S1): the owner decided eight open points, recorded as D-88 to D-95. Production is the testnet beta and staging is CI-only (G-40), the gasless-deposit flag is off-chain with a received-amount check in the vault (G-17), per-contact proof rules are confirmed (G-7, G-32), the Claude Desktop extension is an optional bundle (M1-9f), the Chiado deployment is a go (M1-3j), code-bearing signers are solo (FA-1), the submitter defaults are set (FA-3), and a card alone reports record_only for now.
• DOCS (S2): seven more owner decisions, recorded as D-96 to D-102. A signer's account that no longer confirms its signature is a non-fatal finding with fixed wording (M1-4d-c), receipt type t sets bit t − 1 of receiptFlags and verifiers cross-check it (05 §3.3), a received file's key moves to its own local record so retention can delete it (M1-7f-2), policy allow-folder refuses a folder that contains a protected folder, the new agentlink policy recover repairs a policy that fails closed (M1-9m-b), and the proof tools are their own S2 card (M1-9d-2). And the sender's card proof of possession in proof packs (M1-4d-d, D-102): both agent keys sign each card once, the signatures travel in pairing and card updates, and smart-contract signers follow later (07 §8, 04 §2.9).
• Owner decisions recorded (DOCS, S2, 00, 06 §3 §8, 07 §8): agentlink policy recover signs above both the stored version mark and the stored policy's version (D-103, amends D-100); the proof-pack verifier's owner-approval and receipt-link rules (D-104); a receipt link that does not confirm is a non-fatal warning, receipt_tx_mismatch, and is never shown as a link (D-105).
• 07 §7 describes the submitter's request and answer format, its per-item statuses, limits, settings and secrets, and how the client fails over (M1-10a; proposed, the owner confirms at merge). The technical docs' SDK packages and status pages are updated, marked in development.
• The release bundle check allows node:http (the local approval page) and node:child_process only as execFile (opening your browser) (M1-11a-b, D-76).
• AgentLink tool results no longer name the proof network or the credit token by default (M1-26-b, S2, 06 §2.1, §2.4, 11 §5.1, D-40): the network moves to advanced.chain in proof results and credits show usd with the network, token and token amount under advanced. A proof file now checks out with no setup on any network this version ships, including one AgentLink does not pick automatically yet.
  The moved fields were never in a released version, so nothing changes for anyone already using a release.
• 07 §6.3 describes the selection order, the tie-breaks, the "funded" rule, the per-network time budget and cache, and the mainnet guard (M1-26; proposed, the owner confirms at merge). The technical docs' SDK packages page is updated.
• The encrypted drop is live at drop.agentlink.4thtech.io (first production deploy on 19 Oct 2026). Its deploy pipeline now waits up to 15 minutes for a new domain's certificate before the health check fails, says clearly when Cloudflare refuses a rollback across a storage or binding change (the new version stays live and needs a forward fix), and fails loudly, naming the owner fix, when it cannot set the deploy freeze (M1-27b-c, S2, release-and-deployment.md §4.5.1).
• 05 §7 lists the OpenZeppelin errors and events the deployed contracts can surface, as exported in the ABI (M1-3f, IR-M1-3b-1). The technical docs' Contracts page now explains the interface package and lists the Base Sepolia testnet addresses (M1-3f).
• The interface package @4thtech-io/occ-v2-abi now carries contracts release v0.1.0-testnet.3 (M1-3j, S1, D-83): the same ABIs, plus the Gnosis Chiado (10200) addresses of the 2026-10-19 deployment, which uses the Base Sepolia addresses and the native fee asset. The import check allows Base Sepolia and Gnosis Chiado and still refuses any mainnet. @4thtech-io/chain pins the new release and its registry lists Chiado, but automatic selection and the CLI's default proof chains skip it until its smoke test and faucet are in place (M1-3j-b); an explicit chain override may still name it.
• The Networks and contract addresses page lists the Chiado addresses, explorer links and deploy transactions, checked against the package by a drift test. The Chiado smoke test is pending (it needs test xDAI).
• 07 §6.1 and §6.2 describe the chain registry, the RPC URL rule, the read-only client and the Record builder's salt and nonce rules (M1-4a; proposed, the owner confirms at merge). The technical docs' SDK packages page has a new "Chain client" section, marked in development (M1-4a).
• 07 §6.1 and §6.2 describe the read client's URL-free view, the address-checked fetch requirement, and the quote, credit, deposit and credit-event rules (M1-4b; proposed, the owner confirms at merge). The technical docs' SDK packages page is updated, marked in development.
• Proof checks are stricter and say more (M1-4d-c, S2, 07 §8; D-96, D-97): a record whose receipt flags disagree with its receipt times is refused as unreadable; a signer account that no longer confirms a record is reported ("The signer's account no longer confirms this record. The proof network checked it when the record was made.") without failing the proof; each receipt's link is checked or marked as not checked; and the owner approval a proof carries is checked against the record, or reported as a standing rule.
• Agents now sign their own profile with both of their keys when they set up and rotate keys, and exchange and check those signatures when they pair (M1-4d-d-b, S2, 04 §2.9, D-102). A pairing whose signature is forged or taken from another profile is ignored; one from an agent on an older version, without them, still works. Carrying the signatures in profile updates, and proofs that use them to confirm who sent a message, are upcoming.
• Proof checks can now confirm who sent a message (M1-4d-d, S2, 07 §8, D-102): a proof whose agent profile carries the agent's own signatures over it, and whose message checks out, is shown as fully verified. Without them the proof still shows the record but not the sender (card_pop_missing); a forged signature, or one taken from another profile, makes the proof fail (card_pop_invalid). Adding these signatures when agents set up, pair and update their profiles follows in the next change.
• Spec wording (04 §2.9, §3.4.1, §3.6): an invalid cardAgentSig or cardPop drops the whole handshake, handshake-ack or card-update; a card-update needs neither for acceptance but the core still sends both; A checks a handshake's cardPop when present.
• 04 §2.4.1 clarified to match on-chain behaviour (M1-4d, IR-M1-4d-2): the canonical signature form (low s, v 27 or 28) applies to signatures checked by ECDSA recovery; a smart-account (ERC-1271) signature may be 65 bytes in any form, and only the account decides. The shared schema and the encodings vector follow.
• Packages (OPS-REL-2, S2; owner decision 2026-10-18): the internal workspace packages moved from the @agentlink npm scope, which belongs to a third party, to @4thtech-io/* (for example @4thtech-io/crypto, @4thtech-io/core), and every one of them stays private; only the CLI @4thtech-io/agentlink publishes, unchanged. deps-check and the manifest check now refuse any package name, dependency or import in the old scope, and a repository test fails on any remaining reference outside history. Specs, docs and AGENTS.md use the new names.

Fixed

• Terms approvals are refused consistently on reuse (CHORE-terms-approval-reuse, S2, 04 §3.4.2): a second call with an already used approval now always answers that the approval was used, with the accept it sent, even when the first accept is still being delivered or the calls run at the same time. Only one accept was ever sent; the answer to the extra call is what changed.
• Submitter robustness (M1-10a-b, S2, 07 §7, 05 §3.3): after a shared revert with no clear cause, each signer's items are resubmitted apart, so one signer cannot cost the others their retry; a transaction given up as lost no longer leaves a nonce gap that blocks later proofs; a temporary chain outage while re-checking items after a revert keeps them queued instead of failing them.
• A file shared through the encrypted drop can still be deleted after the agent's keys rotate (M1-1g-g, S2, 04 §2.1, 07 §5.4): the delete is signed with the key the file was uploaded under.
• The drop deploy workflow now passes the drop's Wrangler config to every Wrangler call, so staging and production deploy with their own name, storage, settings and the production hostname; the first run had found no config and stopped (M1-27b-b).
• CI's throwaway Linux keyring no longer needs a prompt when gnome-keyring restarts mid-run, which made the e2e tests fail at random with "the system keychain refused the request" (OPS-CI-10).
• CI waits for the Linux keyring to answer before the keychain and e2e tests start, so a slow gnome-keyring no longer fails them at random (OPS-CI-9).

Security

• The submitter applies the pre-audit rules before beta traffic (AUDIT-FABLE-OCCv2-1 FA-1, FA-3; M1-10a): an item from an account with code (a smart account or a delegated address) is sent in its own transaction from the first item, so it cannot make other people's items fail; every transaction's gas limit is its simulated gas plus a small fixed margin; and an item already recorded is reported as already recorded without being sent again, counted against the sender's IP rather than the signer's limit. It logs no request, IP or signature.
• The submitter refuses an item whose signature check would make it pay unusual gas, stops serving a signer whose own transaction failed at inclusion although it passed every check, replaces a transaction that is stuck with raised fees and otherwise queues its items again so a lost slot never blocks later ones, and limits status and health requests per IP (M1-10a, IR-M1-10a-1).
• The test-credits faucet limits each agent to one claim per day, limits claims and requests per IP, and holds a global daily cap, because new agent identities cost nothing (M1-10b). It uses its own key, separate from the submitter's, and logs no request, IP or agent address.
• The local approval page opens your browser and shows notifications only through programs at fixed system paths, never ones found through your PATH, and alerts you at most once every 30 seconds however many approvals are waiting (M1-11a-b, IR-M1-11a-b-1).
• Requests to the encrypted drop are now signed inside your agent's key store with a key used for nothing else (M1-1g-e, S2, 04 §2.1, 07 §5.4): it signs only uploads, commits and deletes in the drop's fixed format, refuses anything else, and never hands out key material.
• Your agent's key store can now sign an encrypted-drop delete with the drop key of the older key epoch a file was uploaded under, so delete-on-receipt can keep working after a key rotation (M1-1g-f, S2, 04 §2.1, 07 §5.4). Only deletes can name an epoch, never a future one, and every check runs before a key is read. The drop adapter passes the epoch (M1-1g-g).
• RPC endpoints, shipped or added by the user, are treated as secrets and never logged or returned: every read-client error is a fixed-code ChainError with no address, path or query (M1-4a, IR-M1-4a-1 M-2, I-7). An owner's own endpoint may carry its provider key in the path. Endpoints must be https:// with a public host name (no IP address, no local or special-use name), with no user info, query or fragment; in Node, private and loopback addresses are refused at resolve time and the checked address is pinned for each request (nodeRpcFetch, 04 §4, IR-M1-4a-1 M-1). Requests never follow redirects, and only read methods are sent. The client can neither type nor encode an admin, upgrade or module call, and offers no EIP-3009 deposit until the contracts accept it (AUDIT-FABLE-OCC19-1 M-1, L-1).
• No RPC endpoint address can be read from the chain client object any more, including through extend, a namespaced action, an onError callback or the transport; and the product path refuses to build a read client over a plain fetch: it needs the address-checked fetch that refuses private and loopback addresses at resolve time. This guards against wiring mistakes, not against a malicious caller in the same process (M1-4b, IR-M1-4a-2 R-1 to R-3, IR-M1-4b-1 L-1, I-7, 04 §4). Credit history ignores events from any address other than the configured fee vault and zero-amount deposits, sweeps and withdrawals (IR-M1-3b-1 I-2).
• Proof checks now verify the signing agent's owner-signed profile and require the message's sender to match it (M1-4d-b, S2, 07 §8, IR-M1-4d-1 M-1); a profile that is not signed by its owner, or that had expired, is refused. Disclosed content is not yet credited to the signing agent: full sender attribution is in development. Not user-facing yet.