Quantstamp Submits First Idle Governance Proposal

December 15, 2020
Quantstamp Announcements

Gov Tokens Allocation Fix in Idle

On December 14th, a minor bug in the governance tokens distribution module in Idle protocol was reported.

The incident does not involve any deposited funds in Idle protocol (Best-Yield or Risk-Adjusted strategies) nor the accrued yield provided by the underlying protocols.

Governance tokens distribution ($IDLE and $COMP) is affected by the bug under specific circumstances, hence resulting in a misallocation of a small number of tokens to liquidity providers. According to the initial assessment, approximately ~150 IDLE and ~1 COMP have been misallocated since the launch of Idle Governance.

The bug has already been mitigated by a joint effort with Quantstamp and Idle team members, and Quantstamp has proposed a patch via a governance proposal, IIP-1. For security reasons, Quantstamp and the Idle team will fully disclose the bug once the on-chain proposal is implemented.

Core Facts

Quantstamp collaborated with the Idle team to investigate this inquiry, identifying the vulnerability and working on both the temporary mitigation patch and the final proposal.

Next Steps

The on-chain proposal, IIP-1, launched by Quantstamp is available here.

Idle Governance has 3 days to cast its vote, in favor or against it. If the “For” vote wins and 4% of IDLE tokens have casted a vote, IIP 1 will be implemented after 2 days (grace period).

If you want to get in touch with the Idle team, feel free to join their community on Twitter, Discord, or Telegram.

Quantstamp Announcements
December 15, 2020

Gov Tokens Allocation Fix in Idle

On December 14th, a minor bug in the governance tokens distribution module in Idle protocol was reported.

The incident does not involve any deposited funds in Idle protocol (Best-Yield or Risk-Adjusted strategies) nor the accrued yield provided by the underlying protocols.

Governance tokens distribution ($IDLE and $COMP) is affected by the bug under specific circumstances, hence resulting in a misallocation of a small number of tokens to liquidity providers. According to the initial assessment, approximately ~150 IDLE and ~1 COMP have been misallocated since the launch of Idle Governance.

The bug has already been mitigated by a joint effort with Quantstamp and Idle team members, and Quantstamp has proposed a patch via a governance proposal, IIP-1. For security reasons, Quantstamp and the Idle team will fully disclose the bug once the on-chain proposal is implemented.

Core Facts

Quantstamp collaborated with the Idle team to investigate this inquiry, identifying the vulnerability and working on both the temporary mitigation patch and the final proposal.

Next Steps

The on-chain proposal, IIP-1, launched by Quantstamp is available here.

Idle Governance has 3 days to cast its vote, in favor or against it. If the “For” vote wins and 4% of IDLE tokens have casted a vote, IIP 1 will be implemented after 2 days (grace period).

If you want to get in touch with the Idle team, feel free to join their community on Twitter, Discord, or Telegram.

Quantstamp Announcements

The Exploit Race

Web3 is different from “normal software” for one brutal reason: bugs turn directly into money. In 2025 alone, an estimated $3.4B was stolen through crypto exploits. That incentive creates a uniquely hostile environment where attackers systematize vulnerability search.

Read more
Quantstamp Announcements

Engineering Smart Contract Families for Solidity

Decentralized applications (dApps) (e.g., DEXes) increasingly span multiple Ethereum-compatible chains, such as a number of L2s. Although these chains are intended to be compatible with the Ethereum Virtual Machine (EVM), subtle differences in opcode implementations can significantly alter smart contract behavior and security. This poses an important question: how can developers efficiently code and manage smart contracts targeting different chains?

Read more
Quantstamp Announcements

Will EIP-7702 Affect Your Code?

The upcoming EVM hardfork, Pectra, amongst other changes, will implement EIP-7702, a proposal introducing a new transaction type that allows Externally Owned Accounts (EOAs) to delegate—and later undelegate—their behavior to smart contracts. While this upgrade enhances flexibility, it also disrupts long-standing security assumptions in many deployed contracts. With the risk that malicious actors may exploit these changes once Pectra is enabled, it is crucial to assess whether your codebase might be negatively impacted.

Read more