BEAM Payload Safety

Bounded External Access Modules (BEAMs) represent a fundamental shift in how Sky Protocol executes routine parameter changes. Rather than requiring full executive votes and spell deployments for every rate adjustment, BEAMs delegate specific, bounded authority to governance-whitelisted operators who can modify parameters within strictly defined safety caps ^[1]. This architecture emerged as Sky Protocol transitioned toward a spell-less paradigm, where the overhead of crafting, auditing, and executing weekly spells for routine changes became increasingly impractical as the protocol scaled across multiple Stars and deployment chains.

The BEAM system addresses a critical tension in decentralized governance: the need for operational agility in competitive DeFi markets versus the security guarantees of on-chain voting. Traditional governance execution through spells requires days of lead time, from forum discussion through spell crafting, community audit, executive vote, and the Governance Security Module (GSM) delay period. For time-sensitive parameter adjustments, such as responding to market volatility with stability fee changes, this cadence proved too slow ^[2]. BEAMs resolve this by pre-authorizing a bounded action space through governance votes, then allowing trusted operators to act within those bounds without further voting.

As of March 2026, two BEAM implementations operate on Sky Protocol's Ethereum mainnet: the Stability Parameter BEAM (SP-BEAM) and the stUSDS BEAM. Together, these modules handle the protocol's most frequently adjusted parameters, including stability fees for vault types, the DAI Savings Rate (DSR), the Sky Savings Rate (SSR), and stUSDS-specific rates ^[3]. The transition from spell-based parameter management to BEAM-based execution represents one of the most significant operational changes in the protocol's history, shifting risk from complex spell code to bounded smart contract logic.

Architecture and Design

The BEAM architecture implements a constrained delegation model that balances operational efficiency with governance control. Each BEAM module is a smart contract that enforces parameter bounds set by governance, ensuring that no operator, even a compromised one, can push parameters beyond predetermined limits. This design draws on established patterns in access control and rate limiting, adapted for the specific requirements of decentralized protocol governance.

Core Bounded Parameter System

Every BEAM implementation shares four fundamental safety parameters that define the operational envelope for any parameter change ^[1]:

min — The absolute minimum value that any governed parameter can be set to. For example, a stability fee might have a minimum of 0%, preventing operators from setting negative rates that would drain the protocol's surplus ^[4]
max — The absolute maximum value, capping the upper bound to prevent excessive fees or rates that could destabilize vault positions. Governance determines these ceilings through executive votes ^[5]
step — The maximum amount by which a parameter can change in a single operation. Even within the min-max range, operators cannot make large sudden adjustments. For SP-BEAM, the current step of 400 basis points (4%) means stability fees can move at most 4 percentage points per operation ^[6]
tau — The cooldown period between successive adjustments. This temporal constraint prevents rapid-fire changes that could manipulate the system or reflect compromised operator behavior. Both SP-BEAM and the stUSDS BEAM currently use a tau of 57,600 seconds (16 hours) ^[7]

These four parameters create a bounded action space that governance can reason about in advance. When voting to enable a BEAM, token holders evaluate the worst-case scenario, what happens if an operator uses the full min-max range at maximum step frequency, and approve only configurations where this worst case remains acceptable for the protocol.

SP-BEAM Implementation

The Stability Parameter Bounded External Access Module (SP-BEAM) is the first and most widely used BEAM implementation, handling the protocol's core economic parameters ^[3]. SP-BEAM enables governance-whitelisted operators to adjust:

Stability Fees — Per-vault-type interest rates charged to borrowers. Different collateral types (ETH-A, ETH-B, WBTC-A) each have independent stability fee parameters managed through SP-BEAM
DAI Savings Rate (DSR) — The yield offered to DAI depositors in the DSR contract
Sky Savings Rate (SSR) — The yield offered to USDS depositors through the sUSDS wrapper

The SP-BEAM contract is referenced in the Sky Atlas under section A.3.7.1.3, within the Stability Scope's "Measures for Endgame Transition" section ^[3]. The official implementation is maintained in the sky-ecosystem/sp-beam GitHub repository ^[8].

SP-BEAM governs parameters for eight native vault types (ETH-A, ETH-B, ETH-C, WSTETH-A, WSTETH-B, WBTC-A, WBTC-B, WBTC-C), five allocator vaults (Spark, Nova, Bloom, Obex, Pattern), the SSR, and the DSR. All native vaults share bounds of max 3,000 bps (30%), min 200 bps (2%), and step 400 bps, while allocator vaults and the DSR have a min of 0 bps ^[6]. The contract has a technical hard ceiling of 50% (5,000 bps) regardless of the governance-set max; any attempt to set a rate above this value will revert ^[3]. SP-BEAM was initialized through an executive vote passed on April 17, 2025 (executed May 2, 2025), which also added the emergency halt spell (EMSP_SPBEAM_HALT) to the protocol's chainlog ^[21].

A critical safety feature of SP-BEAM is its emergency disable mechanism. Unlike standard governance changes that must pass through the GSM delay period, governance can disable SP-BEAM without the standard GSM Pause Delay ^[9]. This means that if operators behave anomalously or the contract is suspected to be compromised, the module can be halted rapidly through emergency governance action.

stUSDS BEAM Implementation

The stUSDS BEAM (Atlas section A.4.4.1.3.8) governs parameters specific to the stUSDS token, Sky Protocol's "Expert token" that funds SKY-backed borrowing ^[10]. This BEAM controls:

stUSDS Rate (str) — The yield rate for stUSDS deposits
SKY Borrow Rate (duty) — The interest rate charged on SKY-backed borrowing positions
Maximum Deposit Cap — The ceiling on total stUSDS deposits
Maximum Debt Ceiling (line) — The maximum debt that can be generated through SKY-backed borrowing

The stUSDS BEAM uses the same four-parameter bounded system (min, max, step, tau) as SP-BEAM for rate parameters (str and duty), while the deposit cap and debt ceiling use separate maximum-ceiling parameters (maxCap and maxLine) ^[10]. The operational model mirrors SP-BEAM: operators prepare parameter changes, create transaction simulations to verify correctness, and execute within the bounded envelope.

The stUSDS BEAM's rate parameters have wider bounds than SP-BEAM: max 5,000 bps (50%), min 200 bps for str and 210 bps for duty, and a step of 1,500 bps — substantially larger than SP-BEAM's 400 bps step, reflecting the different risk profile of Expert token parameters ^[1]. The maxCap and maxLine are each set to 1,000,000,000 USDS ^[1]. The stUSDS BEAM was onboarded through the September 4, 2025 executive vote, with initial parameters of str=0 bps, duty=2,000 bps, cap=200,000,000 USDS, and line=200,000,000 USDS ^[22]. Step parameters were subsequently adjusted through the December 11, 2025 executive vote following governance polling ^[23].

Operator Framework and Execution

The BEAM system delegates execution authority to a specific set of governance-whitelisted operators organized through a multisig structure. This operator framework defines who can submit BEAM transactions, how they coordinate, and what verification procedures they follow before executing parameter changes.

Operator Multisig

BEAM operators are organized into a multisig wallet controlled by Core GovOps ^[11]. This structure ensures that no single individual can execute a BEAM parameter change unilaterally. Both the SP-BEAM and stUSDS BEAM operator multisigs use a 2-of-3 signing threshold, meaning at least two of three authorized signers must approve each transaction ^[11]. For SP-BEAM, operator changes are managed by Stability Facilitators in consultation with the Core Council Risk Advisor; for stUSDS BEAM, they are managed by Core GovOps ^[12].

The operator set is not static. Governance can modify the list of approved BEAM operators through the Operational Weekly Governance Cycle or through executive votes ^[12]. This update process ensures that operator access can be revoked quickly if concerns arise about a specific signer's security posture or alignment with governance intent.

Payload Generation Process

The lifecycle of a BEAM parameter change follows a structured process designed to minimize execution risk ^[13]:

Request Origination — The Core Council Risk Advisor posts a request to the Sky Forum specifying the proposed parameter change, including target values and rationale based on current market conditions
Operator Preparation — Upon receiving the request, BEAM operators prepare the on-chain transaction. This preparation phase includes the creation of transaction simulations to verify that the proposed inputs are correct and fall within bounded parameters ^[13]
Simulation Verification — Operators execute the transaction against a fork of the Ethereum mainnet, verifying that the parameter change produces the expected state transitions without unintended side effects
On-Chain Execution — After simulation verification, the operator multisig signs and submits the transaction to the BEAM contract, which enforces bounded parameters at the smart contract level

This process ensures that even before the on-chain safety bounds are tested, a human verification step catches potential errors. The simulation phase is particularly important for complex rate changes that affect multiple vault types simultaneously, where the interactions between parameter adjustments could produce unexpected outcomes.

Verification and Simulation

Transaction simulation forms the critical safety layer between operator intent and on-chain execution ^[13]. The simulation process typically involves:

Input Verification — Confirming that proposed parameter values match the governance request and fall within BEAM bounds
State Transition Modeling — Executing the transaction on a forked chain to observe all resulting state changes, including impacts on existing vault positions, savings rate depositors, and protocol accounting
Gas Estimation — Ensuring the transaction can execute within block gas limits and at reasonable cost
Reversion Testing — Verifying that the transaction reverts as expected when given out-of-bounds inputs, confirming the BEAM contract's safety enforcement

The Block Analitica research team has documented the SP-BEAM's safety properties, noting that the operator can only change rates if the proposed values do not exceed governance-determined max/min/step limits ^[9]. This dual-layer verification (operator simulation plus smart contract enforcement) provides defense-in-depth against both human error and malicious intent.

Transition from Spell-Based Execution

The introduction of BEAMs represents a deliberate architectural shift away from traditional spell-based governance execution. Understanding this transition requires context on how spells work and why they became a bottleneck for protocol operations.

The Traditional Spell Model

Historically, every parameter change in MakerDAO (now Sky Protocol) required a full spell deployment cycle. A spell is a smart contract that, when executed through an executive vote, modifies protocol state through delegatecall from the governance proxy ^[14]. The spell crafting process involves:

Translating governance decisions into Solidity code
Peer review by spell teams (historically Sidestream and Dewiz)
Community audit of the proposed spell
Executive vote to approve the spell
GSM delay period before execution
Keeper-triggered final execution

For routine parameter changes, such as adjusting stability fees by 0.25% in response to market conditions, this entire pipeline introduced days of latency. The spell crafting teams (specialized smart contract developers) became operational bottlenecks, and the complexity of auditing each spell created overhead that scaled poorly as the protocol added more collateral types and parameters ^[14].

The Spell-less Paradigm and Its Risks

The community discussion around BEAM payload safety, particularly within Sky's Laniakea contributor community, has highlighted a nuanced risk consideration: removing spells does not eliminate risk, it relocates it ^[15]. Traditional spells, despite their operational overhead, undergo a rigorous governance process with community review, spell team auditing, and the GSM delay providing a window for emergency cancellation via Protego.

In the spell-less paradigm enabled by BEAMs, the risk shifts from complex spell code (where bugs could cause catastrophic state changes) to bounded parameter spaces (where the worst case is a maximum-bounds parameter adjustment). This is generally a favorable trade: bounded parameter changes are easier to reason about than arbitrary code execution. However, as the protocol evolves toward more complex BEAM types, such as potential future cBEAM (Configurator BEAM) payloads that bundle multiple actions into single transactions similar to Spark Relayer payloads, the safety analysis becomes more demanding ^[15].

The challenge intensifies as Prime Agents generate, verify, simulate, and submit increasingly complex payloads to BEAMs. In the current architecture, the Spark planner handles much of this payload generation through proprietary processes. As the ecosystem expands, contributors have argued that a standardized process for BEAM payload generation should be established, ensuring that all Prime Agents follow consistent safety procedures regardless of the specific BEAM implementation ^[15].

Emergency Safeguards

The BEAM architecture provides distinct emergency mechanisms for each BEAM type, each addressing different threat scenarios ^[16]:

SPBEAM_MOM — A contract (Atlas section A.1.9.3.2.11) that allows Sky Governance to bypass the GSM Pause Delay and disable the SP-BEAM. When activated, the SP-BEAM can no longer change rates, but existing rates remain at their pre-disable levels until modified by a standard executive vote ^[24]
SPBEAMHaltSpell — A reusable standby emergency spell (Atlas section A.1.9.5.2.2.4.2) that triggers the SPBEAM_MOM. As a standby spell, it can be voted on and invoked without deploying new contract code ^[16]
STUSDS_MOM — A contract (Atlas section A.1.9.3.2.12) that disables the stUSDS BEAM with an additional capability not available to the SP-BEAM equivalent: it can also set the stUSDS deposit cap or debt ceiling to zero directly, providing a more aggressive shutdown option ^[25]
Protego Module — The emergency cancellation system that can nullify pending governance actions awaiting the GSM Pause Delay. Protego does not directly affect live BEAM operations (since BEAMs bypass the GSM), but it can cancel malicious executive votes that attempt to modify BEAM parameter bounds ^[14]

Agent Framework Integration

BEAMs operate within Sky Protocol's broader Agent Framework, which defines how different types of governance participants interact with protocol infrastructure. Understanding this framework is essential for comprehending the full payload safety picture.

Prime Agents and Operational Executors

The Sky Atlas defines two agent types relevant to BEAM operations ^[17]:

Prime Agents — Entities that maintain and automate Sky features in new markets. When a Prime Agent formulates a new initiative, it encodes relevant instructions and parameters into its Agent Artifact, a detailed operational blueprint. Insofar as the Artifact requires protocol-level interactions, Operational Executors use it as their implementation guide ^[17]
Executor Agents — Specialized agents implementing Prime Agent strategies. Operational Executor Agents handle day-to-day execution of strategy portions that directly interface with the Sky Protocol, strictly following Prime Agent Artifact instructions. Core Executor Agents oversee Operational Executors to ensure Atlas compliance ^[18]

In the BEAM context, Prime Agents (such as Spark, Grove, and Keel) define strategic parameter targets based on market analysis and risk modeling. Operational Executors then translate these targets into BEAM transactions, following the bounded parameter constraints and simulation verification procedures described above.

StarGuard Execution Path

For more complex governance actions that exceed BEAM scope, the protocol provides the StarGuard execution path ^[19]. Agent Spells (governance actions originating from Stars) are whitelisted in Sky Core Spells and later executed using the StarGuard module. The Sky Core Spell includes a whitelist of approved Agent Spells, which allows them to be executed via separate transactions rather than being bundled into the main weekly spell ^[20].

This separation provides resilience and scalability benefits. If an Agent Spell fails or encounters an issue during execution, it does not affect other governance actions in the same weekly cycle. StarGuard effectively creates an isolated execution environment for each Star's governance actions, reducing the blast radius of any single failure.

Laniakea Target Architecture

The Laniakea design documents describe a more elaborate BEAM hierarchy that will supersede the current SP-BEAM and stUSDS BEAM model ^[15]. In the post-transition architecture, BEAMs are organized into a four-level authority cascade rooted in the Council Beacon:

Council Beacon — An HPHA (High Power, High Authority) beacon operated by the Core Council's 24 Guardians, set through SpellCore spells requiring a 16-of-24 signing threshold. The Council Beacon is the root of all BEAM authority and Synome write rights ^[15]
aBEAM (Admin) — Granted by the Council Beacon, with a 14-day timelock on additions and instant removals. Manages PAU registration, init approvals, and cBEAM grants ^[15]
cBEAM (Configurator) — Granted by aBEAM holders to GovOps teams. Sets rate limits within Second-Order Rate Limit (SORL) constraints of 25% maximum increase per 18-hour cooldown, executes approved controller actions, and manages relayer and freezer addresses ^[15]
pBEAM (Process) — Set by cBEAM holders for direct execution on PAUs, calling Controller functions and moving capital within rate limits ^[15]

This hierarchy introduces a safety asymmetry design principle: additions at any level require a timelock, while removals are always instant, ensuring the system can be shut down faster than it can be expanded. Any individual Core Council Guardian can freeze or cancel any BEAM across the entire system, providing a powerful emergency brake ^[15].

Risk Analysis and Criticism

While BEAMs significantly improve operational efficiency, they introduce new risk vectors and have generated substantive debate within the governance community. A balanced assessment must consider both the security improvements over spell-based execution and the new attack surfaces created by bounded delegation.

Smart Contract Risk

The BEAM smart contracts themselves represent a potential vulnerability. A bug in the boundary enforcement logic could allow parameter changes outside the intended range. However, the contracts are relatively simple compared to full spell implementations, as they only need to check four parameters (min, max, step, tau) rather than executing arbitrary governance logic ^[9]. This simplicity reduces the attack surface and makes formal verification more tractable.

The SP-BEAM implementation has been deployed on Ethereum mainnet and has processed multiple parameter changes without incident since its activation. The open-source implementation on GitHub enables community review and independent security analysis ^[8]. The SP-BEAM module underwent a formal code assessment by ChainSecurity completed on March 31, 2025, prior to the module's mainnet deployment. The audit identified one notable finding related to frontrunning of ilk initializations, which was resolved before deployment by requiring that the step parameter be greater than zero for any configuration ^[26].

Operator Compromise Risk

The most significant risk vector in the BEAM architecture is operator key compromise. If the operator multisig is compromised, an attacker could push parameters to their bounded extremes, potentially destabilizing the protocol. However, several mitigations exist:

Bounded Worst Case — Even a fully compromised operator can only move parameters within the governance-approved range, limiting maximum impact
Cooldown Enforcement — The tau parameter prevents rapid parameter manipulation, buying time for governance to detect and respond to anomalous activity
Emergency Halt — The SPBEAMHaltSpell can disable SP-BEAM specifically without GSM delay, enabling rapid response to suspected compromise ^[16]
Multisig Threshold — Multiple operators must be compromised simultaneously to execute unauthorized changes

Governance Centralization Concerns

Critics have noted that the BEAM system concentrates execution power in a small set of operators rather than distributing it through token-weighted voting. While governance sets the bounds, the specific parameter choices within those bounds are made by operators without further community input. This creates an information asymmetry where operators possess specialized knowledge about optimal parameter settings that the broader community cannot readily evaluate.

Proponents counter that this centralization is deliberate and bounded: governance retains ultimate authority through parameter bounds, operator appointment, and emergency halt capabilities. The system is designed for operational efficiency within governance-defined constraints, not for replacing governance itself ^[3].

Future Complexity Risks

As Sky Protocol evolves toward more complex BEAM implementations, the safety analysis becomes more demanding. Contributors have raised concerns about future Configurator BEAM (cBEAM) payloads that might bundle multiple actions into single transactions, similar to Spark Relayer payloads with many actions within a single transaction ^[15]. In a spell-less paradigm, such complex payloads require robust verification frameworks to ensure safety at the same standard as traditional spells, which benefited from community review and the GSM delay window.

The standardization of payload generation processes across all Prime Agents has been identified as a critical governance priority. Without consistent verification standards, different Stars might apply varying levels of rigor to their BEAM payload generation, creating inconsistent safety guarantees across the protocol ^[15].

Current State and Future Development

As of March 2026, the BEAM system has been operational on Ethereum mainnet since SP-BEAM's initialization on May 2, 2025 ^[21] and the stUSDS BEAM's onboarding on September 4, 2025 ^[22]. SP-BEAM handles the majority of routine stability parameter adjustments, while the stUSDS BEAM manages parameters for the Expert token system. The most recent known BEAM execution was a stUSDS BEAM rate configuration on February 24, 2026. The operational cadence has shifted from weekly spell-based parameter changes to more frequent, targeted adjustments enabled by BEAM's lower execution overhead.

The protocol's governance community continues to debate the appropriate scope of BEAM authority. Some advocate for expanding BEAM capabilities to cover additional parameter types, reducing dependence on spell-based execution further. Others argue for conservative expansion, noting that each new BEAM type requires careful analysis of its bounded worst case and potential interactions with other system parameters. The Laniakea target architecture envisions a structured aBEAM/cBEAM/pBEAM hierarchy with formal rate limit constraints that would provide more granular control than the current model ^[15].

The development of standardized payload generation tools, automated simulation frameworks, and formal verification of BEAM boundary logic represent active areas of work within the Sky ecosystem. These improvements aim to strengthen the safety guarantees of the spell-less paradigm while maintaining the operational agility that motivated the transition from traditional spell-based governance ^[15].

Spells — Traditional governance execution mechanism that BEAMs partially replace
Executive Votes — Governance votes that establish BEAM parameters and authorize operators
Sky Governance Voting — Broader governance system within which BEAMs operate
Sky Atlas — Constitutional document defining BEAM specifications and authority
Sky Stars — Prime Agents that interact with BEAMs for parameter management
Sky Primitives — Modular building blocks including BEAM-related primitives
Sky Savings Rate — Parameter managed through SP-BEAM
stUSDS — Token with parameters managed through the stUSDS BEAM
Diamond PAU Architecture — PAU infrastructure governed through the BEAM hierarchy

BEAM Payload Safety