back
How Story Secures its Governance Processes
Story
26 January 2026
This post is the second instalment in our multi-part series exploring how we approach security at Story. This series shares the principles that guide us, the systems we’ve built, and what we’ve learned along the way. If you missed the first post in the series, which outlines our security philosophy and foundations leading up to our mainnet launch, you can catch up here..
Governance Security in Action
Over the past year, governance mechanisms have become one of the most frequently exploited attack surfaces in crypto protocols. Several high-profile incidents have demonstrated that even when core smart contracts are sound, failures in upgrade execution, multisig signing, or emergency authority can lead to irreversible onchain damage.
As Story transitions from deployment to live operation, governance security is no longer a theoretical nice-to-have, but an existential operational requirement.
This post focuses on how we secure the governance processes that make the ecosystem function. We’ll walk through:
- how protocol upgrades are prepared, reviewed, tested, and executed.
- how onchain governance powers are structured.
- how the Governance Multisig and Security Council work together to reduce risk and act quickly.
What Can Go Wrong in Governance
When governance fails, it's rarely because a single smart contract is broken. More often, incidents emerge at the intersection of human decision-making, upgrade complexity, and time pressure. This is especially true during live incidents.
In practice, most governance-related failures fall into a small number of recurring patterns:
- blind multisig signing, where signers approve transactions they cannot independently reconstruct or verify, often under time pressure.
- upgrade misconfiguration, where incorrect initialization, storage layout changes, or parameter values corrupt state or introduce unintended behavior.
- delayed incident response, where highly decentralized governance processes are unable to act quickly enough during an active exploit.
- over-centralized emergency powers, where security mechanisms intended to protect the system become a single point of failure themselves.
The governance model at Story is designed explicitly around these risks. We assume that mistakes will happen, signers are human, and response time matters. We built processes, checks, and counterbalances that reduce the blast radius when things go wrong.
How We Handle Upgrades
To ensure security and reliability during protocol upgrades, we adhere to a checklist of key elements designed to scrutinize every critical aspect of an upgrade before execution. The key elements we evaluate to ensure a safe upgrade include:
- Namespaced Storage Implementation: As a best practice, smart contracts use a namespaced storage layout (ERC-7201 standard). This architecture helps prevent storage collisions (scenarios where new state variables accidentally overwrite existing data slots), thereby ensuring data integrity across different versions of the implementation.
- ERC-7201 vs. storage gaps: Storage gaps were previously used to handle upgradeability, but the risk of variable collisions remained relatively high, especially when adding many new variables or significantly changing the inheritance chain. ERC-7201 reduces this risk by ensuring the root of a contract’s storage layout is no longer located at slot zero, but instead at a specific slot derived from a chosen namespace. Because different contracts use different namespaces, the likelihood of variable collisions is significantly reduced compared to gap-based approaches.
- Implementation Deployment Script Review: Deployment scripts for new implementation logic undergo careful review. We pay particular attention to constructor arguments, ensuring that immutable variables and initial configurations set on the logic contract are correct before it is linked to the proxy.
- Upgrade Script Review:
Upgrade scripts are reviewed with equal rigor. We verify the inputs passed to the
initializefunction during the upgrade transaction to ensure the proxy’s state is updated correctly. - Security Audits: Before any code is considered for release, new upgrade implementation contracts must undergo both internal and external security audits.
- Security Council Transaction Review: The verification process described in the next section is mandatory for all upgrades. When Security Council approval is required, members manually review the scheduled transaction calldata to ensure the onchain payload exactly matches the expected upgrade data.
The full upgrade process is first executed on the Aeneid testnet. After the testnet upgrade, a dedicated round of testing is conducted on the upgraded contracts.
Only after successfully passing testnet testing does an upgrade proceed to mainnet.
Onchain Governance Powers and Setup
One of the most significant governance capabilities at Story involves taking direct, onchain actions that immediately affect both the Story Protocol and the underlying Story Network. These onchain powers include the ability to:
- whitelist new modules.
- manage dispute parameters (e.g., whitelisting dispute tags and arbitration policies).
- configure royalty parameters (e.g., whitelisting reward pools, setting the treasury, setting royalty fees, and whitelisting royalty policies and tokens).
- configure licensing parameters (e.g., setting registration fees and registering new license templates).
- pause the protocol.
- upgrade the protocol.
From an execution perspective, all of these actions are carried out through Gnosis Safe multisig wallets. Two multisigs are central to this process: the Governance Multisig and the Security Council Multisig. These multisigs operate in close coordination to ensure that every parameter update, configuration change, or code upgrade is performed smoothly and securely.
A Security Council is an independent, semi-centralized group of trusted individuals or entities empowered to act swiftly to protect a decentralized protocol during emergencies. While fully decentralized governance is the long-term goal, Story deliberately maintains a Security Council with narrowly scoped powers. This is a conscious tradeoff: some risks cannot be mitigated by token voting or timelocks alone, especially during live incidents where response time matters.
The Security Council multisig has the authority to cancel scheduled actions before execution if those actions deviate from the expected change (e.g., incorrect inputs) or appear malicious or unexpected (e.g., in the event of a hack). There are currently six members on the Security Council, and the threshold for canceling an action is three votes. The inaugural members are:
To understand how Governance and Security Council multisigs interact in practice, it’s helpful to note the following:
- Story Protocol: on mainnet the admin is AccessManager.sol from OpenZeppelin located at the address
0xFdece7b8a2f55ceC33b53fd28936B4B1e3153d53 - L1-related smart contracts: on mainnet the admin is TimelockController.sol from OpenZeppelin located at the address
0x6c7FA8DF1B8Dc29a7481Bb65ad590D2D16787a82
The AccessManager and Timelock contracts have three main functions: schedule, cancel and execute governance actions.
In simplified terms, the process for preparing, reviewing, and executing a governance transaction looks like this:
Prepare schedule / execute / cancel JSONs:
Recent incidents, including the Bybit governance exploit, reinforced a pattern we explicitly design against: multisig signers approving transactions they cannot independently reconstruct and verify. At Story, transaction JSONs and calldata are treated as first-class security artifacts and the primary source of truth for verifying exactly what an onchain governance action will do before it is signed.
Transaction JSONs are prepared to call the
schedule,cancel, andexecutefunctions onAccessManager.sol. While simple cases can be handled through the Safe UI, complex or multi-step transactions require a custom script that generates the JSONs. This allows developers and signers to review the calldata beforehand and serves as a source of truth during verification.Sign schedule transactions:
The Governance multisig proposer submits the
scheduletransaction to the Governance multisig.Verify scheduled transactions:
Security Council members review the scheduled transaction data to confirm it matches the originally intended actions. Depending on the outcome:
- If verification passes, the Governance multisig proceeds to call
executeonAccessManager.sol - If verification fails, the Security Council calls
cancelonAccessManager.sol
- If verification passes, the Governance multisig proceeds to call
Future Steps for Governance Security
To further strengthen governance security, it is essential to clearly define and understand the full scope of governance powers within the Story ecosystem. These powers extend well beyond onchain execution and include a broader set of critical decisions that shape the protocol and the network over time.
As outlined in the Story Constitution, governance actions may include:
- amending the Constitution and other foundational governing documents.
- electing or removing Security Council members.
- appointing or removing Foundation supervisors.
- issuing non-binding recommendations to Foundation Directors on matters such as committee formation or dispute resolution policy updates.
- granting additional tokens to initiatives or participants, subject to an annual aggregate cap of 1 million tokens.
- signalling community support for protocol upgrades.
- signalling community consensus on proposed hard forks or major network upgrades.
These powers demonstrate the significant authority held by governance within Story — particularly when it comes to leadership selection, budget and token allocation, incorporating community feedback, and deciding whether and how proposed improvements are implemented.
As governance decisions increasingly translate into direct, irreversible onchain actions, security and robustness become even more critical. In upcoming posts, we’ll dive deeper into the onchain governance mechanics that underpin these processes.
In the near term, token voting is being explored as a way to expand community participation in governance. Because voting power may vary based on staking status, voting calculations will likely rely on L1 APIs and be executed off-chain. More details will be shared as Story continues working toward more open, community-driven governance.
