Release evidence

2026-10-03: implementation candidate

Not deployed. Functional and public-release status: NO-GO. This note covers the implementation source on main. It does not describe the running release.

Application d3cacbca and native indexer 00176254 now contain the consolidated work. Desktop and mobile checks cover the changed boards, detail pages and error states. These controlled checks do not prove native settlement.

Names offer and auction reads/retries use the configured network. Bid retries also check their parent auction. A reused key with changed terms returns a conflict. First and later auction bids check the current network’s block height against the bidding window. These source repairs still need real wallet, native SRC-101 and recovery journeys.

The owned Signet node reported a synchronized tip on 3 October. Its observed challenge identifies the connected Signet. Node sync alone does not establish Stamps, SRC-20 or SRC-101 acceptance or a usable product journey.

The candidate deployer checks MySQL 8.4 and the applied schema before migration. The observed production database used MariaDB 10.11.19. Conversion, rollback and the service handoff remain unverified. No public rollout follows from these checks. Read the running version before treating candidate behavior as live behavior.

The work tracks PRODUCT-NAME-02/03/04, SDX28-ROOT-NET-01 and SDX28-OPS-02. Component and database checks do not pass their native acceptance rows. Earlier dated records remain historical evidence.

2026-09-23: Stamps and SRC-20 only

Not deployed. Application pull request 126 removes every protocol except Bitcoin Stamps and SRC-20. Counterparty stays only as the layer that stamps use. The pull request also removes the two gallery pages that shipped behind build flags.

Sections dated before 2026-09-23 name protocols and pages that this change removes. They stay here as historical records. They do not describe current features.

2026-09-18: source-health development candidate

Not deployed. Native release readiness remains NO-GO. Application commit b83dbcdc changes how source-health reads fail and recover. It does not connect missing native protocol services.

A failed TAP, OPNet or Lightning refresh no longer prevents the other source results from being returned. Concurrent reads share unfinished work. A provider wait ends after 30 seconds without starting duplicate unfinished requests. Public error messages omit raw upstream exception details.

Each native source keeps its own observation time. An unobserved protocol does not borrow the Bitcoin tip’s timestamp. Invalid or future times are rejected, and provider-declared freshness limits are enforced. Local clock rollback invalidates affected caches.

The focused source-health suite passes 24 tests in two suites. The backend regression suite, typecheck and targeted lint exit zero. These are controlled component checks, not wallet, native-transaction or deployment evidence.

2026-09-18: ownership recovery candidate

Unreleased candidate. Native acceptance remains NO-GO. Application commit af90d012 adds a distinct error when stamp ownership cannot be verified. A failed lookup is not evidence that a wallet owns zero stamps. The NFT attachment dialog clears its old ownership result and provides Retry ownership check. That action only reads ownership again; it does not sign or broadcast a transaction.

A broadcast transaction still uses the separate Retry confirmation action. Changing wallets or closing the dialog cancels an ownership retry, and a late response cannot replace the new wallet’s state. Unknown server-error details do not become user-facing messages.

Four focused backend suites passed 18 tests; six frontend HTTP tests passed. These are controlled component checks, not a complete wallet or blockchain journey. Browser verification and full CI are tracked in PR 122. No deployment or mainnet functional transaction was performed for this candidate. Read the running version before treating candidate behavior as live behavior. Earlier sections remain historical records.

2026-09-17: authority transport and CI repair

Unreleased repair branch. Functional NO-GO. No deployment. Application pull request 117 preserves the September 16 candidate and adds request and response limits, checkpoint identity checks and rejection of redirects. It also rejects duplicate transaction inputs and malformed warning or script-type fields.

The client checks passed in 100 cases. The five-authority regression suite passed in 192 cases. These are controlled transport and component checks, not funded native transactions. Real protocol recognition, wallet outcomes, finality and recovery still require their own evidence.

CI now stops when an earlier native command fails instead of accepting a later successful command. Eight regression checks cover failure propagation and reuse of the compiled migration runner. Registry and production dependency checks have passed on this pull request; this statement does not certify full application acceptance.

2026-09-16: local authority and dependency repair

Local candidate. NO-GO. Not deployed. This section records work on the isolated application branch codex/stampdex-go-20260916. It does not change the status of the running service or earlier release evidence.

Authority responses now reject contradictory validation and settlement claims. A positive validation result needs a matching manifest, a transaction ID and no errors. Input value must equal output value plus the miner fee. Settlement must keep confirmation, block and finality fields consistent. A rollback acknowledgement must be an empty object. Invalid transaction artifacts return structured errors instead of escaping the contract checks.

The backend pins the affected TOML parser to version 4.2.0 through a narrow dependency override. Eight parser checks, seven native SDK checks and 91 transaction and OPNet unit tests passed locally; the backend build passed. The dependency scan reported zero advisories at the time of this check. These results do not prove a wallet journey, settlement or recovery on an offered network.

Fee panels keep a missing or invalid estimate unavailable rather than showing zero cost. Test-network or unresolved-network transaction IDs remain visible without a mainnet explorer link. Links use the first-party explorer only when the affected operation has explicit mainnet identity. Configuring a display network alone does not prove the source network.

Settlement response checks enforce consistency; native authorities remain responsible for protocol-specific finality. The candidate also supports first-party electrs fee estimates through explicit operator configuration. This is pending rollout and does not supply missing estimates.

Fee rescue now builds an unsigned child transaction for the configured network only after checking the node genesis and parent output script. Local tests decode SegWit and Taproot outputs on mainnet, Signet, testnet and regtest. Wallet signing and a funded network journey remain unverified. Fee-watch counts separate ready from waiting and exclude ended watches. Without functional-cookie consent, the page uses “Watch for this visit” and “Watches for this visit” and warns that refresh or navigation removes them. A local browser check with functional consent verified save, reload, cancel and reopen behavior.

Native authority services, funded wallet journeys, protocol readback and recovery evidence still need acceptance. Rollout remains pending. No production release or mainnet transaction follows from these local checks.

2026-09-06: Arkade and BRC2 record repair

CI checks passed. Native execution remains unavailable. Application commit 8b0d3467 passed Quality run 34043045580. The run covers 1,954 backend unit tests in 231 suites, 46 API tests, migrations, frontend checks, 179 browser tests and the route fixture. Three browser tests remain skipped. These checks do not prove native transactions.

Arkade and BRC2 no longer return fixed native checkpoints or invented execution results. Native writes return HTTP 503 before reading or changing stored records. No boarding address, completed renewal, settlement or VM result is generated. The pages read the APIs and label stored contracts, VTXOs and receipts as unverified history. Stored status does not prove a spendable balance or settlement.

Arkade owner records require a wallet access signature for the requested address. Reads compare addresses exactly, including letter case. Both the original routes and their versioned aliases use these checks. Historical rows remain intact. Read the API contract and limits before updating a client that consumes the old response format.

The source inventory contains 954 API declarations and 1,979 unbound declarations. The registry still has zero PASS rows; all 351 required wallet variants lack accepted witnesses. Native authorities, execution artifacts, recovery and real wallet outcomes remain open, including separate Spark and Lightning gaps. Check the running version for the deployed commit. Earlier sections below are historical snapshots.

2026-09-06: event access repair and CI evidence

CI checks passed. Native readiness remains NO-GO. Application commit 83498787 passed Quality run 34036927184. It records 1,957 backend unit tests across 231 suites, 45 API integration tests, versioned migrations, frontend checks, browser tests and production operation checks. The backend job passed on retry after the first MySQL fixture failed to start. Read the running version for the deployed application commit. CI does not prove deployment or native execution. The earlier sections below describe the state at the time each review was recorded.

Public activity includes only approved event types and fields. Spark position activity requires the owner’s signed wallet proof. Launch activity requires a campaign that is public and no longer a draft. Operator audit results cover stored checkpoints and omit private position counts and IDs. Approved checkpoint events remain public. Seven isolated API and MySQL tests pass for public filtering, signed owner reads, restart, campaign visibility and checkpoint-only operator audits. They use controlled position inputs and generated, unfunded keys. This does not prove installed-wallet behavior, native Spark execution or full application acceptance.

Authority registration and readiness checks do not establish native transaction execution. Missing native builders, settlement sources and wallet witnesses remain open. Earlier test reports do not verify these later changes.

The current source export includes 940 API declarations. Two new owner-event route aliases bring the unbound declaration count to 1,965. The release evaluator records zero PASS rows, and all 351 required wallet variants still lack accepted witnesses.

2026-09-06: implementation program candidate

Local candidate, 6 September 2026. NO-GO. Not deployed. These source changes have no real-wallet, native-network or browser acceptance witness. Earlier captures do not verify this candidate.

Evidence format stampdex-stage-v2 computes comparisons against hash-checked raw JSON and binds stage-relevant operation, asset, actor, source and network identities. Wallet transactions, authenticated publications, anonymous reads and service jobs have different required stages. An anonymous API read does not invent a wallet signature. Old v1 evidence needs revalidation when it lacks these checks.

Selected unit and isolated MySQL checks cover invoice crash recovery, outbox leases, public launch filtering and stable market snapshots. Invoice settlement does not prove lease delivery or seller payment. Mandatory native contracts, inventory, wallet, mobile, accessibility and performance obligations remain open. Quality runs browser jobs, so the no-UI-CI boundary prevents PR integration. No deployment occurred.

2026-09-06: the GO verdict is withdrawn

LOCAL UNRELEASED · FUNCTIONAL NO-GO. The 2026-09-05 registry page that read GO with 123 passing rows is withdrawn. Its verifier compared the registry with itself, so it could not see the endpoints, routes, views, and protocol flags the rows omitted, and it accepted one sentence reused across nine journey stages as proof of a Signet transaction. Those ledgers are kept for audit and rejected by the repaired verifier.

The repaired gate counts every declared surface, keeps one row per review-owned operation (224 SDX- rows), and one variant per wallet per action. It reports five outcomes: PASS, FAIL, BLOCKED, NOT TESTED, and NOT_APPLICABLE, with the network as a separate field. A PASS proven on Signet reads PASS - SIGNET and needs no mainnet run. A production read never turns a row green. A journey needs typed stage records with a transaction id, the node’s broadcast answer, an authoritative confirmation, and protocol recognition.

Sample data was removed from the executable paths: protocol adapters answer only from a configured authority, OP_NET lists no seeded contracts, tokens, or pools, and the OP_NET pages say so. Lightning Direct seller offers are stored against the saved request with a node-signed proof and a HODL invoice from the configured LND node; without that node nothing can be offered or settled. Leather is now part of the wallet network check, and its network read is marked not tested.

No native authority, Signet wallet, or Lightning node is configured where this work ran. Every row that needs one stays BLOCKED or NOT TESTED. Nothing was deployed.

2026-09-05: local, unreleased repairs

LOCAL UNRELEASED · NO-GO. These local changes repair only part of the execution paths. They have not been deployed. Native protocol authorization, transaction builders, persistence, recovery, and end-to-end evidence remain incomplete. Passing focused tests does not verify a trading journey.

OPNet now reads configured native RPC observations and binds offline binary state to stored intents. Swap uses the existing Atomic quote and purchase path with wallet network checks. TAP reads paginated indexer journal updates. Maker RFQ publication stores authorized terms and cancellation records; it does not reserve funds or execute a trade. Native signing fixtures, isolated database tests, and local browser checks cover parts of these paths. Live protocol execution remains unverified.

The local release verifier binds evidence to the tested source, specific workflow, test command, environment, and network. It requires valid timestamps, kind-specific freshness limits, and retained result files whose contents can be checked. Evidence reuse across merge commits requires an explicit source-tree equivalence check. Inverse checks also compare routes, product views, controller endpoints, adapters, and protocol operations against the registry and reject unregistered entry points.

The Spark view now requests pools, wallet positions, quotes, operator checkpoints, and exit previews through the existing API. Request failures show errors instead of invented data or empty success results. An exit preview does not sign or submit a transaction. A stored checkpoint does not prove current finality.

Wallet proof now protects Spark positions and exit previews. Universal Markets reads indexed SRC-20 deployments and stored atomic listings with identity-bound pagination; missing metrics remain unknown. Isolated MySQL tests cover shared lock contention, quote replay, rollback after an outbox failure, and datasource restart. These checks do not prove native protocol execution or a deployed release.

The 2026-08-31 counts and action table below are historical records. They do not prove that the current source or deployed version passes verification.

This page exists because “it is on the site” and “it has been verified” are different claims, and you deserve to know which one applies to the thing you are about to do.

What counts as a version

There is no version number in the application’s package files that means anything. Release identity is two things:

1. Date-based git tags, in the form v2026.08.31.1.
2. The runtime answer from GET /api/version: the application version, the release id, the git commit, the runtime, the build timestamp, and a hash of the dependency lockfile.

The second is the one to quote, because it is what is actually answering you right now. See Status and version.

How verification is recorded

The application repository holds a release capability registry: one row per user job, each naming the evidence that job depends on. Two things about it are worth knowing:

• Rows carry no self-declared status. A verifier derives one, from the evidence.
• There are exactly five derived outcomes: PASS, FAIL, BLOCKED, NOT TESTED, and NOT_APPLICABLE, with the network recorded beside them. There is deliberately no “partial”, no “beta”, and no “planned”. A row either has its evidence or it does not.

BLOCKED means required evidence is missing. It does not mean a defect was found. Those are different things, and this page will not blur them.

Historical snapshot: 2026-08-31

Recorded 2026-08-31, across 51 rows:

Outcome	Rows
PASS	27
NOT_APPLICABLE	3
BLOCKED	21
Recorded decision	NO-GO

Evidence that was recorded and passing at that snapshot included the backend test suite, the frontend test suite, an end-to-end browser suite across desktop and mobile, a route check confirming every route renders exactly one top-level heading, an automated accessibility audit against WCAG 2.1 A and AA, and a production smoke run.

Evidence that was not recorded included controlled mainnet canary runs for SRC-20 mutations and for stamp mutations, live runs of each wallet extension through each action it claims, a regtest chain exercise, a screen reader pass, and first-party data provenance.

Historical action evidence: 2026-08-31

What you are doing	Evidence position
Browsing markets, tokens, stamps, collections, activity	Verified and passing
Reading the API	Verified and passing
Buying or transferring SRC-20	Implemented, unit and integration tested, deployed. No controlled mainnet canary recorded
Buying a stamp, opening or closing a dispenser, sending a stamp	Implemented, unit tested, deployed. No controlled mainnet canary recorded
Anything in the stamp offer lifecycle	Implemented. No canary recorded, and the ecosystem registry records offers as an unsupported marketplace action. See Offers
Relying on automatic reorg reversal	Implemented and unit tested. Not exercised end to end against a real reorg
Using a wallet marked “Not tested” on the wallets page	StampDEX can ask that wallet for the action and nobody has run it

None of that says an action will fail. It says nobody has recorded proof that it succeeded on mainnet under controlled conditions. Trade accordingly, and start small with anything in the lower half of that table.

What is deliberately not implemented

• An atomic swap for SRC-20. The listing flow is a three-transaction escrow with a server-held intermediate key. See Where your funds are.
• An in-place listing price update. See Change a listing price.
• A local reorg rollback worker at the Universe layer. The ecosystem registry records reconcile as unsupported for both protocols.

Where the platform record lives

Independently of the application’s own registry, the Bitcoin Universe ecosystem capability registry records which marketplace actions are supported and, for each one that is not, the reason. That record is the authority on what counts as a supported way to trade. See What you can and cannot do.

Related

• Status and version
• Changelog
• Safety and trust

2026-09-17: checkpoint and fee-watch follow-up

Application PR 118 binds each chain checkpoint hash to the height it read. Concurrent requests share that read without retaining a stale result. All 107 mempool regression checks passed. A read from the actual service matched an independent Bitcoin Core query on default Signet. This is read-only integration evidence, not a funded protocol journey.

Application PR 120 stops Fee Watch from using a cached low fee after a failed refresh. Saved active states are recalculated; done and cancelled states are preserved. Three rendered-component assertions failed before repair and all 16 focused checks passed after it. The browser recovery scenarios use controlled API responses. A watch does not send a payment or prove settlement.

The isolated application also started after all 45 migrations created its separate test schema. This does not establish every native authority, wallet or indexed protocol outcome. Functional GO remains unproven, and these changes do not deploy the website.