GravityBTC

Contents

Valid Settlement Does Not Prove Valid Origin

Preserving verification across layered Bitcoin systems

More bitcoin will move through layered institutional systems: sidechains, bridges, custodians, exchanges, settlement providers, accounting systems, and tokenized representations.

Bitcoin may remain secure while those systems manufacture invalid claims on bitcoin.

This creates a verification problem that cannot be resolved by pointing only to the final Bitcoin transaction. Bitcoin can establish that a transaction was validly included in its ledger. It cannot, by itself, establish that an upstream representation was legitimately issued, continuously backed, correctly validated, or properly authorized before its consequences reached Bitcoin settlement.

Base-layer settlement and upstream validity must therefore remain distinct evidentiary questions.

A layered system may validate an object once, retain the result, and later reuse that result. This can improve efficiency. It can also create a dangerous separation between the evidence originally examined and the object later receiving the benefit of that examination.

If a valid result becomes attached to different data, a changed object, a later state, or an insufficiently identified representation, downstream systems may inherit the conclusion without inheriting trustworthy evidence that the conclusion still applies.

The result is not necessarily a visibly broken transaction history. The system may continue operating. Later transactions may reference existing outputs correctly. Signatures may be valid. Records may remain internally consistent. The final Bitcoin transaction may settle exactly as Bitcoin requires.

Yet the upstream claim on bitcoin may still have an invalid origin.

A transaction graph establishes relationships

Bitcoin transactions do not exist as isolated records.

Each input in a non-coinbase transaction references a specific output created by an earlier transaction. That reference—identified by a transaction identifier and output index—creates a direct and reproducible relationship between two transactions.

When those references are followed across multiple transactions, they form a transaction graph. The graph is derived from Bitcoin-native previous-output references. It is not created by an explorer’s labels, a wallet’s interpretation, or an analyst’s attribution.

Consider the following structure:

```text

TX100 → TX200 ┐

├→ TX500

TX300 → TX400 ┘

```

TX100, TX200, TX300, and TX400 are ancestral to TX500.

The direct previous-output relationships are:

TX200 and TX400 are the direct transaction parents of TX500. TX100 and TX300 are earlier-generation ancestors.

TX500 demonstrates multi-input convergence because it references previous outputs from two separate transaction branches. The complete structure demonstrates multigenerational ancestry because the relationships extend across more than one generation.

Another examiner can follow the same previous-output references and reproduce the same structure.

That reproducibility gives the transaction graph authority within a defined boundary.

However, it cannot establish why those relationships exist, who possesses authority over them, or whether an asset or institutional claim entering the structure had a valid origin.

That limitation becomes consequential when a layered system incorrectly treats one object as having already satisfied a required validation. If a prior result is reused for different data, an invalid representation may enter the system as accepted state. Downstream components may then process that representation normally, recognize it as redeemable, and authorize the release of real bitcoin.

The resulting Bitcoin transaction may be entirely valid. Its inputs may reference existing unspent outputs, its signatures may satisfy the applicable spending conditions, and its confirmation may be independently reproduced. The transaction graph will accurately preserve how the bitcoin moved.

However, the graph will not reveal that the upstream representation obtained accepted status through a broken relationship between the object and its validation evidence. Once the consequences reach Bitcoin, valid transaction ancestry can coexist with invalid institutional origin.

The graph is therefore necessary but insufficient. It can establish the settlement path. It cannot establish that the upstream state which caused the settlement was legitimately created, correctly validated, properly backed, or authorized for redemption.

Examination using Bitcoin mainnet transactions

The same relationship classes were examined using transactions observed from Bitcoin mainnet. The evidence was recorded within an active-chain observation context, with the examined research state identifying a chain tip height of 964958. The underlying research record preserves the complete transaction identifiers, resolved outpoints, deterministic checks, and evidence classifications used to support the findings. The purpose was not to determine who controlled the transactions or what economic activity they represented. The purpose was to determine which relationships could be established directly from Bitcoin-native evidence.

One examined transaction was:

`1f55061a1c844e0858af70f530d307510506d5bcb2b1d026ebf47274eb729a79`

Four separate outputs created by this transaction were later referenced by four distinct spending transactions:

| Referenced parent outpoint | Spending transaction | Observed spending height |

|---|---|---:|

| `1f5506…9a79:65` | `1366ffc726acf5db75b09598c362e9fa31ae14276e1c6c54cb168a1cf535b3da` | 964947 |

| `1f5506…9a79:78` | `bad4eea63dc381458752c3ac11ac43c0a0c3f49d08f2973dc2e019ad39296673` | 964947 |

| `1f5506…9a79:92` | `1b02db3fac7140d2f31c2a4040200c174f5ec5a81e1067f843ebf61ca3d9a952` | 964947 |

| `1f5506…9a79:45` | `a15cebcc4e174bb338b376ea6856ae79a551b087c3ab9f8ba20c4afcd25ce589` | 964954 |

For each relationship, the transaction input’s referenced transaction identifier resolved to the identified parent transaction, and the referenced output index resolved to the corresponding output.

The examination therefore established four direct previous-output relationships. It also established transaction divergence: separate outputs from one parent transaction were referenced by four distinct later transactions.

Those four transactions consequently share a common transaction ancestor:

`1f55061a1c844e0858af70f530d307510506d5bcb2b1d026ebf47274eb729a79`

The examination then followed the transaction structure another generation backward.

Transaction:

`2e0e396ebf9f854a311cca14dbeae64cf2a410fee91f4d1a2531e3f7af925392`

created outputs—including outputs `10`, `18`, `36`, and `40`—that were later referenced by transaction `1f5506…9a79`. Outputs from `1f5506…9a79` were subsequently referenced by the four later transactions.

The examined structure can therefore be represented as:

```text

2e0e39…5392

│

▼

1f5506…9a79

┌───┼────────┬────────┐

▼ ▼ ▼ ▼

1366… bad4… 1b02… a15c…

```

The abbreviated identifiers are used only for readability. The complete transaction identifiers and referenced output indexes remain part of the underlying examination record.

This examination established:

A separate mainnet transaction was examined for multi-input convergence:

`d69f3c8a548afed09d1167c3aee72f242ede981ae3c09a89f26c42891b643a8e`

Its four examined inputs referenced outputs from four distinct parent transactions:

The referenced transaction identifier for each input matched the transaction identifier of the resolved previous transaction. The examination therefore established an observed four-input topology and the convergence of four distinct previous outpoints into one later transaction.

These findings required no wallet label, entity attribution, ownership claim, or external description of economic purpose. They were established through Bitcoin-native transaction references.

The findings also demonstrate their own limit.

The examination established how the transactions relate to one another. It did not establish whether the state represented by those transactions was legitimately created, correctly validated, properly backed, or authorized by any external institution.

The transaction structure remains reproducible. Its institutional meaning does not arise from that structure alone.

The graph does not establish every meaning attached to it

The graph establishes that transaction relationships exist. It does not, by itself, establish who owns, controls, or gives meaning to them.

An assertion that transactions belong to the same person is an attribution. Attribution introduces meaning that the transaction graph does not contain.

The transaction structure may be cited as part of the evidence supporting an attribution. The attribution does not become a Bitcoin-established fact merely because it refers to Bitcoin data.

The graph does not independently establish:

When the source and authority of externally supplied meaning are not preserved, ambiguity enters the record. As that record crosses systems, the ambiguity becomes uncertainty concerning identity, control, purpose, and provenance.

But the boundary extends further than identity.

The graph also does not establish that every asset represented within its structure was legitimately created, correctly validated, continuously backed, or properly authorized before entering the graph.

A transaction can possess valid descendants without possessing a valid origin.

Accepted state is not necessarily valid state

Layered systems frequently rely on prior validation.

A service may accept an asset because another component reports that it has already been examined. A bridge may release an underlying asset because the corresponding representation exists in accepted upstream state. A custodian may recognize a balance because an internal ledger reports it. An auditor may rely on a system-generated status because the system represents that its controls operated.

Every one of these arrangements depends on a relationship between an object and the evidence supporting its accepted state.

That relationship can be represented as a validation lineage:

```text

Exact object

↓

Validation method and version

↓

Observed system state

↓

Validation result

↓

Accepted downstream state

↓

Bitcoin settlement

```

Each arrow represents a claim.

The exact object was examined. The declared method was applied. The relevant state was observed. The result corresponds to that object. The downstream system received the same result under the same governing conditions. The eventual settlement reflects the consequences of that accepted state.

If the validation result becomes detached from the exact object originally examined, the lineage breaks:

```text

Object A → Valid result

╲

╲ result incorrectly reused

↓

Object B → Accepted state → Downstream processing → Bitcoin settlement

```

Object B may then acquire an internally coherent transaction history. Its later transactions may reference existing outputs correctly. Its movement may be reproduced through a transaction graph.

None of that repairs the broken relationship between Object B and the validation evidence produced for Object A.

The downstream record can therefore be coherent while the upstream validity claim is false.

Valid ancestry does not cure invalid origin.

Three different continuities

Reliable examination of layered Bitcoin systems requires at least three separate forms of continuity.

### Reference continuity

Reference continuity asks whether the later transaction or record correctly references an earlier output or object.

This is the continuity demonstrated by the mainnet examination. The four spending transactions either reference the declared outputs from `1f5506…9a79` or they do not. The relationship is bounded and reproducible.

### Validation continuity

Validation continuity asks whether the exact object and every material state transition were correctly examined under an identifiable method and governing state.

It requires more than a status label declaring an object valid. It requires a retrievable relationship among the object, the evidence, the method, the system state, and the result.

### Asset continuity

Asset continuity asks whether the represented asset remained legitimately issued, backed, authorized, and redeemable while crossing systems.

A representation of bitcoin may circulate through an internally consistent ledger. That consistency does not independently establish that the corresponding bitcoin entered reserve custody, remained available, or was properly released.

These continuities are related, but they are not interchangeable.

Reference continuity does not establish validation continuity. Validation continuity does not automatically establish asset continuity. Asset continuity cannot be inferred merely from the existence of a later valid Bitcoin transaction.

The danger of inherited verification

The phrase “already verified” can conceal a material evidentiary boundary.

Verified by whom?

Which object was examined?

Which representation of that object was examined?

Which software and rules performed the examination?

Which system state governed the result?

Under what authority was the result issued?

What downstream action was the result permitted to authorize?

Has any relevant data changed?

Was the result produced for the current object or inherited from another object?

Can the original evidence still be retrieved?

What limitations accompanied the result?

Without answers to those questions, verification becomes an assertion inherited from an upstream system.

Downstream systems may execute correctly while relying on that assertion. Their correctness does not independently repair the upstream failure. Instead, their correct operation may propagate the consequences more efficiently.

This is especially consequential when the downstream system releases real bitcoin.

Bitcoin evaluates the transaction presented to it according to Bitcoin’s own rules. It does not examine every institutional representation, reserve obligation, internal ledger, bridge decision, or upstream validation event that caused a party to construct and authorize that transaction.

Bitcoin can therefore settle validly while an upstream system has acted on invalid state.

Bitcoin did not fail in that circumstance. Bitcoin accurately recorded the settlement consequences of a failure outside its evidentiary boundary.

Conditions for portable verification

Verification cannot become portable merely because its conclusion can be copied. A portable result must preserve the evidence necessary to determine whether the conclusion still applies.

At minimum, that requires exact object binding, method binding, state binding, authority binding, freshness, and retrieval.

### Exact object binding

Every result must identify the precise object examined.

A statement that “the transaction was verified” is incomplete unless the record establishes which transaction representation, proof data, supporting inputs, and associated artifact were examined.

A valid result cannot safely migrate to another object merely because the objects share an identifier, appear equivalent, or occupy the same operational category.

Object identity must be demonstrated, not assumed.

### Method binding

Every result must identify the method and version used.

Verification is not an abstract event. It occurs through particular software, rules, configurations, dependencies, and decision procedures.

If those change, the meaning or reliability of the result may change. A later reviewer must be able to determine which method produced the conclusion and which limitations applied to it.

### State binding

The relevant chain, node implementation, observation time, confirmation state, policy state, and external-system state must remain attached to the result.

A conclusion reached under one state must not silently represent another. The fact that a result was valid at one moment does not establish that it remains valid after the examined state changes.

### Authority binding

Every result must preserve the authority under which it was produced and the downstream action it was permitted to support.

A technical result establishing that one validation step succeeded must not silently become authority for issuance, backing, redemption, or settlement.

A record may preserve the correct object and remain cryptographically intact while being used under an authority it never possessed.

A record can preserve the right object while carrying the wrong authority.

### Freshness

An earlier valid result must not silently authorize changed data or a later state.

Cached or inherited verification can improve efficiency, but it creates a corresponding obligation: the system must demonstrate that the earlier result still corresponds exactly to the present object and governing conditions.

Otherwise, a historical result becomes an unsupported present assertion.

### Retrieval

A later examiner must be able to recover the evidence and determine exactly what the result did—and did not—establish.

A hash, status flag, or “verified” label is insufficient when the underlying object, method, state, authority, and limitations cannot be retrieved.

Institutional verification should remain intelligible after the original interface changes, the implementation is replaced, the operator becomes unavailable, or the result is challenged.

Verification must survive system boundaries

Interoperability is often treated as a question of whether assets, messages, or identifiers can move between systems.

That is only technical transferability.

Reliable interoperability also requires evidentiary continuity. Each receiving system must be able to distinguish:

A system boundary does not require two separate organizations.

The boundary may exist between a validator, cache, internal ledger, bridge process, settlement worker, accounting system, or audit process operated by the same institution. The evidentiary problem begins whenever one component consumes another component’s conclusion without preserving the object, method, state, authority, and limitations that governed it.

Without that separation, an upstream conclusion may enter a downstream system stripped of its original assumptions and limitations.

The conclusion travels. The evidence does not.

Once that happens, accepted state can acquire the appearance of independently verified state merely because several downstream systems repeat it.

Repetition is not independent verification.

Extending Bitcoin’s verification ethos

Bitcoin’s “don’t trust, verify” principle cannot stop at the base-layer transaction when institutional systems are creating and processing claims on bitcoin above it.

Those systems must preserve the lineage of their own verification.

This does not mean Bitcoin should adjudicate institutional records, contractual rights, ownership disputes, reserve obligations, or external representations. Those subjects remain outside Bitcoin’s consensus authority.

It means institutions should not use Bitcoin settlement to imply that Bitcoin validated everything that occurred before settlement.

Bitcoin may establish that value moved. It does not necessarily establish why the movement occurred, whether the upstream representation was legitimate, whether the correct process authorized it, or whether the institutional obligation connected to it was satisfied.

The verification boundary must remain visible.

The role of independent examination

Independent examination can help preserve this boundary.

It can preserve what Bitcoin establishes, identify where external validity begins, and prevent conclusions from traveling farther than their evidence.

It can record the exact object examined, the method used, the relevant system state, the resulting observation, and the limits of that observation. It can make the record retrievable so another examiner can reproduce the Bitcoin-native portion without inheriting every institutional assertion attached to it.

It cannot make an invalid upstream asset valid. It cannot infer legal authority from settlement alone. It cannot turn a representation into its underlying asset or convert an external assertion into a Bitcoin fact.

Its value lies in preserving the boundary.

Conclusion

The mainnet examination established direct previous-output relationships, transaction divergence, multi-input convergence, common transaction ancestry, and multigenerational ancestry from Bitcoin-native evidence.

Those findings are meaningful and reproducible.

They do not establish identity, ownership, economic purpose, valid issuance, continuous backing, institutional authority, or upstream legitimacy.

A layered system may preserve reference continuity while losing validation continuity and asset continuity. Once invalid state enters an accepted transaction history, later transactions can remain internally coherent and eventually produce valid Bitcoin settlement.

That settlement does not retroactively validate the origin.

As more bitcoin moves through institutional layers, verification must remain bound to the exact object, method, state, evidence, authority, and limitations that produced it.

Bitcoin records settlement.

The systems built around Bitcoin must preserve the validity provenance that Bitcoin does not—and cannot—supply.

Publication Verification

Publisher
GravityBTC
Publication ID
PUB-20260929-VALID_SETTLEMENT_DOES_NOT_PROVE_VALID_ORIGIN
Verification Record
Open verification record
SHA256
Recorded in the publication verification record
Standard
Gravity Publication Authority Pipeline v1.0