Sidestream EA proposes updating the payload execution process for Star spells to enhance resilience and scalability. This document follows recent issues with Star Spells and anticipates the upcoming launch of multiple new Stars. The update will ensure robust handling of payloads from multiple active Stars.

:::warning
Note: this is a work-in-progress document
:::

## Current approach
Currently, each new Sky Star is planned to have a contract called [SubProxy](https://github.com/makerdao/endgame-toolkit/blob/14268515aa729a588096f0d579ea38bde3e9ba2f/src/SubProxy.sol) (originally developed as part of the endgame-toolkit, audited [here](https://www.chainsecurity.com/security-audit/maker-endgame-toolkit)). The purpose of the contract is to execute the Star-scoped spells with the rights limited to the Star and no access to the Core contracts. The current `SubProxy` contract is designed to execute the Star spell in the same transaction as the Core spell.

### Problems with the current approach

1. **Risk of Core spell revert due to Star spell**. Risks associated with the Sky Stars are supposed to be limited by the maximum debt ceiling ([`DssAutoLine[ilk].line` parameter](https://github.com/makerdao/dss-auto-line/blob/bff7e6cc43dbd7d9a054dd359ef18a1b4d06b6f5/src/DssAutoLine.sol#L32)) set per each allocator module. While it is true in theory, there is currently a place where risks associated with one Star can be carried over to the Sky core or other Stars. Current system is designed to execute the Core and all Star spells together in the same transaction. While this approach has its benefits (listed below), it also poses a risk of reverting the Core spell due to a problem within any of the Star spells.

2. **The current approach is bottlenecked**. Executing all spells within the same `cast` transaction can consume more gas than the maximum gas limit per block enforced by Ethereum. To give 2 specific examples:
- [Executed `2025-03-20` spell](https://etherscan.io/tx/0xfa915f838ad5b31fe05d1f31669af9496e65c5cc0656695298bd14dc8b6793ab) (which had a lot of content on the Spark side with relatively few items in the Core spell) consumed 15,4M gas out of the current block limit of 30M, taking approximately half of the block space. If there would have already been another Star Spell or more Core Spell content, all together they wouldn't fit into one spell.

- A recent request from the RWA Star team also shows that the bottleneck is already noticeable by the Stars: “I'd prefer to make sure that the July 10th spell is not planned to be a large one, because we will probably not only need the contents that we already worked on, but also some more stuff”

3. **Star spells have less integrity protection than the core spell**. Currently, the Star spells are not protected on the blockchain-level from the `CREATE2`/`SELFDESTRUCT`-based attacks, while the Core spells are protected from it by the [design of the pause contract](https://github.com/makerdao/ds-pause/blob/5e798dd96bfaac978cd9fe3c0259b486e8afd213/src/pause.sol#L129).

4. **Star spells can change SubProxy owner**. The current design of the SubProxy allows maliciously crafted and improperly reviewed Star spell to take ownership of the SubProxy and then make any modifications to the Star contracts without requiring any governance action.

**Note**: problems 1 and 2 exist even with well-functioning reviews, but in theory could also be intentionally exploited to prevent execution of the core spell during a critical update.

### Benefits of the current approach

- The main benefit is simplicity. As everything is executed within one block, external interference is not possible. In this situation, the Star spell acts as part of the Core spell, but with its access being limited to Star contracts.
- The second benefit is the keeper-support. Currently, neither changes to the Chief keeper need to be made, nor additional copies of keepers have to be run by TechOps to support new Star spells

## Recommended changes

We propose to develop a new standardized “proxy wrapper” based on the whitelisting principle. In other words: when initiated, the execution of the Core spell will only whitelist certain Star spells, which are then executed via separate transactions.

### Benefits of the proposed design

- No bottleneck due to the transaction size limitation: The Core spell is able to whitelist an arbitrary amount of Star spells, independent of their size or complexity

- No risks of the Core spell reverting due to any Star spell, as they will be executed via separate transactions

- Possibility to fallback to the current pattern in case Star spell have to be executed within the same transaction as Core spell

- Potentially, the new approach can have more flexibility over timing of the execution:
- Star spells can have longer delay than the Core spells, allowing them to "go live" when they plan to, or even introduce their own “office hours”. Also, the Core spell doesn't have to enable standard “office hours”, if only one of the Stars needs it
- Star spells might have expiration time, enforcing them to not wait too long to execute their spell (but when utilizing a [dss-cron](https://github.com/makerdao/dss-cron) it would likely be done in the next block)

- Potentially, the new approach can ensure integrity of the provided spell by validating its `codehash` the same way it’s currently done for the core spells
- The new approach allows the [“dark spell” pattern](https://mips.makerdao.com/mips/details/MIP15) to be applied to a single Star to patch Star-specific vulnerability

- Star spells will be able to introduce their own checks and protections against front-running, as these protections wouldn’t compromise execution of the Core or all other Star spells (for example, a Star can ensure that their Star spell is only executable if the price of a certain asset is within specified bound)

- Proxy ownership change can be made impossible via a Star spell (although a similar attack, changing ownership of other Star-owned contracts, would still be possible)

### Identified risks of the proposed design

- Possibility for external actors to execute anything in-between the Core and the Star spell. For example, a Core spell that increases line, which is then taken advantage of by the frontrunner. This is, however, unlikely with a correctly configured system. Moreover, if needed, the new design can still allow to “fallback” to the current pattern and execute a specific Star spell within the same transaction as the Core spell (e.g., if the risk of front-running is deemed higher than the risk of the Core spell revert).

- Execution of the whitelisted Star spells wouldn’t be automatically supported by the existing Chief keeper run by TechOps. However, we propose to utilize [dss-cron](https://github.com/makerdao/dss-cron) to make it less dependent on the off-chain infrastructure

## Scope of the required work
1. Development of the new contracts, scripts to deploy and initialise and the audit of those contracts
2. Deployment and verification of the new contracts, execution of the init script by the Core spell

## Initial technical specification

- Develop `StarGuard` contract deployed per each allocator Star
- Owned by the Pause Proxy
- Only the owner is able to whitelist new spells
- Have configurable “expiration delay” (max time between the whitelisting and the execution)
- Whitelisting requires
- The address of the Star spell
- The hash of the bytecode
- Execution
- Is permissionless
- Ensures whitelisted spell is executable only once
- Ensures whitelisted bytecode codehash is valid
- Ensures `spell.isExecutable()` view function returns `true` – to allow custom "office hours" implementation by the Star spell
- Calls `exec(calldata)` on the `SubProxy`
- Checks that `StarGuard` hasn't lost access to `SubProxy`
- Develop init script
- Authorizes new `StarGuard` instance on the relevant `SubProxy`
- Adds both contracts to chainlog
- Optionally configures the job
- Optionally develop `StarGuardJob` contract
- Owned by the Pause Proxy
- Contains the list of supported `StarGuard` contracts with add/remove methods
- Provides cron-compatible methods for getting `calldata` and executing a job