Skip to main content
Author - Maka Pono

LIFE Specification (V1)

Privacy, Transparency, and Contextual Separation​

1. Purpose of This Specification​

This specification defines how LIFE enables privacy and transparency simultaneously, without contradiction.

The goal is not to hide activity.
The goal is to place control of visibility with the individual.

LIFE accomplishes this through contextual separation, derived identifiers, and consensual disclosure, rather than global obfuscation.

2. Core Principle​

Privacy in LIFE is achieved through separation and consent, not darkness.

Transparency exists when chosen.
Privacy exists by default.

3. Life Environments and Contextual Wallets​

Each participant in LIFE may operate across multiple Life Environments, such as:

  • Mexican Life
  • Canadian Life
  • American Life
  • Aotearoa Life
  • Saudi Life
  • Pacific Life

Each Life Environment defines:

  • A base currency
  • Jurisdictional rules
  • Cultural defaults
  • Disclosure expectations

Within each environment, the participant may maintain one or more Contextual Wallets.

A Contextual Wallet is not an identity.
It is an expression of identity under a specific context.

4. Wallet Separation Model​

4.1 Multiple Wallets per Participant​

A single LIFE identity may control multiple wallets without linking them publicly.

Wallets are intended to be:

  • Purpose-specific
  • Jurisdiction-specific
  • Disclosure-scoped

Example:
A participant may:

  • Transact daily in a Mexican Life wallet
  • Save long-term assets in a Canadian Life wallet

These wallets do not imply discoverability of each other.

4.2 No Assumed Linkage​

The LIFE Protocol does not assume that two wallets controlled by the same participant are related.

Any linkage must be:

  • Explicitly granted
  • Temporarily scoped
  • Cryptographically authorized

5. Address Derivation and Public Exposure​

5.1 One-Time Receiving Addresses (Normative)​

When receiving value, a wallet should not expose a static public address.

Instead, wallets derive ephemeral receiving addresses for each transaction or session.

This prevents:

  • Asset enumeration
  • Balance inference
  • Long-term clustering

This mechanism is derived from LIFE’s broader principle of derived authority.

5.2 Outbound Transactions​

Outbound transactions may originate from a stable wallet context, but should not reveal inbound structure.

Implementations may use:

  • Internal aggregation
  • Delayed batching
  • Derived sending keys

Exact mechanics are intentionally private.

6. Wallet-to-Wallet Transfers (Critical Section)​

6.1 Prohibited Pattern (Direct Linkage)​

A direct, observable transfer from Wallet A to Wallet B creates a durable correlation.

This pattern is discouraged except when transparency is intentionally desired.

6.2 Recommended Pattern (Context Exit + Context Entry)​

When a participant wishes to move value between wallets:

  • Value exits Wallet A under a neutral settlement context
  • Value enters Wallet B via a new derived receiving address
  • No public statement asserts shared ownership

From an external perspective:

  • Wallet A paid a settlement
  • Wallet B received value

No public evidence links the two.

7.1 View Capabilities​

Participants may grant view-only disclosure capabilities to third parties.

These capabilities may be:

  • Time-bound
  • Scope-limited
  • Revocable

Examples:

  • Tax reporting
  • Audits
  • Family oversight
  • Regulatory compliance
  • Dispute resolution

Transparency is intentional, not accidental.

7.2 No Global Transparency Requirement​

LIFE explicitly rejects the idea that all participants must be transparent to all observers.

Transparency without consent is surveillance.

8. Network Metadata Protection (Non-Optional Guidance)​

Privacy at the ledger level is insufficient if network metadata correlates identity.

LIFE implementations should avoid:

  • Static broadcast endpoints
  • Repeated timing patterns
  • Deterministic transaction fingerprints

Exact mitigations are implementation-specific and intentionally not standardized.

9. Relationship to Zero-Knowledge Proofs​

9.1 ZK Is Optional, Not Foundational​

LIFE does not require zero-knowledge proofs for baseline privacy.

Privacy is achieved primarily through:

  • Contextual separation
  • Derived identifiers
  • Scoped disclosure

9.2 Approved ZK Use Cases (Optional Modules)​

Zero-knowledge proofs may be introduced as optional modules for:

  • Proof of reserves
  • Proof of compliance without identity
  • Threshold attestations

ZK is never required to:

  • Hold value
  • Transact
  • Maintain identity continuity

10. E-Commerce Implications (Developer Guidance)​

For Digital World e-commerce systems:

  • Merchants should receive ephemeral payment addresses
  • Customers should not expose long-term wallets
  • Refunds should use new receiving contexts
  • Loyalty and rewards should attach to LIFE identity, not wallet addresses
  • Reporting uses view disclosure, not scraping

This enables:

  • Privacy-respecting commerce
  • Regulatory compliance
  • User trust
  • Platform neutrality

11. Security Posture Summary​

This model provides:

  • Privacy without obfuscation
  • Transparency without surveillance
  • Compliance without custody
  • Scalability without fragility

It remains aligned with identity continuity systems and avoids speculative cryptography dependencies.

12. Canonical Statement (Lock This In)​

LIFE protects privacy through separation, and enables transparency through consent.