v0.1.0-alpha.3

Added

• counterparty_allowlist's KNOWN_ISSUER kind gains an opt-in gate_inflows
  flag (default false, so existing policy files parse and behave unchanged).
  When true, KNOWN_ISSUER evaluates every leg of the descriptor — debit
  and inflow alike — instead of debit legs only, so tokens received from an
  un-allowlisted issuer (Blend withdraw/borrow proceeds, vault withdrawals)
  are gated too. An inflow leg whose asset is unresolvable denies fail-closed,
  the same posture as the existing debit handling. The other counterparty
  kinds (G_ACCOUNT / C_ACCOUNT / HOME_DOMAIN) are unaffected. (#39)

• profile enroll-owner-key enrols the policy-file owner ed25519 PUBLIC key
  from an operator-held seed, and profile sign-policy signs a V1 policy file
  with that seed so the engine accepts it. Together they make
  policy.engine = "v1" usable end to end: no shipped command previously
  produced the [signature] table the engine requires, so selecting v1
  failed closed. (#30)

• stellar_agent_core::policy::v1::signature::sign, the owner-signature
  primitive that is the exact inverse of verify. (#30)

• Value-moving verbs now write a hash-chained, HMAC-signed
  value_action_submitted audit row after a confirmed on-chain submit,
  recording the SAME value legs the policy gate sized (single-derivation
  invariant), the redacted transaction hash, and the ledger. This covers the MCP
  stellar_pay / stellar_create_account / stellar_claim / stellar_trustline
  commit tools, the Blend / DEX / DeFindex adapters, the opaque
  stellar_sep43_sign_and_submit_transaction path, and the CLI pay /
  claim / accounts create (sponsored) / trustline verbs. The x402
  payment authorizers write their own x402_payment_authorized row at
  authorization signing (there is no on-chain submit on that path), carrying
  the gate-sized legs plus the settle network and scheme. A
  DeFi adapter that fails on submit records a sa_raw_invocation row instead.
  Emission is non-fatal post-submit: a row-write failure logs a warning and
  never changes the result. (#21)

• PolicyEngine gains evaluate_full / evaluate_with_value_full, which return
  an Evaluation { decision, value_effects } surfacing the value descriptor the
  gate sized on the allow path; the decision-only evaluate /
  evaluate_with_value remain as thin views. Value-verb dispatch uses the
  _full methods so the post-submit audit row records exactly the legs the gate
  evaluated rather than re-deriving them. (#21)

• The six key-writing profile commands — enroll-signer, enroll-owner-key,
  rotate-nonce-key, rotate-attestation-key, rotate-counterparty-key, and
  rotate-audit-key — now write a keyring_key_written audit row recording the
  key purpose and, where applicable, the redacted public address. (#34)

• profile rotate-audit-key rotates the audit chain-root HMAC key and re-signs
  every per-file chain-root sidecar with the new key so audit verify stays
  green across the rotation; the new key is persisted before any sidecar is
  re-signed. (#34)

• Offline envelope-shape regression coverage for the nonce.mint_failed
  business error on the four two-phase simulate handlers (stellar_pay,
  stellar_create_account, stellar_claim, stellar_trustline) and for the
  RPC-dependent sep48.spec_fetch_failed / sep48.render_failed /
  sep47.discovery_failed arms of stellar_sep48_preview_invocation /
  stellar_sep47_discover, each asserting the full normalised envelope
  (ok:false, the documented wire code, a non-empty request_id,
  is_error == Some(true)). (#36)

• Testnet acceptance coverage for a sponsored stellar_create_account /
  stellar_create_account_commit two-phase call: the destination account
  exists on-chain afterward with the sponsored starting balance, and the
  commit recorded a value_action_submitted audit row. (#43)

• Testnet acceptance coverage for a classic stellar_trustline /
  stellar_trustline_commit two-phase call against the pinned testnet USDC
  issuer, run under a minimum_reserve policy rule the funded source account
  satisfies: the simulate and commit steps both reaching ok:true (rather
  than policy.criterion_evaluation_failed) is on-chain proof that both
  dispatch points supply a genuinely populated account_view (#47). Asserts
  the on-chain trustline limit and the commit's value_action_submitted
  audit row. (#43)

• profile rotate-audit-key gained the run_with_dependencies seam already
  used by the other key-writing profile commands, so its unit coverage now
  drives the actual persist → re-sign → emit sequence rather than a parallel
  reimplementation of it; reordering the three steps turns the test red. A
  V1-engine testnet acceptance variant of the stellar_pay_commit flow now
  asserts the confirmed commit's value_action_submitted audit row's leg
  content (action, amount, asset, redacted destination) equals exactly
  the values submitted on-chain, not merely that a row of the right kind
  exists. (#44)

Changed

• CLI pay --sign-only / --submit-only and claim --sign-only /
  --submit-only now evaluate operator policy on the supplied envelope before
  signing or broadcasting, instead of running unconditionally under
  policy.engine = "v1". Each stage decodes the envelope through the same
  decoder the MCP stellar_pay_commit / stellar_claim_commit path uses and
  evaluates the decoded amount/asset/destination — sizing comes from the
  envelope, not caller-supplied args. --submit-only gates even though the
  envelope arrives pre-signed, because broadcasting still spends funds. An
  envelope the decoder cannot classify into a sized shape follows the
  opaque-signing posture: denies policy.deny.unsizable_value_effect under a
  matched value rule unless it sets allow_opaque_signing = true, mirroring
  the stellar_sep43_* tools' posture. policy.engine = "noop" is unaffected
  — the staged flows remain ungated there, as before. The staged flows
  match policy rules under the stellar_pay_commit / stellar_claim_commit
  tool names (the same names the MCP commit phase matches), not stellar_pay
  / stellar_claim: a ruleset that names only the base tools default-denies
  the staged flows, so operators cover both names, or use tool = "*", for
  uniform behavior across invocation modes. (#40)
• The per-period rolling-window accumulator (PolicyStateStore) is now
  i128-width: cumulative recorded spend within a rolling window is exact
  across the full i128 range, superseding the previous i64-width
  accounting and its fail-closed refusal above i64::MAX (#20). The
  accumulator is in-process state only (no persistence across restarts, as
  before), so there is no legacy on-disk form to migrate. (#42)
• Documented that minimum_reserve and identity-class criteria
  (home_domain_resolved) are inapplicable to the smart-account verbs
  (stellar_blend_lend, stellar_dex_trade, stellar_defindex_vault_deposit,
  stellar_defindex_vault_withdraw, and the CLI lend/trade/vault
  equivalents): the acting account is a smart-account contract with no classic
  AccountEntry, so account_view and identity_view stay unset permanently
  on these tools, by design. A rule configuring either criterion on one of
  these verbs fails closed on every call. (#38)
• Value criteria (per_tx_cap, per_period_cap, minimum_reserve,
  counterparty_allowlist) now size a call through a typed value descriptor
  derived at the dispatch gate, instead of matching hard-coded tool names. A
  rule that matches a value-moving tool constrains every debit leg it carries
  (classic pay/create, Blend supply/repay, DEX trades, vault deposits, x402
  payments), and per-asset caps aggregate across the legs of a multi-leg call.
  A value rule that matches a call whose value cannot be sized — a tool that
  reached the gate without resolved effects, or a raw signing tool
  (stellar_sep43_*) — now denies fail-closed with
  policy.deny.unsizable_value_effect rather than passing silently. A rule may
  opt a signing tool back in with allow_opaque_signing = true.
  minimum_reserve now counts only native-XLM outflow legs; a token-only move
  no longer reduces the native reserve. Operators with existing value rules
  should expect previously-unconstrained value tools to be gated. (#18, #19,
  #20)
• CLI pay, claim, and accounts create (sponsored mode) now evaluate
  operator policy before signing, through the same PolicyEngine::evaluate
  path the trade/lend/vault/trustline CLI verbs already use and with
  value descriptors identical to their stellar_pay / stellar_claim /
  stellar_create_account MCP twins. Previously these three verbs signed and
  submitted unconditionally, bypassing the engine entirely. All three verbs
  gain a --profile flag (default "default"). With no persisted profile
  file, an in-memory Noop-engine testnet profile is synthesized, so the verbs
  keep working without an authored profile and policy.engine = "noop"
  behavior on testnet is unchanged. The gate only bites when --profile
  resolves to a
  persisted profile with policy.engine = "v1". accounts create Friendbot
  mode is not gated (it debits no wallet funds). (#19)
• CLI trade, lend, and vault now size their policy gate with the same
  value descriptor their stellar_dex_trade / stellar_blend_lend /
  stellar_defindex_vault_deposit / stellar_defindex_vault_withdraw MCP
  twins use: each verb builds its value legs from the same parsed inputs it
  submits and evaluates them through PolicyEngine::evaluate_with_value, so
  per_tx_cap / per_period_cap / minimum_reserve constrain CLI DeFi debits
  exactly as they constrain the MCP calls. Previously these verbs gated on the
  tool name alone — with trade classified read-only — leaving the traded,
  lent, and deposited amounts...

v0.1.0-alpha.2

Added

• Remote operator approval: approve serve --remote binds a TLS-protected,
  passkey-authenticated listener so an operator can approve or reject pending
  wallet actions from another device, with per-entry WebAuthn assertions on
  every decision.
• Bounded agent delegation: context rules can be scoped to a single contract
  (--context call-contract:<C>) or wasm hash, first-class External-Ed25519
  signers attach to rules via a registered verifier, and a spending-limit
  policy enforces a per-rule rolling-window budget on-chain.
• Spending-limit observability and retuning: smart-account rules get-spending-limit reads an installed policy's live budget state,
  set-spending-limit retunes the limit without resetting spend history, and
  the read-only MCP tools stellar_rules_list / stellar_rules_get expose
  rule and budget state to agents.
• Agent-proposed context rules: the two-phase stellar_rule_create /
  stellar_rule_create_commit MCP pair routes rule installation through the
  operator-approval spine, with the fully resolved rule rendered on every
  approval surface before consent and the proposal digest bound into the
  attestation.
• Smart-account ergonomics: typed simple-threshold and weighted-threshold
  policy builders, a unified deploy-policy --kind verb, weighted-threshold
  mutators (set-weighted-threshold, set-signer-weight), batch signer
  addition, passkey/Ed25519/external genesis signers on accounts deploy-c,
  and new rule/signer read APIs.
• Interactive WebAuthn operator enrollment: approve operator enroll --interactive runs the passkey registration ceremony in the browser against
  a one-shot loopback server (bootstrap-token gated) and persists the
  credential without it passing through the shell; the argument mode remains
  the import path for credentials created on a remote listener's domain.
• smart-account execute: submit a CallContract invocation against an
  external contract, authorized by named context rules and signed by an
  External-Ed25519 rule key, with a separate fee-paying envelope signer.
  rules create gains --signer-ed25519 / --verifier so an Ed25519-only
  rule can be installed entirely from the CLI.
• A provisional audit status in the verifier allowlist taxonomy: the vendored
  OpenZeppelin verifier entries now report provisional (named-party internal
  review) rather than overstating an external audit; list-verifiers carries
  the attestor and date as additive fields.
• All 34 workspace crates are published to crates.io, so the binaries install
  with cargo install stellar-agent-cli / cargo install stellar-agent-mcp
  (or cargo binstall without a --git URL) and the library crates resolve
  as normal registry dependencies.

Changed

• Value-denominated fields on the machine-readable JSON wire are decimal
  strings, never JSON numbers: all i128 token quantities (dex, blend, vault,
  spending-limit budgets) and the residual i64/u64 stroop and fee fields
  (payment, account-creation, claim, trustline amounts and limits, fee-stats
  percentiles, served approval summaries). Raw JSON numbers on the migrated
  input fields are rejected. This is a breaking wire change; JSON numbers are
  exact only up to 2^53 in f64-backed parsers, and trustline limits routinely
  carry i64::MAX. The policy cap and reserve criteria now read the resolved
  stroop amounts on every dispatch shape, and pay's simulate gate arguments
  include the asset, so cap and reserve policies evaluate calls they
  previously refused or under-counted.
• Every CLI secret-env signing path handles the seed through an
  mlock-protected unlock window with explicit residue zeroization; when mlock
  is unavailable and the profile policy allows degraded operation, the
  degradation is recorded in the audit log as a wallet_mlock_failed event.
• Renamed the wallet CLI command group to smart-account (with sa as a
  shorter alias), and flattened the former nested sa admin subgroup so its
  verbs (deploy-webauthn-verifier, migrate-verifier, list-verifiers,
  list-rules, register-multicall, unregister-multicall, timelock) are now
  direct children of smart-account alongside rules, signers, and
  multicall. This is a breaking change to the CLI command surface.
• Bumped the vendored OpenZeppelin stellar-accounts and stellar-governance
  dependencies from 0.7.1 to 0.7.2 (a soroban_sdk 26.1.0 fix upstream, no
  entrypoint or ABI changes) and rebuilt all five vendored OZ WASM artifacts at
  the new tag. New smart-account, threshold-policy, timelock-controller, and
  WebAuthn-verifier deployments now use the 0.7.2 artifacts. Verifier and
  threshold-policy contracts already deployed from the 0.7.1 artifacts remain
  recognized and valid; nothing on-chain is redeployed.

v0.1.0-alpha.1

First public alpha of the Stellar Agent Wallet: a Stellar wallet for AI agents.
It provides a stellar-agent CLI and a stellar-agent-mcp MCP server over a shared
policy engine, operator-approval spine, and tamper-evident audit log.

Added

• stellar-agent CLI for accounts, payments, balances, trustlines,
  claimable-balance claims, Friendbot funding, fee stats, counterparty identity,
  smart-account governance, DeFi, the channel-account pool, profiles,
  credentials, approvals, audit verification, and agent toolsets.
• stellar-agent-mcp MCP stdio server exposing the wallet capabilities as tools
  to an MCP client. It starts on hosts without an OS keyring backend (for example
  headless servers), serving read-only and simulate tools; signing tools are
  refused with a keyring error until a backend is configured.
• Policy engine with a no-op gate and a typed first-match, default-deny V1 engine
  evaluating each action to allow, deny, or require operator approval.
• Operator-approval spine: a per-profile pending-approval store and an
  HMAC attestation binding each approval to the executed envelope and the
  approving OS user.
• Hash-chained, append-only JSONL audit log that records key names only (never
  argument values), with audit verify chain and HMAC-sidecar verification.
• Key custody via the platform keyring with a TTL-bounded, zeroize-on-drop,
  memory-locked unlock window; profiles name keyring entries and hold no secrets.
• OpenZeppelin smart-account governance: context rules, ed25519 and WebAuthn
  passkey signers, quorum, verifier/policy WASM-hash pinning, multicall, and an
  upgrade timelock.
• DeFi adapters: Blend lending (lend), Soroswap swaps (trade/quote), and
  DeFindex vaults (vault), each with venue pinning and fail-closed guardrails.
• Protocol support: SEP-7, SEP-10, SEP-24 and SEP-6, SEP-43, SEP-45, SEP-47,
  SEP-48, and SEP-53.
• Operator approval inbox: approve list enumerates pending approvals with
  their wallet-controlled summaries, and approve serve runs a loopback-only
  web inbox that lists pending approvals live, notifies the operator, and
  approves (minting the same attestation as approve --id) or rejects.
  Rejection records a short-lived marker so the agent's commit is refused
  with policy.approval_rejected instead of waiting out the TTL. Session
  bootstrap is a single-use URL token exchanged for an HttpOnly cookie;
  actions require a per-session CSRF header. Approvals now emit audit
  events from both the terminal and inbox surfaces. For a remote agent
  host, the inbox is reached through an SSH port-forward; the approving
  user must be the wallet's OS user.
• Claimable-balance claims by ID (CLI claim, MCP stellar_claim /
  stellar_claim_commit two-phase pair): RPC-backed preview with claimant,
  predicate, clawback, and trustline pre-flight guards. Balance IDs are taken
  as 72-hex, bare 64-hex, or B... strkey; listing balances by claimant is a
  Horizon-only query and stays out of scope for the RPC-only wallet.
• x402 v2 Exact Stellar agent payments with an optional SEP-10 counterparty
  identity gate.
• Signed agent toolsets with capability isolation, publisher-signature verification,
  a first-invoke gate, and unconditional per-action approval for toolset-routed
  payments.
• approve returns the approval_attestation for a payment approval so the agent
  surface can present it to the matching *_commit tool, completing the
  simulate-approve-commit flow over MCP.
• An agent knowledge skill under skills/ (agentskills.io format, with a Claude
  Code marketplace plugin and a downloadable archive) that teaches an AI agent to
  operate the wallet's CLI and MCP server without cloning the repository.
• An agent integration guide (docs/agents.md) and capability-isolation example
  toolsets under examples/toolsets/.