Impact of the Istanbul hard fork on Aragon organizations

⚠️ The warnings in this advisory post apply only to organizations created before Sept. 11, 2019 (old organizations).

If your organization was created through the Aragon client after the Aragon 0.8 release on Sept. 11, 2019 (new organizations), you will not be significantly impacted by the hard fork and do not have to take any action.

If your organization was created before Sept. 11, 2019, we recommend carefully reading this post to understand how the upcoming Istanbul hard fork will impact your organization. In short, if you would like to use the new Agent app with an organization created before Sept. 11, 2019, we strongly recommend creating a new organization and migrating your users, tokenholders, and funds over to the new organization instead of using your pre-0.8 organization.

The Istanbul hard fork is scheduled to occur at block 9,069,000 or roughly 20:00 UTC on December 7th, 2019. As with all hard forks, we encourage users to exercise caution around the time of the fork and be alert for anything weird with the network, newly sent transactions, or dapps.

If you notice a problem with the network during the hard fork, please refer to this list for emergency contact information. If the issue specifically concerns your Aragon organization, please contact support@aragon.one.

After the hard fork, organizations created before Sept. 11, 2019 will lose the ability to accept ether (ETH) deposits to their installed Vault or Agent apps from other smart contracts. For these organizations, an immediate consequence is that they will not be able to receive ETH from other organizations' Vaults. Technically, only contracts using send() and transfer() to send ETH will stop working, but unless otherwise noted, you should assume a contract uses one of these methods if it is able to send ETH—this includes most smart accounts provided by wallets.

The hard fork will not impact withdrawing ETH from the Vault or Finance apps and users will still be able to directly deposit ETH into Vaults with externally-owned-accounts. Depositing through the Finance app's frontend or by directly sending ETH to an install Finance or Vault app will work.

Your organization will not be affected by the hard fork if you and your organization members are only using the Aragon client via an externally-owned-account and your organization is not interacting with any other external contracts—either by using the Agent app or setting the Vault as the recipient of an ETH-sending contract. This should be true for the vast majority of organizations created before Sept. 11, 2019.

The Agent app complicates matters because unlike Finance and Vault, it is designed to interact and freely transact with on-chain protocols, like Maker, Uniswap, Kyber, and others. It is a direct expectation that the Agent app would be able to accept ETH from other contracts, such as SAI's CDP contracts. Otherwise, it may irreversibly result in a loss of ETH from the Agent.

For users of older organizations who are interested in either using the Agent app or connecting to their organizations with a smart account, we recommend creating a new organization and migrating all users, tokenholders, and funds from the older organization. Unfortunately there is no easy migration path available for assigned aragonid.eth subdomains and it is recommended to select a new aragonid.eth subdomain for the new organizations.

For users of older organizations who were already using the Agent app while it was in its beta phase, we recommend closing out all open contract interactions — e.g. CDPs, orders on decentralized exchanges, etc — and migrating to a new organization before Istanbul activates.

As an example, in the case of a CDP or Maker Vault, you should use Frame to either close out any outstanding debt, withdraw remaining ETH, and migrate all funds to a new organization, or directly transfer ownership of the CDP to a new organization's Agent app.

We have plans to include a visual warning in the Aragon client for organizations affected by this hard fork but will not be able to release the feature ahead of the hard fork.

Please contact support@aragon.one if you have further questions or would like to request help with a migration.

Technical details

The reason Istanbul will cause contracts to change behaviours is due to a particularly contentious change included in Istanbul: EIP-1884. In short, the EIP proposes to significantly increase the gas cost of all SLOAD operations, amongst other state trie-dependent operations, to better align these virtual operations' costs with their current-time real-world computing costs.

The Ethereum network is shared and growing, and some operations, like SLOAD, have real-world costs closely mirroring the size of the network's state. Mispricing these types of operations can lead to significant harm on the overall network as a denial-of-service (DOS) vector becomes increasingly exposed to attackers for stalling new blocks . Note that this is the second time SLOAD has been re-priced; the first was in defence from the Shanghai DOS attacks with EIP-150. SLOAD is now priced at 800 gas, a significant increase from its original 50 gas.

Particularly hard hit with this EIP are dapps expecting to execute a small layer of logic upon receiving ETH. send() and transfer() were introduced into Solidity after the DAO hard fork to alleviate re-entrancy concerns by only providing a small 2300 gas stipend to the contract receiving ETH. Its intention was still to allow the receiving contract to execute a few instructions and possibly emit a log event.

Given the already limited gas stipend, dramatically increasing the cost of some opcodes will cause previously successful ETH transfers to begin failing with out-of-gas errors. A security analysis was completed by ChainSecurity ahead of EIP-1884's acceptance into the hard fork and found that outside of Aragon, other high-profile dapps like Kyber and Totle were similarly impacted with severe behavioural changes.

Aragon 0.8, released on Sept. 11, 2019, deployed an optimized version of the AppProxy contract used by default in organizations to install applications. This new version of the AppProxy contract was specifically designed against the increased cost of SLOAD, and will not change behaviours following the hard fork.

Unfortunately, AppProxy contracts are not themselves upgradeable, and hence older organizations are not able to receive this change. Our original AppProxy contracts were designed with the best practices at the time, following the recommended gas stipend. The Istanbul hard fork pushes their costs of receiving ETH via send() or transfer() to 2359 gas, or a mere 59 gas above the available limit.

Ethereum security members were alerted of this impact ahead of the final decision to accept EIP-1884 into the hard fork.