Panic Button Activation Incident Report.
On April 16, 2026, the Money On Chain protocol activated its Panic Button after validating a critical flaw in the OMoC-Decentralized-Oracle infrastructure. The purpose of this report is to explain why the Panic Button was activated, why that decision was necessary, and how this mechanism protected the protocol during a period of immediate risk.
Funds are safe. No funds were lost. The identified flaw was not exploited.
The pause only affected minting and redemption of DOC and BPRO through the protocol. Transfers of DOC, BPRO, and MOC continued to function normally, and trading those assets on decentralized exchanges such as Uniswap remained available. After the pause is lifted, protocol operation returns to normal.
What Happened.
The Money On Chain minting and redemption of DOC and BPRO was paused upon discovery of a flaw in the oracles infrastructure that put the entire protocol funds at immediate risk. The issue was reported to, and investigated by, the mimLABS team. The pause was enacted by the operators of the Panic Button mechanism, which is a multi signature contract controlled by the protocol’s decentralized governance, and whose operation had been delegated by governance to the current signers.
The issue was first communicated early Thursday, April 16, 2026, through a disclosure path that began with a team working through Immunefi while auditing Tropykus. After intense investigation, about 2 hours later, we concluded that an attacker could register as an oracle and immediately publish arbitrary BTC/USD prices on chain. Controlling the BTC/USD price without consensus would allow an attacker to drain funds in the protocol, and would also affect other protocols and integrations that rely on the BTC/USD price, as well as the BPRO/USD price derived from it.
This was therefore an incident about immediate protocol risk, and about the activation of the protection mechanism designed for exactly this type of emergency. No exploit occurred, no funds were lost, and funds remain safe.
About OMoC Oracles And The Identified Flaw That Brought Up The Risk.
The OMoC-Decentralized-Oracle network is the infrastructure that publishes the on chain BTC/USD price used by Money On Chain, and also relied upon by other protocols in the Rootstock ecosystem. The system provides a price that is uniquely precise and up to date, hence it’s favoured by DeFi protocols and hard to replace with other oracle providers.
The oracle set is decentralized, and is composed of up to ten oracle operators. To participate, an operator must stake enough MOC tokens to occupy one of the 10 available slots. The more MOC an operator stakes, the greater its participation in price publication and reward allocation. These operators collectively, and by consensus, provide the price that the protocol uses directly, and that other systems also consume either directly or through derived values such as BPRO/USD.
Each oracle operator manages two addresses. One is the owner address, which is the long term identity of the oracle, the address that stakes MOC, and the address that receives oracle rewards. This address is expected to be kept under strong protection, typically in a hardware wallet or a secure contract. The other is the operative address, which is the hot wallet address used by the operator’s running infrastructure to sign the messages involved in the price publication process. Because this operative key lives in active infrastructure, the protocol allows it to be rotated.
These contracts have existed since the protocol started, and over the course of their lifetime they were reviewed by multiple human audit teams, both internal and external, and were also part of the Money On Chain bug bounty program through Immunefi. Even so, two bugs that had existed since the beginning of the protocol were identified only now. We believe the growing effectiveness and availability of AI assisted review tools is a likely reason these issues were finally discovered.
The identified risk came from the interaction of two bugs. The first bug affected operative key rotation. The second bug affected validation of the signatures used to publish prices. Together, they made it possible for a single oracle operator to bypass the intended consensus process and publish an arbitrary price.
First Bug, Stale Operative Address Mappings After Key Rotation.
When an oracle operator rotated its operative key, the old operative address was not removed from the on chain lookup table that maps operative addresses back to their owner address. That meant the old operative address remained recognized by the protocol as belonging to the oracle owner even after rotation.
This was a mistake. When key material is rotated, all cryptographic references that remain security relevant should be removed. In this case, the old operative address no longer had any legitimate function once rotation was completed. Keeping that stale lookup entry was unnecessary from a gas perspective, incorrect from a protocol design perspective, and dangerous from a security perspective.
This bug alone already meant that key rotation did not fully revoke the previous operative key. If an attacker managed to obtain old operative keys from multiple oracle operators, even operators that had attempted to rotate correctly could still remain exposed. That path required time, preparation, and likely some degree of social engineering, so it was concerning but not the most immediate threat by itself.
Second Bug, Signature Validation Counted Operative Addresses Without Enforcing Owner Uniqueness.
To publish a price, an oracle must submit signatures from more than half of the selected oracle set. The validation routine recovered the signer addresses, mapped each signer back to an oracle owner, and checked that the recovered owner belonged to the active round. The code assumed that each owner could only have one valid operative address, so it did not verify that the submitted signer addresses corresponded to distinct oracle owners.
Because stale operative addresses remained in the lookup table after rotation, a single oracle owner that had rotated multiple times could have several operative addresses still recognized as valid signers. That meant one oracle operator could sign the same publication message several times using different operative addresses, all of which mapped back to the same owner, and still satisfy the apparent signature threshold. In practical terms, this allowed a single oracle operator to bypass consensus and publish an arbitrary BTC/USD price.
This second bug transformed the stale cleanup issue into an immediate threat to protocol funds.
Why The Risk Was Immediate.
The oracles protocol is decentralized. There is no whitelist for entry, and there is no waiting period before a new operator can join. An attacker only needed to buy enough MOC, stake it, register as an oracle, and execute the attack. Under the conditions that existed at the time of the incident, that could have happened in a matter of minutes.
There were several aggravating factors that made this particularly easy at that moment. Four oracle slots were vacant. Entry into a vacant slot was immediate. The minimum entry threshold for an open slot was 250,000 MOC. The market price of MOC made that amount unusually cheap relative to the scale of the attack surface it opened. This meant that a malicious actor did not need to compromise an existing oracle operator in order to exploit the flaw. It was sufficient to become an oracle directly, quickly, and at low cost.
The combination of technical severity and immediate exploitability is why the Panic Button was activated as soon as the investigation confirmed the risk.
Scope Of The Pause.
The protocol had never been paused before. The decision to activate the Panic Button was exceptional and was not taken lightly.
The Panic Button paused minting and redemption of DOC and BPRO through the protocol. It did not pause the transfer of DOC, BPRO, or MOC between users. It did not pause trading those assets in decentralized exchanges such as OKU. It also did not provide any power to freeze specific user balances or interfere with user custody.
This distinction is important, as the Panic Button exists to provide immediate protection at the protocol level while preserving user control over their assets. Funds are safe, no funds were lost, and once the pause is lifted all protocol operations return to normal.
Ecosystem Impact.
The OMoC-Decentralized-Oracle network is not only used by Money On Chain. It is also used by third party protocols such as Tropykus and Sovryn, and by additional on chain and off chain integrations across the Rootstock ecosystem. The oracle network provides a precise and frequently updated BTC/USD price on chain, which is a valuable service that many integrations depend on. Because BPRO/USD is derived from the protocol state and depends on BTC/USD, a manipulated BTC/USD price would also propagate risk to systems relying on BPRO/USD.
We coordinated closely with known downstream users so they could evaluate their own exposure and take their own governance decisions. At the same time, because the oracle service is widely consumed and there was no realistic way to identify and coordinate with every party relying on these prices, some exploit enabling details were intentionally withheld while the issue remained live. That decision was made as an attempt to reduce ecosystem wide risk during the response window, although current AI tools reduce the effectiveness of this “security by obscurity” approach in smart contracts.
Timeline.
Early on Thursday, April 16, 2026, the mimLABS team received first contact regarding the issue through a disclosure path involving Tropykus and Immunefi related research. Investigation began immediately.
On the same day, less than 2 hours later, the issue was validated as real and critical. At that point we concluded that an attacker could become an oracle, publish arbitrary BTC/USD prices without consensus, and use that power to threaten funds in the protocol. That same price manipulation capability would also place downstream protocols at risk through direct reliance on BTC/USD and indirect reliance on BPRO/USD. Because the attack was immediately actionable, the Panic Button was activated that day. In parallel, we started reviewing the historical on chain oracle activity to determine whether the flaw had ever been used before.
By Friday, April 17, 2026, a tested fix had been completed and a governance proposal to apply it was prepared and submitted through the existing MoC governance process. The proposal required approximately twenty four hours to reach quorum, followed by a seven day voting period. During that time the oracle infrastructure remained under close monitoring, interim mitigation measures were applied, and the vulnerability remained unexploited.
Historical Review And Interim Mitigations.
After discovery of the issue, we explored the historical on chain activity of the oracle system to determine whether the key rotation path had previously been exploited in this way. We found no evidence that it had.
While the fix moved through governance, we also worked to make the attack less actionable in practice:
We coordinated responses with ecosystem stakeholders exposed to BTC/USD and BPRO/USD.
We limited publication of exploit enabling details while the issue remained live.
We urged MOC holders to withdraw liquidity from markets so that acquiring the staking tokens needed for a fast oracle entry attack would become harder.
We encouraged staking into vacant oracle slots in order to raise the effective barrier to entry.
None of these measures removed the underlying bug, but they reduced the immediate practicality of the attack while governance completed the fix.
The Fix.
The remediation addressed both failure modes. Rotated operative addresses must be fully invalidated, including any lookup entries that would otherwise allow an old operative key to remain recognized. Signature validation must also enforce uniqueness at the oracle owner level, rather than only at the operative address level. Together, these changes restore the intended consensus guarantees of the oracle publication process.
Why We Acted Quickly.
This incident also reinforced a broader change in the security environment for smart contracts. We are seeing a growing volume of automated, AI assisted vulnerability discovery. These tools reduce the cost of finding subtle flaws to a level that no human team could consistently match, even with substantial time and budget. That changes the value of security by obscurity for zero day smart contract bugs.
Once a flaw has been found, we should assume that other capable parties may also find it quickly and may attempt to exploit it. That assumption informed our response. After validation, we treated this issue as an immediate live threat and acted accordingly.
Lessons And Next Steps.
The bug is fixed, but this incident changed how we think about the strategic importance of the oracle network. The OMoC-Decentralized-Oracle system is critical infrastructure for Money On Chain and for other Rootstock protocols, and hardening it must go beyond correcting this specific flaw.
One major priority is improving oracle operator incentives. The ten available slots should remain filled at all times, and participation should be attractive enough that there is a queue to join. The current limit of ten slots is related to the cost of signature verification on Rootstock. If native Schnorr verification becomes available in the future, that constraint could change and allow the oracle set to scale further.
Another lesson is that protocols depending on this oracle service should be more directly aligned with the cost and responsibility of operating it. So far, the oracle network has provided a valuable service to the ecosystem free of charge to any protocol other than Money On Chain. MoC governance should consider charging consumers of these prices. That would improve sustainability, strengthen incentives, and create reasons for downstream protocols to participate directly as oracle operators themselves.
This incident also highlighted the importance of well governed circuit breakers. Public discourse often treats decentralization and delegated emergency powers as if they were incompatible, but this incident showed why that view is too simplistic. A decentralized governance can delegate limited and revocable protective powers to a constrained set of signers without granting them the permanent ability to freeze user funds. The Panic Button mechanism does not give its operators the ability to seize balances or censor normal transfers, it just gives them a narrow emergency response capability that can protect the protocol while preserving user custody.
Closing.
The Panic Button was activated to protect users, integrators, and protocol funds during a period of real and immediate risk. It worked as intended.
Funds are safe. No funds were lost. After the pause is lifted, all protocol operations return to normal.
This post mortem is written by the mimLABS team, as protocol developers and stewards we are deeply sorry for the impact of these bugs, and we’ll work harder so that this never happens again.
As part of the money on chain community, we want to state our approval of the Panic Button. Although it is sometimes publicly mischaracterized by detractors as a point of centralization, this incident showed its true value protecting the protocol from critical vulnerabilities while maintaining a decentralized governance and user ownership.
“For a successful technology, reality must take precedence over public relations, for nature cannot be fooled.” --Richard Feynman
Disclaimer
This report is provided for transparency and informational purposes only. It does not constitute financial, investment, legal, or any other form of advice. Interaction with decentralized protocols involves inherent risks, including but not limited to smart contract vulnerabilities, market volatility, and potential loss of funds.
While the information presented here is believed to be accurate at the time of publication, it may be subject to updates or revisions without notice. Users are solely responsible for evaluating the risks associated with the use of the Money On Chain protocol and for making their own independent decisions.
Nothing in this report should be interpreted as a guarantee of future performance, security, or availability of the protocol. Past performance and incident outcomes, including the absence of losses in this case, do not guarantee similar results in the future.