Trust Model
The ALX trust model separates deterministic protocol verification from application-defined trust. ALX establishes properties of Block identity and declared parent relationships without assigning authority, meaning, or trust to the people, systems, or infrastructure associated with those Blocks.
Protocol Guarantees
Block validation establishes that recorded identities correspond to protocol data. Graph verification, a separate claim, establishes within a Verification Context that every examined Block and required parent relationship satisfies the protocol rules. A missing parent produces incomplete, not invalid.
Core verification requires no trusted service, signer, storage provider, registry, or blockchain. Trust Boundary lists the exact claim each result supports.
Application Authority
Applications decide whether verified Blocks are accepted, trusted, displayed, executed, or used in downstream decisions. Accounts, API keys, sessions, storage permissions, and transport authorization remain application concerns. Application policies define:
- Accepted Blocks and sources
- Trusted signers and attestations
- Storage and discovery systems
- Users and systems permitted to perform actions
- Recognized external commitments
- Accepted chains, contracts, and finality policies
- The effect of verification results on application behavior
- External Roles
- Evidence Inputs
- Changes in Trust
Any address can publish a commitment to ALXAnchor; applications define the publishers and authorities that verifiers accept.
| Role | Responsibility |
|---|---|
| Application | Defines acceptance policy, permissions, and trusted external authorities. |
| Commitment publisher | Publishes a Block-derived commitment through an external mechanism. |
| Verifier | Selects and evaluates protocol data, proof, commitment, and external context. |
Roots, chain context, and proof data establish only mechanism-specific properties.
| Input | Trust consideration |
|---|---|
| Commitment value | Identifies the Block-derived value or Merkle root hash being evaluated. |
| Chain and contract | Identify where a commitment is recorded. |
| Finality policy | Determines when an application considers a commitment settled. |
| Proof data | Supplies the values required to evaluate Merkle inclusion. |
| Application metadata | Requires its own integrity, authenticity, and availability checks. ALX verification does not cover application metadata. |
External authority changes affect future acceptance policy without changing Block identity.
Block identity stays the same while content and normalized declared parent relationships stay the same. Signer rotation, contract upgrades, chain reorganizations, policy changes, or changes in accepted authorities can change whether an application accepts future or previously observed evidence; none of them changes the underlying Block identity.
A signature from a key that is later compromised still verifies, and the signer-supplied attestation timestamp cannot show that signing happened before the compromise. Applications that accept attestations track key validity and revocation themselves.
When to Use This Model
Use the trust model when selecting signers, Merkle root hashes, proofs, chain state, and external policies for an application.