Platform: Code4rena
Start Date: 07/10/2022
End Date: 12/10/2022
Period: 5 days
Status: Completed
Pot Size: $50,000 USDC
Participants: 62
Reporter: liveactionllama
Judge: 0xean
Id: 169
League: ETH
Trust | 1/62 | $25,057.78 | 3 | 0 | 0 | 2 | 2 | - | 0 | 0 |
ladboy233 | 2/62 | $5,676.97 | 2 | 0 | 0 | 1 | 0 | - | 0 | 0 |
csanuragjain | 3/62 | $4,328.22 | 1 | 0 | 0 | 1 | 0 | 0 | 0 | 0 |
d3e4 | 4/62 | $2,278.81 | 1 | 0 | 0 | 1 | 0 | 0 | 0 | 0 |
cccz | 5/62 | $1,803.21 | 2 | 0 | 0 | 1 | 0 | - | 0 | 0 |
catchup | 6/62 | $1,773.72 | 2 | 0 | 0 | 1 | 0 | 0 | - | 0 |
joestakey | 7/62 | $1,752.93 | 1 | 0 | 0 | 1 | 0 | 0 | 0 | 0 |
0xSmartContract | 8/62 | $1,054.18 | 2 | 0 | 0 | 0 | 0 | - | - | 0 |
IllIllI | 9/62 | $954.97 | 2 | 0 | 0 | 0 | 0 | - | - | 0 |
delfin454000 | 10/62 | $622.91 | 2 | 0 | 0 | 0 | 0 | - | - | 0 |
Auditor per page
IMPORTANT NOTE: Prior to receiving payment from this contest you MUST become a Certified Warden (successfully complete KYC and pass screening for OFAC sanctions). You do not have to complete this process before competing or submitting bugs.
The Graph is a decentralized protocol for indexing and querying data from blockchains, starting with Ethereum. It makes it possible to query data that is difficult to query directly.
The Graph Network consists of Indexers, Curators and Delegators that provide services to the network, and serve data to Web3 applications. Consumers use the applications and consume the data.
To ensure economic security of The Graph Network and the integrity of data being queried, participants stake and use Graph Tokens (GRT). GRT is a work token that is an ERC-20 on the Ethereum blockchain, used to allocate resources in the network. Active Indexers, Curators and Delegators can provide services and earn income from the network, proportional to the amount of work they perform and their GRT stake.
To reduce gas costs and sustainably scale The Graph Network, there are active proposals to move the contracts to the Arbitrum Layer 2 blockchain. To mitigate risk, the proposed approach is to initially run the protocol in L1 in parallel with the protocol in L2. During a first stage, the L2 protocol would not distribute any Indexer rewards, and therefore not have any token issuance in L2.
The scope for this contest is the first step of this migration, that consists in a custom token bridge to send GRT between Ethereum and Arbitrum.
The changes that make up the scope for this contest are described in the following proposal: GIP-0031 (also in this Forum discussion). We recommend that Wardens read this spec to understand the scope and the rationale for the design of these contracts. This corresponds to PR #699 in the graphprotocol/contracts repo.
The contracts that are in scope for this audit were added with this spec in mind, and any deviation between the implementation and this spec can be considered a valid submission.
We’re mostly looking to validate the security of the token bridge: that tokens in the BridgeEscrow are safe, that transferring between L1 and L2 is safe (and works as expected), and that an attacker cannot steal funds from the bridge or mint tokens at will.
We’re assuming that the Arbitrum rollup and bridge contracts behave as expected, though we do want to minimize the impact of any breach to Arbitrum admin keys. Therefore, any submissions that can show the bridge opening up an unnecessary attack surface in a scenario where Arbitrum is compromised can be considered valid as well. The same applies to the Arbitrum GatewayRouter: we assume it behaves correctly, but any submissions showing our integration with it is incorrect or opening up an unnecessary attack surface will be valid as well.
The current bridge design assumes no tokens are minted in L2 (other than through the bridge), so any submissions showing how an attacker can mint tokens in L2 (without compromising the governor account) would be particularly valuable.
The bridge includes the ability to trigger callbacks in L2 when sending tokens from a whitelisted set of addresses. This will be useful for later stages of the migration plan. We encourage submissions that show ways to bypass the whitelist or otherwise exploit this feature, but considering that governance would only add a trusted L1 contract (e.g. GNS, Curation or Staking) to this whitelist. We still want to make this robust against a whitelisted sender being compromised, so submissions showing how a compromised/malicious whitelisted sender or receiver causes damage to the bridge or other protocol contracts would be valid as well.
A previous version of this code was audited (together with 3 other PRs) by OpenZeppelin on July 2022. A report for this audit, which also includes the 3 other PRs that are out of scope, is available here; the list of issues from that report that are relevant to this scope is available in this document. Any reports that are duplicates of issues mentioned there will be considered invalid, unless:
# Install dependencies yarn # Compile the contracts yarn build # Run unit tests yarn test
Additional end to end tests can be run as described in TESTING.md.
Tests can be run for specific files as well, in particular, this will run the tests that are relevant for the contracts in scope:
yarn test test/gateway/bridgeEscrow.test.ts yarn test test/gateway/l1GraphTokenGateway.test.ts yarn test test/l2/l2GraphToken.test.ts yarn test test/l2/l2GraphTokenGateway.test.ts
To get a gas report, you can run:
yarn test:gas
This will produce a report in reports/gas-report.log.
Note that this requires having curl installed as we use it to check if the local EVM node is ready.
This command also accepts specific test files, e.g.
yarn test:gas test/gateway/l1GraphTokenGateway.test.ts
This will clone, install, and build the project, then run tests with gas reporting and output to reports/gas-report.log:
rm -Rf 2022-10-thegraph || true && git clone https://github.com/code-423n4/2022-10-thegraph.git && cd 2022-10-thegraph && nvm install 16.0 && yarn && yarn build && yarn test:gas
The contracts in scope that will be deployed are the following:
Each of these will be deployed behind a proxy, so we're including the proxy and upgrade logic in the scope, as well as the dependencies for the contracts in scope that relate to governance and the pausing mechanism.
The files in contracts/arbitrum/**.sol are copied from the Arbitrum repo so not in scope; the only change from the original was the solidity version.
All other files in the repo are not in scope.