ARCHAI PROTOCOL WHITEPAPER

Programmable ownership for land, housing, and community infrastructure

June 2025

Disclaimer

This document is for research and design discussion. It does not constitute an offer to sell securities, financial advice, or legal advice. Real-world deployments require jurisdiction-specific legal structuring, licensing, and compliance.

---

---

1) The thesis

The built environment is the largest asset class humans maintain. Its ownership systems impose high transaction costs, obscure information, favor rent extraction, and remain politically fragile.

Archai is the protocol that turns land and buildings into programmable institutions with on-chain and off-chain components and access to arbitration, where:

• people can enter through staking or buying,
• earn ownership over time and contribution,
• surplus is allocated by explicit constitutional logic, and
• the whole system stays compliant, auditable, and jurisdiction-portable through Mass primitives and attestation streams.

Archai provides capital and governance infrastructure for many settlements and many civilizational models (Amagi and beyond).

Why now: enabling infrastructure

Archai builds on existing Momentum systems:

• Mass makes entities/ownership/consent programmable and enforceable through compliant APIs (legal infrastructure).
  
• HomeOS makes buildings legible and continuously measurable (operational infrastructure), and that data directly improves valuation and risk models for tokenized assets.
  
• Programmable legal stacks / SEZ modules make jurisdictional portability possible (jurisdictional infrastructure), with Smart Assets carrying compliance and producing attestation streams regulators can verify programmatically.

Together, these systems support the legal rights, operating records, and compliance checks that programmable property institutions require.

---

2) The problem

2.1 Ownership in real estate is structurally exclusionary

For most people, ownership requires a mortgage, a large down payment, creditworthiness, and legal expertise. Selling is slow and expensive, with high transaction costs.

2.2 Housing markets are dominated by rentier dynamics

The default incentives reward:

• holding scarce assets,
• restricting supply,
• harvesting rent,
• and capturing appreciation driven by policy and scarcity.

Abundant, well-maintained housing that serves its community requires different incentives.

2.3 Buildings are opaque, so risk is mispriced

Traditional real estate has persistent information asymmetries. HomeOS lets buildings report occupancy, energy, maintenance, and revenue streams continuously, providing the operational evidence that tokenization requires.

2.4 The coordination problem: land + community + infrastructure

Land ownership also encodes:

• governance,
• cultural norms,
• maintenance commitments,
• collective investment decisions.

Today, these are handled by slow legal processes and weak social trust. Archai’s premise is that they can be expressed as programmable institutional logic.

---

3) Required design principles

Archai is institutional infrastructure and must meet the legal, financial, and governance requirements below.

3.1 Legal reality first

A token requires enforceable rights to represent a secured asset. Archai vault assets are always paired with a real legal wrapper (SPV, trust, foundation, coop) that holds title and signs a protocol-aligned charter. The design must make these enforceable rights explicit from the outset.

3.2 Yield first, not appreciation first

We treat built assets as sources of cash flow (housing, services, utilities, data, commerce). Appreciation is not the core promise.

3.3 Anti-speculation must be engineered

“Non-speculative” is a set of constraints:

• pricing rule,
• transfer constraints,
• premium capture rules,
• exit windows and gates,
• and governance limits.

3.4 Composability at the primitive level

Mass provides primitives for entities, ownership, identity, consent, and related functions. Archai composes them into institutions that own and operate built assets. In Momentum’s architecture, Archai tokenizes HomeOS buildings through native integration with these primitives.

3.5 Continuous attestations, not annual audits

The system needs evidence for compliance checks. Under the SEZ Legal Stack design, Smart Assets should generate cryptographically secured, legally enforceable attestation streams. These let programs verify compliance without exposing private data.

3.6 Progressive decentralization with explicit safeguards

Governance starts with safety: trustees, emergency powers, upgrade controls. It decentralizes only as mechanisms prove stable.

---

4) System model

4.1 Archai is a network of “Vault Institutions”

Each Archai project is a Vault:

• a set of on-chain contracts,
• bound to an off-chain legal wrapper,
• holding a specific portfolio of land/buildings/infrastructure,
• issuing stake positions and ownership claims,
• distributing surplus according to encoded policy.

4.2 Archai separates “use” from “ownership”

Most housing systems bundle:

• right to occupy (use),
• financial exposure (ownership),
• and governance power.

Archai treats them as separable primitives:

1. Use Rights: the ability to live/work in a unit under certain terms.
2. Stake Positions: time-locked capital with defined redemption and yield.
3. Ownership Units: equity-like claims on the underlying entity.
4. Contribution Credits: earned equity via labor/service, verified by attestations.
5. Governance Power: parameterized, scoped, and constrained.

Separating these lets us engineer “non-speculative” systems while still raising capital.

4.3 Archai is a policy engine for many civilizational models

A “civilizational model” combines policy parameters with a governance constitution:

• rent policy,
• surplus split,
• equity issuance schedule,
• contribution valuation rules,
• secondary transfer constraints,
• commons obligations.

Archai hosts multiple models. Each vault selects one and can migrate through governance.

---

5) Protocol architecture

5.1 Layer 1: Legal wrapper (Mass-native entity)

Each Vault corresponds to a legal entity (or entity set):

• Asset SPV / Trust holds title and bank accounts.
• Operator entity contracts services (maintenance, property management, construction).
• Archai Foundation / protocol entity holds IP, administers upgrades, manages network treasury.

Mass provides software to form and maintain these entities automatically. It encodes their governance, ownership tables, identity checks, and consent workflows.

The legal wrapper operates as a programmable Smart Asset.

5.2 Layer 2: Vault contracts (capital + rights engine)

Vault contracts manage:

• deposits,
• stake terms,
• redemptions,
• distribution,
• issuance of ownership units,
• rent discount rules,
• secondary transfer rules,
• reserve accounts,
• liquidation/wind-down logic.

5.3 Layer 3: Governance module (polycentric)

Vault governance excludes a simple “one token, one vote” model. It is:

• scoped,
• role-based,
• bicameral where necessary,
• with trustee/guardian failsafes.

5.4 Layer 4: Commons + network treasury

A portion of surplus flows to the Archai Commons Treasury. The initial proposal allocates 5–10%.

This treasury funds:

• seeding new vaults,
• resident subsidies,
• protocol R&D,
• and risk underwriting (insurance).

5.5 Layer 5: Evidence layer (HomeOS + attestation streams)

Buildings running HomeOS produce continuous operational data:

• occupancy,
• energy,
• maintenance costs,
• revenue streams.

This reduces information asymmetry and feeds valuation and risk models for tokenized assets.

The SEZ Legal Stack design uses attestation streams to prove required checks (KYC tier, AML screening, transfer restrictions) without revealing underlying private data.

5.6 Layer 6: Arbitration and dispute resolution

Every vault must have:

• a defined dispute path,
• arbitration clause,
• on-chain evidence admissibility rules,
• and emergency intervention rights.

Momentum’s ecosystem includes an ADGM-based arbitration court for digital asset and machine-intelligence workflows. Archai vaults should route disputes into such specialized venues by default.

Momentum Monograph - Google Docs

---

6) Vault economics: stake-to-live, stake-to-own, and earned equity

The contracts must specify what participants receive for locking capital and how the vault produces returns without speculation.

6.1 Vault balance sheet and capital structure

Each vault combines private equity and real estate finance through the following capital structure:

• Senior capital (bank debt / bonds)
  Lowest risk, capped return, first claim.
• Resident stake (time-locked deposits)
  Medium risk, compensated via rent discounts + earned equity.
• Programmatic equity (vault ownership units)
  Variable return, receives residual surplus and some appreciation per policy.
• Sponsor/operator equity
  Paid for execution, absorbs early risk, earns if the asset performs.
• Commons stake (network)
  Receives protocol fee and may provide insurance backstops.

Solvency and redemptions depend on an explicit model of this capital structure.

6.2 Two primary stake products

A) Resident Stake (stake-to-live)

Residents stake capital for a term. The initial proposal suggested 3–7 years.

They receive:

• a rent discount (economic benefit now),
• earned equity over time (wealth building),
• governance participation (scoped),
• and the right to redeem principal at maturity (subject to safety gates).

Resident Stake is a capitalized membership in a housing institution.

B) Capital Stake (stake-to-build / stake-to-yield)

Non-resident capital providers stake into the vault with:

• defined term,
• defined distribution rules (coupon-like),
• potentially equity kicker,
• no occupancy rights.

Capital Stake finances additional housing supply while constraining speculation.

6.3 Earned equity

Earned equity rewards time, risk, and contribution instead of mere wealth.

The initial formula makes equity proportional to stake * multiplier / valuation. The model below adds explicit terms for time, risk, and contribution:

Let:

• 𝑁𝐴𝑉𝑡NAVt​ = net asset value of the vault at time t (audited + attested)
• 𝑆𝑖Si​ = stake amount for position i
• 𝑇𝑖Ti​ = term length for position i
• 𝑅𝑖Ri​ = risk multiplier (construction > stabilization > mature)
• 𝐶𝑖(𝑡)Ci​(t) = contribution score (verified labor/service)
• 𝛼,𝛽α,β = policy parameters

Define Equity Accrual Rate:

𝐸𝐴𝑖(𝑡)=𝑆𝑖𝑁𝐴𝑉𝑡⋅𝑓(𝑇𝑖)⋅𝑅𝑖  +  𝛼⋅𝐶𝑖(𝑡)EAi​(t)=NAVt​Si​​⋅f(Ti​)⋅Ri​+α⋅Ci​(t)

Where:

• 𝑓(𝑇)f(T) is convex in time (long-term alignment rewarded),
• 𝑅𝑖Ri​ is bounded (no infinite multipliers),
• 𝐶𝑖(𝑡)Ci​(t) is capped per epoch to prevent gaming.

Equity accrues continuously or in epochs, minted as Vault Ownership Units.

6.4 Rent: discount as “coupon”

We formalize:

• Let Base Rent be computed from:

• operating costs,
• reserves,
• debt service,
• targeted maintenance SLA,
• and affordability policy.

• A Resident Stake provides a discount that functions like the “interest payment” on their locked capital.

The vault borrows from residents and compensates them through reduced rent and earned equity.

6.5 Surplus allocation

Define:

𝑆𝑢𝑟𝑝𝑙𝑢𝑠=𝑁𝑂𝐼−𝐷𝑒𝑏𝑡𝑆𝑒𝑟𝑣𝑖𝑐𝑒−𝑅𝑒𝑠𝑒𝑟𝑣𝑒𝑠Surplus=NOI−DebtService−Reserves

Then allocate surplus by policy:

• Resident / staker distributions: 50–70% (initial proposal)
• Reinvestment: 20–40% (initial proposal)
• Protocol fee to Commons: 5–10% (initial proposal)

The allocation also includes:

• Insurance / contingency buffer (can be part of reserves or funded via protocol treasury)

Surplus allocation defines the vault’s economic constitution.

---

7) Liquidity and exit without rentier speculation

Participants also need defined ways to exit. Most tokenized real estate fails to provide liquidity while constraining rentier speculation.

7.1 Three exit paths (each with constraints)

1. Redemption at maturity (primary)

• Stake positions redeem at maturity at a deterministic rule:

• principal less fees,
• subject to solvency and redemption queues.

2. Secondary transfer of stake rights (bounded)
   
   We formalize:

• transfers only to whitelisted (KYC/KYB) recipients,
• premium cap relative to NAV,
• any premium above cap is routed to Commons (anti-speculation capture),
• mandatory disclosure of vault state.

3. Cross-vault portability (network feature)
   As Archai evolves into a registry, positions can be portable:

• stake exits one vault and enters another under rules,
• enabling mobility without liquidation cascades.

7.2 Redemption gates: preventing bank runs

Real assets are illiquid, so Archai cannot promise instant liquidity. It uses explicit redemption gates:

• max redemption per epoch,
• variable queue times tied to liquidity,
• emergency halts when reserves breach threshold.

These gates protect solvency.

7.3 “Non-speculative” as a pricing rule

A vault can choose among policy modes:

• NAV-bounded mode: ownership units trade within a tight band around NAV. Excess premium is taxed away.
• Affordability-first mode: occupancy rights are non-transferable or transferable only at cost.
• Growth mode (allowed but explicit): partial appreciation can accrue, but with caps and commons capture.

Speculation requires a deliberate policy choice and is disabled by default.

---

8) Governance and control surfaces

The initial proposal describes governance as “stake-based, resident-weighted, trustee-checked.” The roles below assign control over local rules, capital, and compliance, subject to constitutional limits.

8.1 Governance must be polycentric

Different decisions require different stakeholders.

Recommended structure:

Resident Council

Controls:

• community rules,
• local service priorities,
• cultural programming,
• some budget allocations.

Voting weight: occupancy + contribution (not raw capital).

Capital Council

Controls:

• leverage limits,
• reserve policy,
• large capex,
• refinancing terms,
• issuance policy.

Voting weight: stake and ownership units (bounded).

Trustee/Guardian

Controls:

• legal compliance,
• emergency actions,
• fraud response,
• enforcing constitutional constraints.

Trustees connect vault governance to its legal obligations.

8.2 Constitutional constraints (hard-coded)

Certain parameters must be upgrade-resistant:

• maximum leverage,
• minimum reserves,
• affordability floors,
• anti-speculation constraints,
• disclosure requirements.

Governance cannot authorize treasury theft or leverage beyond the constitutional limit.

8.3 Evidence-based governance

Governance proposals must reference:

• attested operating metrics (HomeOS),
• audited financials,
• risk reports,
• and predicted impacts.

These records connect governance decisions to the building’s operations, finances, and risks.

---

9) Legal + compliance: Mass-native smart assets

9.1 Required Mass integration

Mass provides programmable primitives:

• entities,
• ownership structures,
• financial instruments,
• identity,
• consent.
  Momentum Monograph - Google Docs

Archai vaults should be implemented as a specific composition of those primitives:

• the SPV/trust is a Mass entity,
• stake positions and ownership units are Mass-native ownership tables/tokens,
• transfers are governed by identity gates and consent workflows,
• distributions use Mass fiscal rails (accounts/wallets/banking integration).

9.2 Smart Assets carry legal modules

Under the SEZ Stack design, a Smart Asset should encode its jurisdiction, transfer restrictions, identity tier requirements, and consent mechanisms. Compliance checks become part of the asset’s operation.

For Archai:

• Each vault declares its jurisdictional module.
• Transfers compute the intersection of permissible actions (e.g., KYC tiers, residency rules, securities exemptions).
• The asset enforces constraints programmatically.

9.3 Attestation streams are the regulator interface

Regulators and auditors need verifiable compliance.
Attestation streams prove requirements were met without exposing private data (e.g., “all holders meet KYC tier X”).

Archai uses attestation streams for:

• holder eligibility,
• transfer compliance,
• treasury flows,
• operating metrics integrity.

9.4 Legal wrappers are modular (jurisdiction SDK)

The initial proposal names templates such as a Cayman foundation, Swiss Verein, and Panama company. Jurisdiction modules organize these legal choices:

• Create a Jurisdiction SDK: a set of deployable legal + compliance modules (entity type, offering exemptions, custody model, dispute resolution path).
• Vaults instantiate within a chosen module.
• Modules can be upgraded or migrated with governance and trustee oversight.

---

10) Security, risk, and solvency

10.1 Threat model

The design must address the following risks:

• title defects / legal disputes,
• operator fraud,
• valuation manipulation,
• oracle corruption (data + appraisals),
• governance capture,
• liquidity cascade (redemption run),
• jurisdictional intervention,
• stablecoin/banking rail failure,
• smart contract bugs.

10.2 Minimum institutional controls

• Segregated accounts (operating vs reserves vs distributions)
• Independent appraisal + HomeOS attested ops data feeding NAV
• Redemption gates + queues
• Role-based access control for operational actions
• On-chain + off-chain audit trails
• Emergency guardian powers with transparency constraints
• Insurance module (protocol-level underwriting)

10.3 Network insurance and underwriting

The initial proposal assigns insurance and the protocol token a role in network underwriting:

• The Commons Treasury can act as a first-loss backstop for defined event categories.
• $ARCH can be staked into underwriting pools (risk-weighted).
• Vaults pay risk-based premiums (paid from surplus).

More vaults improve risk modeling, which lowers the cost of capital.

---

11) Token model: $ARCH and vault assets

The initial proposal: “The protocol token ($ARCH) governs the Archai network… stake-weighted voting… access to preferred vaults… claim on commons surplus… underwriting.”

Vault assets carry rights in individual projects. The network token serves protocol governance and underwriting, with distinct legal conditions:

11.1 Two token categories

1. Vault Assets (per-vault)

• Stake position tokens (time-locked notes / deposit receipts)
• Ownership units (equity-like claims)
• Use rights (occupancy/access claims)

These map to specific legal wrappers and are highly jurisdiction-dependent.

2. $ARCH (network token)

• Governance of protocol-level parameters and upgrades
• Underwriting / insurance staking
• Access coordination (optional, not core)
• Fee capture from Commons Treasury (if legally viable)

11.2 Distribution principles

• Incentivize early vault bootstrapping and limit the duration of subsidies.
• Reward verified contribution (builders, maintainers, operators) more than passive speculation.
• Fund long-term commons (treasury).
• Avoid short-term emission schedules that create mercenary behavior.

11.3 Regulatory posture

Vault assets are likely regulated financial instruments in many jurisdictions. Mass-native compliance must constrain distributions and transfers accordingly.

$ARCH may be regulated if it carries explicit cash-flow claims. Governance and underwriting collateral with carefully scoped economics may offer a clearer regulatory position. The treatment depends on jurisdiction, so Archai must support distinct legal modules.

---

12) Roadmap

The roadmap starts with one vault, then adds portability, shared underwriting, jurisdiction modules, and resident and operator tools:

Phase 1: MVP (single vault)

• One legal wrapper
• One vault contract system (stake, redemption, distribution)
• One governance constitution
• One evidence feed (basic HomeOS metrics)
• Basic KYC gating through Mass

Phase 2: Multi-vault registry + portability

• Registry contracts
• Standard interfaces for vault types
• Cross-vault portability primitives
• Redemption queue standardization

Phase 3: Commons layer + underwriting

• Protocol treasury routing
• Grants program for new vault origination
• Insurance pools + risk scoring

Phase 4: Jurisdiction SDK (legal modules)

• Deployable templates per jurisdiction
• Integration hooks to SEZ stack modules
• Attestation stream standards for compliance

Phase 5: Resident and operator interface

• Mobile dashboard
• Resident onboarding flows
• Contribution verification tooling
• Proposal and voting UX

---

13) Appendix A: The Archai stack in one diagram

Value + control flow (simplified)

Residents / Investors
→ stake capital into Vault Contract
→ Vault Contract coordinates with Mass Entity (SPV/Trust)
→ Entity holds title + bank accounts, pays operators
→ Building ops run on HomeOS, producing attested metrics
→ Vault calculates surplus, updates NAV, distributes per policy
→ Protocol fee to Commons Treasury
→ Commons funds seeding + subsidies + insurance

---

14) Appendix B: Glossary

• Vault: on-chain capital + rights engine paired to a real legal entity holding the asset.
• Stake position: time-locked capital with defined redemption/yield.
• Ownership unit: equity-like claim on the underlying entity.
• Use right: occupancy/access claim (may be non-transferable or bounded-transfer).
• Attestation stream: cryptographic proof stream of compliance/operations.
• Commons: shared treasury and seeding/underwriting engine.