Data Infrastructure / Developer Tools
A blockchain proof is useful only if it still verifies later.
That became a practical engineering problem for Traceport during an October 31 BSV Blockchain mainnet test in which developer Bridget Doran reports that the service accepted 99,879 attestations over roughly six and a half hours.
The more consequential result came after submission.
According to Doran, three blockchain reorganizations during the test left 26,581 stored Merkle proofs pointing to blocks that were no longer part of the active chain. Traceport’s subsequent verification process detected those affected proofs, and Doran developed and tested a recovery path that ultimately allowed all 99,879 accepted attestations to verify against the winning chain.
The original recovery was not fully automatic during the live run. Doran says she first repaired the affected proofs after the test, then built and tested an automated fallback using the actual October 31 reorganization data.
That makes the episode more interesting than a throughput result alone. It tests what happens to business-record evidence when the blockchain state around that evidence changes.
What Traceport Attests
Traceport is designed to give business records independently verifiable blockchain evidence without requiring the underlying business data itself to be made public.
An application hashes its original data locally using SHA-256 and submits that hash to Traceport.
Traceport returns a blockchain transaction reference and verification information, while the original record remains under the control of the organization or application using the service.
The public API documentation describes possible uses including audit records, supply-chain events, certifications, contracts and other business data.
Verification then occurs in layers.
A verifier can check that the attestation transaction exists in the blockchain, verify the digital signature and organization-specific identity information, and—when the original record is supplied—confirm that its hash matches the value that was attested.
The blockchain proof therefore establishes evidence about the submitted hash and its transaction history. It does not require Traceport to retain the original business document itself.
The Test Was More Than a Submission Count
Doran reports that the October 31 run accepted 99,879 attestations, with one failed request.
The test ran for approximately six and a half hours, at a reported average of around 4.4 requests per second.
Median time from an API request to receiving a transaction ID was about 230 milliseconds.
That timing needs an important qualification.
The 230-millisecond figure measures how quickly the application received a transaction ID. It is not a measurement of blockchain confirmation time or settlement finality.
The test therefore provides information about Traceport’s submission path and application response rather than establishing a 230-millisecond confirmed-record guarantee.
The more useful finding appeared when the stored proofs were checked later.
When a Block Is Replaced
A transaction included in a block can be accompanied by a Merkle proof showing that the transaction belongs to that block.
Traceport’s public verification documentation describes this using BUMP, the BSV Unified Merkle Path format defined by BRC-74. The verifier reconstructs the block’s Merkle root from the transaction and proof, then checks that root against block-header information.
A blockchain reorganization complicates that relationship.
If a competing branch becomes the active chain, one or more blocks that were previously accepted may be replaced.
A transaction from a replaced block may later appear again in another block on the winning chain.
But its old Merkle proof remains tied to the block that was replaced.
The transaction itself may therefore still be valid and present on-chain while the previously stored inclusion proof is no longer the proof that should be used to establish its place in the current chain.
For applications intended to preserve evidence over long periods, that distinction matters.
26,581 Proofs Were Affected
Doran reports that Traceport encountered three mainnet reorganizations during the October 31 test.
When she later ran a verification sweep across the accepted attestations, 26,581 stored proofs were associated with blocks affected by those reorganizations.
That did not mean 26,581 attestations had disappeared.
It meant their stored inclusion evidence needed to be reconciled with the winning chain.
Traceport therefore had to find updated proof information for transactions that had survived or been included again after the reorganization.
Most of the affected records could be repaired through the existing retrieval path.
A second problem then appeared.
Spent Outputs Complicated Proof Retrieval
Doran reports that 12,724 remaining proofs could not be repaired through the same mechanism because the corresponding transaction outputs had already been spent.
That exposed a practical dependency in the proof-retrieval path.
An application may need historical inclusion evidence for a transaction long after the outputs created by that transaction have ceased to be unspent.
A service optimized around current spendable state may therefore not always be sufficient as the only source for historical proof recovery.
Doran says she addressed the remaining cases using her own block-header infrastructure and an alternative recovery path.
The result, according to her published account, was that all 99,879 accepted attestations eventually verified against the active chain.
This is developer-reported testing rather than an independently audited result, but it exposes a useful operational problem that is easy to overlook when discussing permanent blockchain records.
The Repair Was Developed After the Live Run
The chronology matters.
The initial October 31 test did not encounter each reorganization and automatically repair every affected proof in real time.
Doran explains that the first recovery was performed manually after the run as she investigated the failed verification cases.
She then implemented an automated fallback and tested it against the actual reorganization data from October 31.
That means the development has two stages:
the live test exposed the proof-recovery problem, and the subsequent engineering work produced an automated mechanism intended to handle the same condition.
BSV TIMES has not independently verified that this fallback is now operating continuously in Traceport’s production service, so it should not yet be described as a demonstrated live automatic recovery system.
What has been demonstrated publicly through Doran’s account is the failure condition, the manual repair, and a later test of the automated fallback using the same real reorganization data.
Submission and Long-Term Verification Are Different Problems
This distinction is particularly relevant for business infrastructure.
A system may successfully write a transaction and immediately return its identifier.
That proves the application succeeded in submitting something useful at that moment.
But an attestation service has a longer obligation.
Months or years later, somebody may want to verify that a particular business record corresponds to a transaction included in the accepted blockchain history.
For that purpose, the quality of the retained evidence matters as much as the original submission.
Traceport’s October test therefore exercised two different parts of the system.
The first was processing: accepting large numbers of attestation requests, assigning organization-specific cryptographic identities and returning transaction references.
The second was evidence maintenance: detecting when stored proofs no longer corresponded to the winning chain and restoring evidence that did.
For long-lived business records, the second problem may ultimately be the more important one.
A Blockchain Record Is Not Just a TXID
It is tempting to treat a transaction ID as the permanent proof.
But independent SPV-style verification requires more context.
A verifier needs to establish that the transaction was included in a block accepted by the chain being verified. A Merkle path supplies the relationship between the transaction and the block’s Merkle root, while block headers allow that root to be checked against the chain.
Traceport’s documentation explicitly describes its proof-of-existence verification in those terms.
That makes proof maintenance an infrastructure concern of its own.
If a reorganization changes the block in which a transaction is recognized, an application preserving long-term evidence needs to notice that its earlier proof has become stale and obtain a current one.
The underlying transaction history can remain intact while the application’s stored evidence needs updating.
Reorganizations Are an Operational Condition, Not an Exception to Ignore
Blockchain reorganizations are not necessarily evidence that something has gone wrong with the protocol.
Competing blocks can occasionally appear, and one branch ultimately becomes the accepted continuation of the chain.
For an application working close to the network, the important question is how it responds.
A proof system that assumes the first observed block association will remain permanent risks silently retaining evidence that no longer validates against the active header chain.
Traceport’s October test is useful because this was not only a hypothetical scenario.
According to Doran’s report, the application encountered reorganizations during an actual mainnet run, later detected the resulting stale proofs, and used those cases to develop a recovery mechanism.
That gives the test practical relevance beyond its transaction count.
From Throughput Testing to Evidence Resilience
Nearly 100,000 attestations is an eye-catching number.
But the stronger infrastructure story is what happened to the evidence afterward.
Traceport is designed around the idea that business records should remain independently checkable without depending indefinitely on Traceport itself. Its public API documentation says verification references can be used independently and that original data remains under the customer’s control.
For that promise to be useful, the blockchain evidence accompanying those records also has to remain valid as network history settles.
The October 31 test exposed one way that evidence can become stale without the underlying business record or transaction itself becoming invalid.
Doran’s reported recovery work addresses that operational gap.
The next useful milestone would be clearer public evidence that the automated fallback is integrated into Traceport’s continuing service and can detect and repair future reorganizations without manual intervention.
For now, the test demonstrates something more valuable than a simple request-rate benchmark: large-scale record submission was followed by a real mainnet condition that challenged stored proofs, creating an opportunity to test how long-lived verification evidence can be repaired rather than silently abandoned.
Developer Context
Bridget Doran (HBGnostic) develops Traceport through her broader UTXO Engineer work.
Related public projects include:
- Traceport — blockchain-backed attestation and business-record verification infrastructure.
- Teranode Explorer and related network infrastructure tooling.
- BSV Fundamentals — developer education focused on BSV Blockchain architecture.
- Bitcoin Bytes and other interactive transaction and Script explainers.
- Bridget’s General Store / shomee work — BRC-100 wallet-connected commerce, covered separately by BSV TIMES.
The Traceport test represents a different side of that work: not user-facing wallet commerce, but preserving independently checkable business evidence under real network conditions.
Source Links
Traceport — Verification Methods
The October 31 test figures, reorganization counts and recovery chronology are based on Bridget Doran’s public reporting and follow-up explanations. BSV TIMES has not independently audited the test logs or recovery results.
BSV TIMES – Under the Surface
Under the Surface looks at projects, standards, experiments, and community activity that may not rise to the level of a headline but are still worth noticing. Some are new, some are continuing work, and some are quieter developments that help show what is taking shape across the BSV community.
Update — November 5, 2026
Leave a Reply