# Asset–Token Binding

Asset–token binding defines how an off-chain asset is **anchored, referenced, and kept in sync** with its on-chain representation. This is one of the most sensitive areas of RWA tokenisation: weak binding leads to over-issuance, misrepresentation, or loss of confidence, while over-binding creates false claims of enforceability.

The Invest Network approach treats binding as a **continuous relationship**, not a one-time event.

***

#### Purpose of Binding

The binding layer exists to ensure that:

* each tokenised unit corresponds to a defined off-chain claim
* on-chain supply does not drift from real-world issuance
* changes in asset state are reflected explicitly
* discrepancies can be detected early

Binding does **not** attempt to transfer physical or legal custody to the blockchain. It provides **referential integrity**, not possession.

***

#### Binding at Issuance

At issuance, binding establishes the initial correspondence between the asset and the token.

This includes:

* identifying the asset instance or pool
* defining the unit of representation (e.g. share, claim, entitlement)
* setting maximum authorised supply
* linking to legal and custodial documentation

Once established, this binding becomes the reference point for all future state transitions.

***

#### Proof of Existence and Ownership

Where possible, binding is supported by proofs or attestations.

Examples include:

* confirmation that the asset exists
* confirmation of custodial arrangements
* confirmation of issuer authority

These proofs are:

* attributable to specific roles
* time-stamped
* updateable

They are treated as **inputs to protocol logic**, not unquestionable truth.

***

#### Ongoing Reconciliation

Binding is maintained over time through reconciliation, not assumption.

Reconciliation may include:

* periodic attestations
* event-based updates (e.g. asset sale, impairment)
* confirmations tied to lifecycle events

The protocol does not infer continued correctness from silence. Missing updates are treated as **signals**, not ignored.

***

#### Handling Asset State Changes

Real-world assets change state.

Examples include:

* partial repayment or drawdown
* yield distribution
* impairment or default
* maturity or termination

State changes must be:

* explicitly declared
* mapped to on-chain effects
* constrained by predefined rules

If a change cannot be mapped safely, defensive measures such as transfer restrictions or freezes are available.

***

#### Divergence Between On-Chain and Off-Chain State

The architecture assumes divergence is possible.

When divergence is detected or suspected:

* on-chain activity can be restricted
* issuance may be halted
* escalation paths are triggered

The protocol prioritizes **containment over continuity**. It is safer to pause than to propagate incorrect state.

***

#### No Implicit Rebinding

Once an asset is bound, it cannot be silently replaced.

Rebinding — for example, swapping the underlying asset — requires:

* explicit disclosure
* governance approval
* clear state transition

This prevents the common failure mode where tokens quietly drift away from their original backing.

***

#### Transparency of Binding Relationships

All binding relationships are:

* visible on-chain
* auditable historically
* attributable to specific actors

Participants can inspect:

* what asset a token represents
* who attested to its state
* when updates occurred

This transparency enables independent risk assessment rather than blind trust.

***

#### Binding Does Not Guarantee Value

A critical distinction: binding does not guarantee that an asset retains value.

If an asset:

* defaults
* loses value
* becomes unenforceable

the binding reflects that reality — it does not mask it.

The protocol preserves **truthfulness**, not performance.

***

#### Why Conservative Binding Matters

Many RWA systems fail by:

* over-asserting asset backing
* assuming custodial infallibility
* hiding state changes

This binding model avoids those failures by:

* treating off-chain reality as dynamic
* making updates explicit
* allowing safe failure

The result is a system that can be trusted **because its limits are visible**.