Laniakea Phase 1: Pragmatic Delivery

Status: Draft Last Updated: 2026-01-27

Table of Contents

1. Executive Summary
2. Sentinels and Beacons
3. Diamond PAU Deployment
4. Synome-MVP
5. Checker Beacon
6. Relay Beacon
7. Core Halos and Legacy Cleanup
8. Configurator Unit
9. NFAT Smart Contracts
10. NFAT Beacon
11. Report Beacon
12. Collateral Beacon
13. Council Beacon
14. Structuring Halo Legal
15. SOFR Hedging
16. Sequencing and Execution

Executive Summary

Phase 1 is pragmatically focused on delivering a minimal viable infrastructure for automated capital deployment. Phase 1 operates on a monthly settlement cycle; daily settlement is the Phase 2 target.

Seven deliverables in sequence order:

1. Diamond PAU Deployment — Upgrade to Diamond PAU architecture (EIP-2535)
2. Synome-MVP — Operational database for risk parameters and NFAT records
3. MVP Beacons — Six low-power beacons for monitoring, reporting, execution, and governance
4. Core Halos and Legacy Cleanup — Standardize legacy assets as Core Halos, wind down the rest
5. Configurator Unit — Simplest form enabling spell-less operations
6. NFAT Smart Contracts — Facility and Redeemer contracts for Structuring Halos
7. Structuring Halo Legal — Legal infrastructure enabling autonomous NFAT operations

Sentinels and Beacons

To reduce overload of the term "sentinel," Phase 1 introduces a broader taxonomy: beacons.

Beacon Taxonomy

Beacons are autonomous operational components. They vary along two axes:

Sentinels are a subset of beacons — specifically, high-power (AI) beacons that will eventually manage Prime and Halo operations autonomously.

Phase 1: Low-Power Beacons

Phase 1 deploys low-power beacons (programs, not AI) to enable Core Halo and NFAT operations at smaller scale:

These MVP beacons provide the operational foundation. As scale increases, high-power (AI) sentinels will replace or augment them with adaptive decision-making.

Beacon Categories

Read-only (LPLA):

• lpla-checker — observes, calculates, alerts (no write authority)

Reporters (LPHA):

• lpha-report — writes Prime performance summaries to Synome
• lpha-collateral — writes Core Halo / legacy data to Synome (speculative — may not be needed)
• lpha-nfat — writes NFAT records to Synome (also executes)

Executors (LPHA):

• lpha-relay — executes PAU transactions
• lpha-nfat — executes NFAT lifecycle operations

Governance tooling (LPHA):

• lpha-council — Core Council interface for updating Synome

1. Diamond PAU Deployment

Phase 1 deploys the Diamond PAU architecture (EIP-2535 diamond proxy pattern) replacing the legacy PAU pattern. Diamond PAUs provide modular, upgradeable functionality without full contract redeployment.

Diamond PAU Architecture

Benefits Over Legacy PAU

Phase 1 Action Facets

Core Facets:

• NfatDepositFacet — Deposit into NFAT Facility queues
• NfatWithdrawFacet — Withdraw from queues before deal execution
• CoreHaloFacet — Deploy into Core Halo positions

Migration Facets:

• LegacyMigrationFacet — Wind down legacy positions during transition

Migration Path

Each Prime migrates from legacy PAU to Diamond PAU:

1. Deploy Diamond PAU with initial facet set
2. Migrate positions from legacy ALMProxy to new Diamond
3. Grant cBEAMs to GovOps for new Diamond
4. Wind down legacy PAU once migration complete

2. Synome-MVP

Synome-MVP is the operational database that stores risk parameters and NFAT state. It accepts signed statements from authorized parties and serves as the source of truth for the MVP beacons.

How It Works

┌─────────────────────────────────────────────────────────────────┐
│                         INPUTS                                   │
│                                                                  │
│  ┌───────────────────┐         ┌───────────────────┐            │
│  │ Core Council      │         │ Operational       │            │
│  │ GovOps            │         │ GovOps (Halo)     │            │
│  │                   │         │                   │            │
│  │ Signed statements │         │ NFAT deal params  │            │
│  │ for risk params   │         │ for lpha-nfat     │            │
│  └─────────┬─────────┘         └─────────┬─────────┘            │
│            │                             │                       │
│            └──────────────┬──────────────┘                       │
│                           ▼                                      │
│                  ┌─────────────────┐                             │
│                  │   SYNOME-MVP    │                             │
│                  │                 │                             │
│                  │ • Risk params   │                             │
│                  │ • NFAT records  │                             │
│                  │ • Position data │                             │
│                  └────────┬────────┘                             │
│                           │                                      │
└───────────────────────────┼──────────────────────────────────────┘
                            │
                            ▼
┌─────────────────────────────────────────────────────────────────┐
│                        OUTPUTS                                   │
│                                                                  │
│  ┌───────────────────┐         ┌───────────────────┐            │
│  │   lpla-checker    │         │    lpha-nfat      │            │
│  │                   │         │                   │            │
│  │ Reads risk params │         │ Reads NFAT params │            │
│  │ for CRR calcs     │         │ for deal execution│            │
│  └───────────────────┘         └───────────────────┘            │
└─────────────────────────────────────────────────────────────────┘

Data Flows

What Synome-MVP Stores

• Risk parameters — CRR weights, thresholds, limits (signed by Core Council GovOps)
• NFAT records — Parameters for each issued NFAT (amount, APY, maturity, counterparty)
• Position data — Current state of Prime/Halo positions

3. Checker Beacon

The Checker Beacon (lpla-checker) is the Phase 1 monitoring system for position verification and settlement tracking.

Purpose: Monitor positions, calculate CRRs, and track settlement status (read-only reporting)

Inputs: On-chain position data, price feeds, risk parameters from Synome-MVP

Outputs: CRR calculations, settlement status, verification results, alerts

Note: Checker Beacon is LPLA (Low Power, Low Authority) because it only reads and reports — no execution authority.

4. Relay Beacon

The Relay Beacon (lpha-relay) is the execution system that deploys assets via PAU into NFATs and legacy assets (Core Halos).

Purpose: Execute PAU transactions with rate limits and relay role

Inputs: Execution requests from governance/operations, rate limit parameters from Configurator

Outputs: Executed transactions, execution logs

5. Core Halos and Legacy Cleanup

Before deploying Configurator, current Prime exposures must be reduced and simplified. Legacy assets either become Core Halos or are wound down.

Why Cleanup Matters

Each additional exposure creates complexity:

Core Halos

Core Halos are legacy assets that are retained and standardized as Halo Units under Core Council maintenance:

Initial scope: Core Halos cover all assets that aren't Structuring Halos — including Morpho vaults, SparkLend, and other DeFi integrations. These assets can later transition into standard Halos controlled by their respective Primes as the infrastructure matures.

Legacy Asset Decision Tree:

┌─────────────────────────────────────────┐
│         LEGACY PRIME EXPOSURE           │
└──────────────────┬──────────────────────┘
                   │
                   ▼
        ┌─────────────────────┐
        │  Worth retaining?   │
        └──────────┬──────────┘
                   │
         ┌─────────┴─────────┐
         │                   │
         ▼                   ▼
   ┌───────────┐       ┌───────────┐
   │    YES    │       │    NO     │
   └─────┬─────┘       └─────┬─────┘
         │                   │
         ▼                   ▼
   ┌───────────┐       ┌───────────┐
   │ Wrap as   │       │ Wind down │
   │ Core Halo │       │ position  │
   └───────────┘       └───────────┘

Cleanup Targets

• Promote to Core Halo: Valuable legacy assets standardized as Halo Units
• Wind down: Experimental, low-value, or redundant allocations
• Consolidate: Redundant exposures merged into fewer, larger positions
• Document: Each Core Halo's data requirements for MVP beacons

Acceptance Criteria

Primes enter Phase 1 with:

• Core Halos — Legacy assets wrapped as standardized Halo Units
• No orphan exposures — Everything either becomes a Core Halo or is wound down
• Consistent interfaces — All remaining positions accessible via standard PAU actions

6. Configurator Unit

The Configurator enables GovOps teams to manage Prime operations without requiring Sky Spells for routine changes.

How It Works

The Configurator uses a two-tier access model:

┌─────────────────────────────────────────────────────┐
│  aBEAMs (Core Council)                              │
│  • Add inits (pre-approved configs) via timelock    │
│  • Grant cBEAMs to GovOps teams                     │
│  • Remove permissions instantly (emergency)         │
└──────────────────────┬──────────────────────────────┘
                       │
                       ▼
┌─────────────────────────────────────────────────────┐
│  Configurator Unit                                  │
│  (BEAMTimeLock → BEAMState → Configurator)         │
└──────────────────────┬──────────────────────────────┘
                       │
                       ▼
┌─────────────────────────────────────────────────────┐
│  cBEAMs (GovOps Teams)                              │
│  • Set rate limits using approved inits             │
│  • Increase rate limits (max 20% per 18h via SORL) │
│  • Decrease rate limits (always instant)            │
│  • Set relayer/freezer addresses                    │
└──────────────────────┬──────────────────────────────┘
                       │
                       ▼
┌─────────────────────────────────────────────────────┐
│  PAU (Controller + ALMProxy + RateLimits)           │
└─────────────────────────────────────────────────────┘

Key concepts:

Typical flow:

1. Core Council creates inits for a new allocation target (14-day timelock)
2. Core Council grants cBEAM to GovOps for that PAU (14-day timelock)
3. GovOps activates rate limits using the approved inits
4. GovOps increases limits gradually via SORL (20% every 18 hours)
5. GovOps can decrease limits instantly at any time

Safety properties:

• Additions require 14-day timelock (time to detect problems)
• Removals are instant (emergency response)
• Rate limit increases are gradual (SORL bounds damage from compromise)
• Decreases are always allowed (can always reduce exposure)

7. NFAT Smart Contracts

Two contracts enable Structuring Halos:

NFAT Facility

The Facility manages the complete NFAT lifecycle:

NFAT Redeemer

The Redeemer processes NFAT redemptions:

Integration

• Facility and Redeemer connect via shared PAU
• lpha-nfat holds pBEAM for Facility operations
• All state changes logged to Synome

8. NFAT Beacon

The NFAT Beacon (lpha-nfat) manages the NFAT Facility lifecycle — from queue sweeping to RWA offboarding.

Purpose: Operate NFAT Facilities end-to-end

Inputs: Deal parameters from Synome-MVP (set by Operational GovOps), Facility queue state, RWA endpoint status

Outputs: Minted NFATs, deployment transactions, redemption funding, NFAT records to Synome-MVP

9. Report Beacon

The Report Beacon (lpha-report) posts Prime performance summaries to the Synome on a 24-hour cycle.

Purpose: Summarize how each Prime fulfilled its CRRs and encumbrance ratio since the last Synome update

Inputs: Prime position data, CRR calculations from lpla-checker, encumbrance data

Outputs: 24h performance summaries written to Synome-MVP

10. Collateral Beacon (Speculative)

The Collateral Beacon (lpha-collateral) uploads data for Core Halos and legacy RWA positions.

Note: This beacon is speculative and may not be needed depending on how Core Halo data flows are structured.

Purpose: Report Core Halo and legacy RWA data to Synome

Inputs: Core Halo position state, legacy RWA data sources

Outputs: Collateral data written to Synome-MVP

11. Council Beacon

The Council Beacon (lpha-council) is the Core Council toolkit for managing Synome configuration.

Purpose: Enable Core Council to update risk equations and specify report formats

Inputs: Core Council signed updates

Outputs: Updated risk equations and report format specifications in Synome-MVP

Note: lpha-council is governance tooling, not an autonomous beacon. It provides the interface through which Core Council configures the operational Synome.

12. Structuring Halo Legal

The legal infrastructure for Structuring Halos must be established before NFAT Facilities can operate. This framework enables lpha-nfat to execute deals autonomously within governance-approved bounds.

Design Principles (Inspired by Passthrough Halos)

The Buybox Model

Each NFAT Facility defines a buybox — the acceptable parameter ranges for deals:

Deals within the buybox can be executed by lpha-nfat without additional governance approval. Deals outside the buybox require governance intervention.

Legal Isolation

Each NFAT represents a claim on a distinct Halo Unit — legally and operationally isolated:

• If one NFAT's underlying deal fails, other NFATs in the facility are protected
• Each Halo Unit functions as a serialized LLC equivalent
• Recourse is limited to the specific Unit's assets

Governance Artifacts

Deliverables

1. Buybox Template — Reusable legal framework defining acceptable deal parameters
2. Pre-signed Agreements — Standard agreements Primes sign to participate in NFAT Facilities
3. Recourse Mechanisms — Procedures for Fortification Conserver intervention
4. Artifact Templates — Governance documentation for Halo and Unit Artifacts

13. SOFR Hedging

Primes deploying into NFATs with duration must manage interest rate risk. When using the ALDM (Asset-Liability Duration Matching) system for duration matching, Primes have two options:

Why This Matters

Fixed-rate NFATs with duration create interest rate exposure. If SOFR rises, the Prime holds a below-market position. The duration matching system assumes either:

1. The Prime has hedged this risk externally (swaps, futures), receiving variable SOFR exposure that offsets fixed NFAT duration, OR
2. The NFAT itself is priced as SOFR + spread, so yield floats with the benchmark

Validation

lpla-checker validates that Primes deploying into duration NFATs have declared either:

• Hedge positions covering the interest rate exposure
• SOFR plus terms on the underlying NFAT

Primes without valid hedging or floating-rate terms cannot deploy into duration NFATs via the ALDM system.

Sequencing and Execution

Stage 0: Planning

Objective: Establish target timeline for full Phase 1 delivery

• Align all stakeholders on scope and dependencies
• Identify first cohort of Primes participating in initial NFAT deployments
• Confirm Structuring Halo partners and onboarding order

Stage 1: Diamond PAU Deployment

Objective: Deploy Diamond PAU architecture for first-cohort Primes

Stage 2: Operational Infrastructure

Objective: Deploy infrastructure enabling Prime deployment into Core Halos

These components enable Primes to deploy into Core Halos with proper monitoring and execution infrastructure, even before Configurator removes the spell requirement.

Stage 3: Legacy Cleanup and Core Halos

Objective: Complete legacy cleanup and standardize retained assets

Stage 4: Configurator Deployment

Objective: Enable spell-less Prime operations

Stage 5: Halo1 (First Structuring Halo)

Objective: Deploy and validate first Structuring Halo

Stage 6: First Structuring Halo Cohort

Objective: Complete initial Structuring Halo rollout

Deploy remaining first-cohort Structuring Halos:

Each Structuring Halo follows the same pattern:

1. Deploy legal buybox
2. Onboard to Configurator (inits + cBEAMs)
3. Primes deploy immediately — no spell required

Execution Timeline:

STAGE 0       STAGE 1        STAGE 2        STAGE 3        STAGE 4        STAGE 5        STAGE 6
Planning  →   Diamond    →   Operational →  Legacy      →  Configurator → Halo1       →  Full Cohort
              PAU Deploy     Infra          Cleanup        Deployment     (First Halo)   Deployment
                             + Core Halos
    │             │              │              │              │              │              │
    ▼             ▼              ▼              ▼              ▼              ▼              ▼
┌────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐
│Timeline│  │Diamond   │  │Synome-MVP│  │Core Halos│  │Spell-less│  │NFAT      │  │Halo2     │
│agreed  │  │PAUs      │  │Checker   │  │ready     │  │operations│  │contracts │  │Halo3     │
│        │  │deployed  │  │Relay     │  │          │  │enabled   │  │Halo1 live│  │Halo4     │
│        │  │          │  │beacons   │  │          │  │          │  │          │  │Halo5     │
│        │  │          │  │          │  │          │  │          │  │          │  │Halo6     │
└────────┘  └──────────┘  └──────────┘  └──────────┘  └──────────┘  └──────────┘  └──────────┘

End State

At completion of Stage 6:

• All first-cohort Primes operate without spells via Configurator
• Core Halos provide standardized access to legacy assets
• Six Structuring Halos (Halo1-Halo6) accepting NFAT deployments
• Full MVP beacons (lpla-checker, lpha-relay, lpha-nfat) operational
• Synome-MVP tracking all risk parameters and NFAT records