Synome

The Synome is Sky Protocol's planned machine-readable operational database designed to complement the human-readable Sky Atlas constitutional document ^[1]. As part of the Laniakea infrastructure roadmap, the Synome represents a fundamental architectural innovation that separates human-interpretable governance principles from machine-executable operational data ^[2]. This separation addresses a core tension in decentralized governance: the need for comprehensive documentation that is simultaneously readable by humans for democratic legitimacy and parseable by machines for autonomous execution ^[3].

The current Sky Atlas spans approximately 364,000 words across seven scope documents, attempting to serve both audiences ^[4]. Agent Artifacts alone comprise 26,838 lines of Instance Configuration Documents, rate limits, and operational parameters—content that is inherently machine-oriented but currently embedded in human-readable documentation ^[5]. The Atlas/Synome separation formalizes this distinction, condensing the Atlas to a constitutional core of approximately 10-20 pages while migrating all operational data to the graph-structured Synome database ^[6].

This article examines the Synome's architecture, its relationship to the Atlas and Sentinel Network, the types of data it contains, and its role in enabling autonomous Synomic Agents. The Synome represents not merely a database but a paradigm shift in how decentralized protocols balance automation with human governance ^[7].

Background and Motivation

The Atlas/Synome separation emerges from a fundamental contradiction in Sky Protocol's original governance vision. The Endgame Plan, ratified by MakerDAO in 2022 and progressively implemented through 2024-2025, envisioned the Atlas as the complete, immutable knowledge base of all Sky data, algorithms, and intelligence ^[8]. The final Endgame State would permanently lock this comprehensive documentation, ensuring the protocol's core processes and balance of power remain decentralized, self-sustainable, and immutable forever ^[9].

This vision contains an inherent tension between three competing requirements. First, comprehensive documentation must cover every operational detail, algorithm, configuration, and edge case to enable fully autonomous operation ^[10]. Second, machine-readable structure is required for autonomous systems—called Sentinels in the Laniakea architecture—to consume and act on this data without human intervention ^[11]. Third, human readability is required for democratic legitimacy, as stakeholders must understand what they are governing to participate meaningfully in decentralized governance ^[12].

These requirements fundamentally conflict. Dense, legalistic language mixing human explanations with machine-precise specifications serves neither audience well. The current Atlas results in documentation that is neither fully readable by humans nor fully parseable by machines ^[13]. Technical parameters like SubProxy addresses, rate limit configurations, and BEAM control boundaries sit alongside philosophical principles and governance procedures, creating cognitive overhead for human readers while requiring complex parsing for automated systems ^[14].

The Evolution of Governance Documentation

Sky Protocol's governance documentation has evolved through several phases since MakerDAO's founding in 2014 ^[15]. Early governance relied on informal social coordination through Reddit and community forums, with no formal constitutional document ^[16]. The introduction of Maker Improvement Proposals (MIPs) in April 2020 established a more structured framework, though still without comprehensive operational specification ^[17].

The Endgame Plan introduced the Atlas Immutable Alignment Artifact in March 2023, representing the first attempt at constitutional governance for a DeFi protocol ^[18]. This document grew substantially through 2024 as it absorbed operational details previously scattered across MIPs, forum posts, and informal agreements ^[19]. The September 2024 rebrand to Sky Protocol brought further expansion, with Agent Artifacts for each Sky Star (Spark, Grove, Keel, Obex) adding thousands of lines of configuration data ^[20].

By late 2025, the Atlas had grown unwieldy. Aligned Delegates and governance participants reported difficulty navigating the document, while Sentinel implementations faced challenges parsing operational parameters from narrative text ^[21]. The Atlas/Synome separation emerged as the solution: preserve the Atlas as a constitutional document that any stakeholder can read and understand, while migrating machine-oriented data to a purpose-built database ^[22].

The Broader Context of Machine-Readable Governance

The Synome concept aligns with broader developments in blockchain governance and autonomous agent systems. Research into decentralized AI agents (DeAgents) has demonstrated the viability of Large Language Model-based agents operating on trustless, tamper-resistant computational substrates including blockchain smart contracts ^[23]. These self-sovereign agents hold their own cryptographic private keys and make autonomous decisions without human intervention, managing cryptocurrency wallets, transferring digital assets, and interacting with DeFi protocols ^[24].

The challenge such systems face is the "code is law" limitation: traditional smart contracts execute automatically based on predefined logic, leaving no room for interpretation or change when errors or unforeseen events occur ^[25]. Smart contracts lack the flexibility to interpret intent, account for jurisdictional nuances, or respond to real-world events that weren't anticipated during coding ^[26]. The Synome addresses this by providing both machine-readable operational constraints and a structured escalation path to human governance for edge cases ^[27].

Technical Architecture

The Synome architecture positions the Atlas as a root node embedded within a larger graph database, rather than as a separate document ^[28]. This design enables the Synome to grow arbitrarily complex while maintaining a human-interpretable entry point through the constitutional Atlas ^[29].

Graph Database Structure

The Synome operates as a graph database containing all operational data, structured for machine consumption ^[30]. Unlike traditional relational databases, the graph structure allows flexible relationships between different types of nodes, enabling complex queries about operational state and historical precedents ^[31].

The architecture includes several node categories:

Node Type	Content	Source
Agent Nodes	Complete specifications for Spark, Grove, Keel, Launch, Obex	A.6.1-A.6.5
Instance Nodes	Contract addresses, rate limits, per-deployment parameters	Instance Configuration Documents
State Nodes	Modifiable operational data, queue states, capacity levels	Active Data Documents
Config Nodes	BEAM parameters (min/max/step/tau), penalty schedules	A.3, A.4 tables
Algorithm Nodes	P&L formulas, waterfall logic, penalty calculations	A.2, A.3 procedures
Budget Nodes	Rates, allocations, disbursement rules	Budget Documents
Precedent Nodes	Historical decisions, interpretations, pattern recognition data	Governance history
Transaction Logs	All Sentinel actions, settlements, state changes	Runtime operation

This structure enables Sentinels to query specific operational parameters without parsing narrative documentation ^[32]. For example, a Sentinel verifying encumbrance ratios can directly query Config Nodes for threshold values rather than extracting them from prose text ^[33].

The Atlas as Root Node

Within the Synome, the Atlas exists as a single root node containing the constitutional principles that govern all other nodes ^[34]. This embedding—rather than separation—ensures that the human-readable governance principles remain the ultimate authority for the machine-readable operational data ^[35].

The Atlas root node contains:

A.0 Spirit of the Atlas — Universal Alignment principles
A.1 Governance — Decision processes, who decides what
A.2 Primitives — Sky Primitive definitions and lifecycle rules
A.3 Risk Framework — JRC/SRC seniority, encumbrance ratio principles
A.4 Protocol — Token architecture, rewards, BEAM pattern definitions
A.5 Accessibility — Compliance philosophy, geographic access controls
A.6 Introduction — Agent type definitions and transformation rules

This constitutional core targets approximately 10-20 pages in plain language—short enough for any stakeholder to read and understand without technical expertise ^[36]. It describes what must be true without specifying how it is implemented, leaving implementation details to the operational nodes ^[37].

Data Migration Mapping

The Synome migration involves systematic extraction of machine-oriented data from the current Atlas structure ^[38]. The following table illustrates the mapping:

Current Atlas Location	Synome Destination	Rationale
Immutable Documents (Scopes, Articles)	Atlas Root Node	Constitutional principles
Primary Documents	Atlas Root Node	Core rules operationalizing the Spirit
Supporting Documents	Bridge Layer	Some explanatory (Atlas), some data (Synome)
Active Data Documents	State Nodes	Modifiable state is machine territory
Budget Documents	Budget Nodes	Rates and allocations are machine territory
Instance Configuration Documents	Instance Nodes	Per-deployment parameters
Precedents	Precedent Nodes	Historical decisions for pattern recognition
Accessory Documents	Atlas Root Node	Translations, archives (for humans)

Current examples of data moving to Synome include Prime SubProxy addresses (Spark: 0x3300f198988e4C9C63F75dF86De36421f06af8c4, Grove: 0x1369f7b2b38c76B6478c0f0E66D94923421891Ba, Keel: 0x355CD90Ecb1b409Fdf8b64c4473C3B858dA2c310, Obex: 0x8be042581f581E3620e29F213EA8b94afA1C8071), Core Operator Relayer Multisig configurations (0x8Cc0Cb0cfB6B7e548cfd395B833c05C346534795, 2/5 signing requirement), and SLL Rate Limit Types per chain (LIMIT_USDS_MINT, LIMIT_USDS_BURN, LIMIT_USDS_TO_USDC, LIMIT_USDC_TO_CCTP, LIMIT_USDC_TO_DOMAIN) ^[39].

Transaction Log Architecture

All Sentinel actions create Synome transaction log entries, enabling comprehensive audit trails for autonomous operations ^[40]. Each transaction follows a structured format:

Transaction {
  id: bytes32
  timestamp: uint256
  sentinel: address
  action_type: enum
  target_node: bytes32
  parameters: bytes
  result: enum
  verification_hash: bytes32
}

This architecture enables audit trails for all autonomous actions, pattern recognition for anomaly detection, precedent lookup for similar situations, and continuous improvement via post-hoc analysis ^[41]. The append-only nature of the transaction log ensures immutability while allowing the operational state to evolve through valid transactions ^[42].

Synomic Agents

The Synome structure enables a crucial property that distinguishes Sky's approach from traditional smart contracts: Synomic Agents can operate with full autonomy within governance-defined bounds while maintaining a path to human judgment for edge cases ^[43]. This represents a middle ground between the rigidity of "code is law" and the inefficiency of human approval for every operation ^[44].

Definition and Properties

A Synomic Agent (Prime, Halo, or Executor) exists entirely within the Synome ^[45]. This bounded existence creates structural accountability that eliminates the possibility of rule-breaking through lobbying, bribery, or override:

Property	Implication
Identity is Synome-native	SubProxy address and token cannot exist outside the system
Assets are Synome-controlled	TRC, credit lines governed by Synome rules
Actions are Synome-bounded	Rate limits, encumbrance ratios enforced by code
Accountability is structural	Penalties accrue automatically, conservatorship triggers automatically

Because the agent cannot escape its constraints, it can operate without human oversight for individual decisions ^[46]. No one can lobby, bribe, or override the rules—they hold unconditionally within the Synome's boundaries ^[47].

Agent Types

The Laniakea architecture defines three categories of Synomic Agents ^[48]:

Primes are specialized, heavyweight Synomic Agents that require transformation primitives, foundations, and nested contributors. Currently five Primes exist: Spark (DeFi lending, SparkLend, Spark Savings, Spark Liquidity Layer across six chains), Grove (institutional credit, CLOs, RWA allocations), Keel (Solana ecosystem, USDS adoption), Launch 3 (distribution rewards, integration boosts), and Obex (agent incubator for Prime and Halo development) ^[49].

Halos are general-purpose Synomic Agents that can wrap any value and give it agency ^[50]. A tokenized building becomes an entity that can manage itself; a portfolio becomes an autonomous allocator. Halos are the fractal layer—they proliferate as the ecosystem grows, with each Halo operating under governance constraints inherited from its parent Prime or the Generator layer ^[51].

Executors perform privileged operations with collateral backing ^[52]. They post escrow and face slashing for failures, creating economic alignment between execution quality and agent incentives ^[53].

Autonomy and Protection

The autonomy enabled by Synomic Agents serves two primary purposes ^[54].

First, it protects humans from each other. Without autonomous Synomic Agents, rules hold only until someone powerful enough lobbies to break them. With autonomous agents, encumbrance penalties apply regardless of who wants an exception, settlement happens regardless of who benefits or loses, and rate limits hold regardless of market pressure ^[55]. The agent protects participants not because it is benevolent but because it literally cannot deviate from its constraints ^[56].

Second, it enables cooperation without trust. Multiple parties—opaque to each other, potentially competing—can coordinate through Synomic Agents ^[57]:

Party A ──┐
          ├───► Synomic Agent ◄───► Synome constraints
Party B ──┘     (neutral arbiter)

Party A cannot read Party B's strategy, Party B cannot read Party A's strategy, yet both can verify the Synomic Agent follows rules, and both can trust outcomes without trusting each other ^[58]. This structure enables sealed-bid auctions, multi-party settlement, and cross-jurisdictional capital flows that would be impossible with human intermediaries or pure code-is-law smart contracts ^[59].

Escalation to Human Reasonableness

The Synome provides what traditional smart contracts lack: a structured path to human judgment for edge cases ^[60]. Regular smart contracts are "code is law"—no appeal, no reasonableness check. If the code produces an absurd outcome, participants have no recourse ^[61]. Synomic Agents differ fundamentally:

99% of cases	1% edge cases
Automated	Escalates to governance
Cheap (gas only)	Expensive (time, attention, voting)
Code resolves	Humans resolve
No human involvement	Sky ensures reasonable outcome

When a dispute arises that code cannot resolve cleanly, the agent flags the dispute, escalates through governance layers, and if necessary reaches Sky Core governance where humans apply reasonableness—determining what a sensible person would conclude ^[62]. The resolution then flows back down through the system ^[63].

The escalation is expensive by design, creating incentive to write better code that handles more cases automatically, resolve disputes at the lowest possible level, and only escalate genuinely hard cases ^[64]. But the path exists, ensuring any edge case can ultimately reach human judgment ^[65].

This creates a trust equation that differs from traditional smart contracts ^[66]:

Traditional smart contracts: Trust = Code (no recourse)
Synomic systems: Trust = Code × Synome Constraints × Human Escalation Path

The Synomic approach combines automation efficiency with human reasonableness, handling 99% of operations cheaply while guaranteeing the 1% gets a sensible outcome ^[67].

Mini-Atlases: The Fractal Pattern

Every level of the Synome with human stakeholders receives a human-readable summary document called a Mini-Atlas ^[68]. This fractal pattern ensures that while the Synome can grow arbitrarily complex, the human layer remains manageable ^[69].

Prime Mini-Atlases

Each Prime Agent creates their own Mini-Atlas to explain their Agent Artifact in accessible language ^[70]. The audience includes Prime token holders and users of Prime services who need to understand the Prime's operations without parsing technical specifications ^[71].

Contents of a Prime Mini-Atlas derive from the Agent Artifact and include what the Prime does (strategic overview), key parameters explained in plain language, risk disclosures without full formula complexity, governance processes (Root Edit Primitive configuration), and how to participate (staking, using services) ^[72].

Root Edit governance follows a standard structure across Primes: 1% token holders can propose changes (Nested Contributors exempt), a 7-day Operational Facilitator alignment review occurs, followed by a 3-day Snapshot poll with 10% quorum and >50% approval threshold ^[73]. The "Publicly Held" gate prevents Root Edit from becoming operational until 2,000+ holders own 10%+ of genesis supply, ensuring sufficient decentralization before governance changes ^[74].

Prime	Focus	SubProxy
Spark	DeFi: SLL (6 chains), SparkLend, Spark Savings	`0x3300...af8c4`
Grove	Institutional: CLOs, RWA allocations	`0x1369...891Ba`
Keel	Solana ecosystem, USDS adoption	`0x355C...2c310`
Launch 3	Distribution rewards, integration boosts	TBD
Obex	Agent incubator	`0x8be0...c8071`

Halo Mini-Atlases

For Halos with external participants—such as Passthrough Halos with institutional investors—Mini-Atlases serve a compliance and communication function ^[75]. The audience includes institutional investors and regulatory bodies who require documentation in formats suitable for due diligence and regulatory review ^[76].

Contents include investment strategy and expected returns, risk factors in compliance-suitable language, legal structure and regulatory status, and reporting cadence and metrics ^[77]. This documentation bridges the gap between on-chain operational data in the Synome and traditional institutional requirements ^[78].

The Documentation Hierarchy

The fractal pattern creates a hierarchy where every node with human stakeholders gets a human summary ^[79]:

Sky Atlas           → Describes Sky Core (A.0-A.5 + A.6 intro)
  ├─ Spark Mini-Atlas    → Describes Spark Agent Artifact node
  │    ├─ SLL docs       → Describes SLL Instance nodes
  │    ├─ SparkLend docs → Describes SparkLend Instance nodes
  │    └─ Halo A docs    → Describes Halo A node
  ├─ Grove Mini-Atlas    → Describes Grove Agent Artifact node
  │    └─ Halo B docs    → Describes Halo B node
  └─ ...

This structure enables the system to scale to thousands of Halos and hundreds of Primes while keeping documentation navigable ^[80]. Each stakeholder only needs to read the Mini-Atlas relevant to their participation level ^[81].

Sentinel Integration

Sentinels—the autonomous systems that operate Sky Protocol's infrastructure—interact with the Synome as their primary data source ^[82]. Rather than parsing Atlas text or querying scattered smart contract states, Sentinels consume structured Synome data and write operation results back to the database ^[83].

Sentinel Data Consumption

Different Sentinel types consume different categories of Synome data ^[84]:

Sentinel	Synome Data Consumed	Synome Data Written
stl-base	Prime pBEAM permissions, rate limits	Bid submissions, capacity requests
stl-erc	LCTS config, queue state	Settlement transactions, exchange rates
stl-unit	Halo parameters, risk thresholds	Status updates, breach alerts
stl-auction	Bid submissions, capacity pools	Clearing prices, allocations
stl-prime	Prime Artifact config	Encumbrance calculations, penalty assessments
stl-verify	All above (read-only)	Verification attestations

This read-write pattern creates a feedback loop where operational outcomes inform future operations ^[85]. Precedent Nodes accumulate historical decisions that can guide interpretation of ambiguous situations ^[86].

BEAM Hierarchy in Synome

The Bounded External Access Module (BEAM) system maps directly to Synome node structures ^[87]:

pBEAM Node (Prime-level)
├── Controlled Parameters[]
│   ├── OSRC_capacity: {min, max, step, tau, current_value}
│   ├── Interest_rate: {min, max, step, tau, current_value}
│   └── ...
├── Authorized Operators[]
│   ├── stl-base (automated)
│   └── Prime Multisig (manual)
└── Last Update Timestamps{}

cBEAM Node (Core-level guardrails)
├── Global Limits{}
│   ├── max_total_allocation
│   ├── max_single_prime_exposure
│   └── ...
└── Override Permissions
    └── Core Council multisig

aBEAM Node (Emergency controls)
├── Freeze Permissions[]
├── Recovery Procedures[]
└── Emergency Contact Info[]

This structure enables hierarchical permission checking without complex contract interactions ^[88]. A Sentinel can verify its authorized bounds by querying a single node rather than traversing multiple contracts ^[89].

CC Synome: The Authoritative Source

The Core Council Synome (CC Synome) serves as the authoritative source of truth for the entire network ^[90]. All other stl-synome nodes sync from the CC Synome, ensuring consistency across the distributed system ^[91].

Write flows follow a hierarchical pattern ^[92]:

Writer	Writes to	Propagates to
Core Council decisions	CC Synome	All stl-synome nodes
GovOps operational data	CC Synome directly	All stl-synome nodes
stl-prime/stl-halo/stl-unit	Via their GovOps	CC Synome → all nodes
stl-exec (with CC seat)	CC Synome with override permissions	All nodes

This architecture ensures that privileged writes occur through auditable channels while allowing operational updates to propagate efficiently ^[93].

Verification Model

The Atlas/Synome split enables a clear verification model that separates human and machine responsibilities ^[94].

Human Verification (Atlas)

Humans verify that the Atlas reflects their values and intentions, contains sensible non-contradictory principles, adequately protects their interests, and is understandable without technical expertise ^[95].

This verification occurs through Governance Polls and Executive Votes as defined in A.1, Aligned Delegate review of proposed changes, and public debate on the Sky Forum ^[96]. The focus is on principles and outcomes rather than implementation details ^[97].

Machine Verification (Synome → Atlas)

Machines verify that the Synome conforms to Atlas constraints, maintains internal consistency, produces valid state transitions, and satisfies formal invariants ^[98].

This verification occurs through Sentinel constraint checking before actions, Monthly and Weekly Settlement Cycle validation as defined in A.2 and A.3, and Independent Calculation versus Initial Calculation comparison ^[99]. The settlement comparison follows specific rules: ≤1% deviation produces an Agreed Amount that is auto-approved, while >1% deviation produces a Disputed Amount requiring Core GovOps resolution ^[100]. Primes can post a Dispute Notice within 5 days of calculation posting ^[101].

The Verification Bridge

Atlas statements map to Synome constraints through formal verification rules ^[102]:

Atlas Statement	Synome Constraint
"Encumbrance ratio target ≤90%"	`∀ prime: prime.RRC / prime.TRC ≤ 0.90`
"JRC absorbs losses before SRC"	`loss_order = [tip_jrc, remaining_jrc, src, backstop]`
"Rate changes limited by BEAM tau"	`∀ param: time_since_last_change(param) ≥ param.tau`
"srUSDS queues process at Monthly Settlement"	`∀ queue: process_on(queue) = MSC_date`
"Penalty escalates with duration"	`penalty_rate = f(shortfall_duration)` per schedule

The Atlas describes intent while the Synome encodes implementation, with verification ensuring the implementation satisfies the intent ^[103].

Migration Path

The transition from the current Atlas to the Atlas/Synome split follows a phased approach designed to minimize disruption while building the necessary infrastructure ^[104].

Phase 1: Extraction

The first phase extracts machine data from the current Atlas into structured format ^[105]. This involves parsing A.6 Agent Artifacts into Agent nodes, Instance Configuration Documents into Instance nodes, BEAM tables from A.4 into Config nodes, penalty schedules from A.3 into Algorithm nodes, and Active Data references into State node templates ^[106].

Phase 2: Distillation

The second phase condenses the Atlas to its constitutional core ^[107]. This involves keeping principles while removing parameters, keeping definitions while removing instances, keeping rules while removing implementation details, targeting a final document of approximately 10-20 pages ^[108].

Phase 3: Verification Mapping

The third phase creates formal links between Atlas assertions and Synome constraints ^[109]. Each Atlas rule maps to one or more Synome invariants, which Sentinels check continuously ^[110]. Violations trigger alerts and actions per cBEAM and aBEAM configurations ^[111].

Phase 4: Sentinel Integration

The fourth phase builds Sentinel interfaces to the Synome, including Read APIs for configuration retrieval, Write APIs for transaction logging, Query APIs for state inspection, and Subscription APIs for real-time updates ^[112].

Comparison with Traditional Approaches

The Synome represents a novel approach to governance infrastructure that differs from both traditional DAOs and pure smart contract systems ^[113].

DAOs and Graph Databases

Identity and decentralized social (DeSoc) graphs have emerged as promising tools for improving DAO data and workflows ^[114]. These tools leverage the blockchain as a central database, increasing transparency and data consistency ^[115]. The Synome extends this approach by creating a purpose-built graph database for operational data rather than relying on social graph structures ^[116].

Traditional DAOs face challenges with data fragmentation, where governance decisions, operational parameters, and execution state scatter across forums, multisigs, and smart contracts ^[117]. The Synome centralizes this data in a structured format while preserving decentralized verification through the Sentinel network ^[118].

Code Is Law Limitations

The "code is law" philosophy that characterizes many DeFi protocols has significant limitations ^[119]. Smart contracts lack flexibility for interpretation, executing automatically based on predefined logic with no room for change when errors or unforeseen events occur ^[120]. They cannot interpret intent, account for jurisdictional nuances, or respond to real-world events ^[121].

The Synome addresses these limitations through the escalation mechanism. While 99% of operations proceed autonomously through code-enforced rules, the 1% that requires human judgment has a structured path to governance ^[122]. This hybrid model preserves automation efficiency while maintaining the possibility of human reasonableness ^[123].

Governance Documentation Standards

The current state of governance documentation in DeFi ranges from informal forum posts to comprehensive constitutional documents ^[124]. Sky's Atlas represents one of the most ambitious attempts at comprehensive governance documentation, but its growth to 364,000 words has created usability challenges ^[125].

The Atlas/Synome separation offers a template for other protocols facing similar challenges: maintain human-readable constitutional principles while migrating operational parameters to machine-readable databases ^[126]. This approach scales better than monolithic documents while preserving democratic legitimacy ^[127].

Open Questions

Several implementation questions remain unresolved as the Synome moves from design to implementation ^[128].

Implementation Architecture

The choice of underlying technology for the Synome remains open ^[129]. Options include on-chain storage (expensive but trustless), off-chain databases (efficient but requiring trust), or hybrid architectures with on-chain anchoring of off-chain state ^[130]. Each approach involves tradeoffs between cost, trust assumptions, and performance ^[131].

Constraint Language

How to express Atlas assertions in a way that is both human-readable and machine-checkable requires further specification ^[132]. Natural language principles must translate to formal constraints without losing meaning or creating ambiguity ^[133].

Mini-Atlas Governance

Whether Mini-Atlases are required or optional, what minimum contents they must include, and who verifies their accuracy against the underlying Agent Artifacts needs clarification ^[134]. These documents serve compliance and communication functions that may require formal standards ^[135].

Migration Governance

How to govern the transition from the current Atlas to the Atlas/Synome split—whether through a single governance vote, phased rollout with intermediate checkpoints, or some other mechanism—requires community decision ^[136].

Versioning

How to version Synome nodes and handle backwards compatibility when constraints change presents technical challenges ^[137]. Agents operating under old constraints may conflict with updated rules, requiring careful migration procedures ^[138].

Access Control

Who can read and write which Synome nodes, and how this maps to the current role structure of Facilitators, GovOps, and Executors, needs precise definition ^[139]. The hierarchical BEAM structure provides a framework, but implementation details remain to be specified ^[140].

Criticism and Considerations

While the Synome architecture addresses real problems in governance documentation and autonomous operation, several considerations merit attention ^[141].

Centralization Concerns

The CC Synome as authoritative source creates a potential centralization point ^[142]. While the design includes distributed stl-synome nodes that sync from the CC Synome, the Core Council's exclusive write access to the authoritative source concentrates power ^[143]. Critics of Sky Protocol's governance have noted that in November 2024 governance votes, just four entities controlled nearly 80% of voting power, raising questions about whether decentralized governance mechanisms meaningfully distribute control ^[144].

Complexity Costs

The Atlas/Synome separation adds architectural complexity to an already complex protocol ^[145]. Maintaining two parallel systems—human-readable Atlas and machine-readable Synome—requires coordination and creates potential for divergence ^[146]. The verification mapping between Atlas assertions and Synome constraints must be maintained as either system evolves ^[147].

Implementation Risk

The Synome remains a design document rather than implemented infrastructure as of January 2026 ^[148]. The gap between architectural vision and deployed systems creates risk that implementation constraints may require design compromises ^[149]. Previous Sky Protocol infrastructure projects have faced delays and modifications during implementation ^[150].

Dependency on Sentinel Network

The Synome's utility depends on the Sentinel Network operating correctly ^[151]. If Sentinels malfunction or are compromised, the machine-readable data in the Synome becomes either useless or dangerous ^[152]. The Minimum Viable Sentinel (MVS) phased rollout acknowledges this dependency by starting with simple verification functions before expanding to full autonomous operation ^[153].

Current Status and Future Development

As of January 2026, the Synome exists as a comprehensive specification within the Laniakea infrastructure roadmap ^[154]. Implementation has not yet begun, pending completion of prerequisite Sentinel infrastructure and governance approval of the migration plan ^[155].

The phased MVS rollout provides the foundation for Synome deployment ^[156]. Phase 1 (Simple Verify) establishes position scraping and risk model calculations. Phase 2 (Simple Settlement) adds monthly PnL and interest calculations for initial Primes. Phase 3 (Simple Settlement Full) extends to all Primes. Phase 4 (Data Integration) introduces the Synome as the central database with Halo self-reporting. Phase 5 (Core Halos & Standardization) addresses underlying data fragmentation through standardized Artifacts ^[157].

The Synome represents a significant evolution in how decentralized protocols manage governance and operational data ^[158]. By separating human-readable constitutional principles from machine-readable operational parameters, Sky Protocol aims to achieve both democratic legitimacy and autonomous efficiency—a balance that has eluded many governance systems ^[159].

Sky Atlas — The constitutional governance document that forms the Synome's root node
Sky Stars — The Prime Agents that operate as Synomic Agents within the framework
Sky Primitives — The modular building blocks coordinated via Synome configuration
Sky Protocol — The broader protocol context for Synome infrastructure