Recall audit details

• Total Prize Pool: $100,000 in USDC
  • HM awards: $88,000 in USDC
  • QA awards: $3,300 in USDC
  • Judge awards: $5,000 in USDC
  • Validator awards: $3.200 in USDC
  • Scout awards: $500 in USDC
• Read our guidelines for more details
• Starts February 19, 2025 20:00 UTC
• Ends March 19, 2025 20:00 UTC

Note re: risk level upgrades/downgrades

Two important notes about judging phase risk adjustments:

• High- or Medium-risk submissions downgraded to Low-risk (QA) will be ineligible for awards.
• Upgrading a Low-risk finding from a QA report to a Medium- or High-risk finding is not supported.

As such, wardens are encouraged to select the appropriate risk level carefully during the submission phase.

Automated Findings / Publicly Known Issues

The 4naly3er report can be found here.

Note for C4 wardens: Anything included in this Automated Findings / Publicly Known Issues section is considered a publicly known issue and is ineligible for awards.

Light Audit

• Any issues outlined in the light audit are considered out-of-scope for the purposes of this contest.

IPC Known Issues

• Any issues that are known in the original IPC repository are considered to be known issues in the Recall implementation and are thus ineligible for a reward

TODO / FIXME Comments

• Any issue that arises from a documented TODO or FIXME comment is considered a known issue and is therefore ineligible for a reward

Gateway

• Gateway manages funds for all registered subnets (cf. “omnibus account”). Funds sit in the subnet actor until the subnet is bootstrapped, at which point the collateral and supply is transferred to the gateway. Gateway will manage the fund and disperse to the subnet upon subnet’s request. This design will cause some security threats as one subnet can potentially impact other subnets. Please check the Problems section of the refactoring proposal. The mitigation under the current design is for gateways to be single-tenant, i.e. to restrict who can create subnets under it, so all risk is contained under a single owner. In the future, the design will segregate liquidity per subnet into their dedicated actors/contracts.

Topdown Checkpointing Issues

Reliability Issues

• Entirely reliant on a single RPC endpoint to query and observe the parent chain. Blind trust on a single RPC node for parent network events/states; possibility of attacks. RPCs can malfunction and serve missing or incorrect data. (For the Filecoin L1: Lotus event indices are optional, and Lotus does not reason about data availability. So it happily returns empty events for an unindexed epoch, instead of an error, misleading the caller to think there were truly no events. Ideally would use trustless light clients, but the Filecoin L1 doesn’t support them yet.)

Availability and Catch-up Challenges

• Dependent on RPC data availability, rendering catch-ups problematic. If the subnet has fallen behind its parent and needs to perform a long-range catch-up, queries may exceed the lookback window of the RPC endpoint (16-24h for popular hosted Filecoin L1 RPC endpoints). Furthermore, queries may slow down as we query historical portions of the parent chain, the deeper the queries go.
• Imported parent data is transient and does not survive restarts. We engage in unnecessary work upon restarts to reload data that IPC had already acquired (and was immutable, to begin with). In case of long-range catch-ups, the relevant chain history may be unfetchable as a result of it.

Condition and Liveness Problems

• Race conditions during start, potentially deriving in network-wide liveness problems. If Fendermint stops or crashes unexpectedly while processing proposed topdown finality, and we are forced to restart, we will need to fill up our cache before we can validate proposals. A problematic edge case occurs if we had accepted a proposal containing parent finality or prevoted on it just before crashing, as we will enter a crash loop during WAL replay because we will now reject a previously accepted proposal, and this is perceived by CometBFT as a fatal consensus violation from the app. To break this cycle, we will need to clear the local CometBFT state and possibly the WAL.

Consensus and Side Effect Inconsistencies

• Topdown voting covers observed height and block hash, but not imported side effects. Due to the Dependency Issues, various nodes may see different side effects (especially if using different RPCs), causing rejections at consensus time, resulting in chain liveness problems, e.g. A/B split brain scenario leading to cohort A rejecting cohort B’s proposals, and vice versa.

Tolerance Issues

• Lack of fault tolerance preventing self-healing and automatic failure recovery. Topdown components do not backoff nor reset their state machine after repeated failures, causing us to enter infinite loops when things get stuck in a bad state, and requiring manual intervention to recover. To remedy this, we could gracefully degrade and back off, skip proposing parent finality, and optionally reset some state (circuit breaker pattern), if we repeatedly fail to commit top-down finality during a particular height.

Brittle Vote Broadcast and Tallying Mechanisms

• Nodes may restart anytime, wiping their state (Condition and Liveness Problems) and appearing to others as if they’re going back when they gossip, which is not tolerated by peers. Similarly, nodes only gossip new parent views but never re-broadcast older pending ones, preventing restarted nodes from learning about intermediate states they could make partial progress towards.

Casuality Awareness

• No notion of a causality. Even though voting for A in a chain A’’←A’←A implicitly votes for A’’, topdown finality does not leverage this fact at all.

Query Patterns

• Inefficient parent RPC query patterns, querying individual blocks and events instead of performing range queries when catching up.
• ProcessProposal is non-deterministic, as validators with different views of parent finality (or data availability issues) will reject benevolently.

Validators

• Known bug for mapping subnet genesis validators to the initial Fendermint power table. There is an issue describing the cause and and a hot fix.
• Bottom-up checkpoints are injected in the child ledger during block proposal (no gas required), and are subsequently signed by a quorum via transactions in the child ledger (requires gas). This means that validators need to monitor their account balance to be able to expend gas for this system operation. While this is not a bug, it is an inconvenience. We are fixing this by making gas charges conditional (exempted in valid system as well.

Subnet Interactions

• Individual subnet stalls cause progress stalls for all child subnets, which opens DoS vectors at the weakest parent.
• A subnet stall causes funds locked on the parent and/or root chains to become inaccessible, but can be recovered through a contract upgrade.
• When a network does not run a relayer and is unable to confirm its changes to the parent, the parent cannot confirm the validator set changes from the subnet, effectively rendering them ineffective.
• A subnet in the parent needs to be activated either by setting federated power or assigning minimum collateral; otherwise, it cannot be used yet. This is not a bug, but it can be confusing.

Message Relays

• Setting a non-standard IPC address in a cross-message might lead to a panic during message parsing in Fendermint.
• Known open issues regarding transaction acceptance, gossip, and inclusion itself, even in the presence of invalid gas parameters. Patch is in progress, but is blocked on some deeper refactors needed.

Overview

Recall leverages the IPC (InterPlanetary Consensus) framework to create an L2 on Filecoin. This is facilitated by two main components: (1) a set of smart contracts deployed to Filecoin, and (2) a FVM (Filecoin Virtual Machine) based blockchain built using CometBFT. These type of L2s are referred to as ‘subnets’, and will eventually allow us to orchestrate multiple blockchains hierarchically and in parallel, but for our mainnet v1 we will only operate one such subnet. This audit will be primarily focused on the IPC framework implemented in Rust. A general description of the IPC framework can be found here.

Links

• Previous audits: Light Audit
• Documentation: https://flat-agustinia-3f3.notion.site/Audit-documentation-Code4rena-17ddfc9427de80a7849fe2144b56dffb?pvs=4
• Website: https://recall.network/
• X/Twitter: https://x.com/recallnet

---

Scope

Files in scope

Files out of scope

Any file that is not explicitly included in the aforementioned list is to be considered out-of-scope.

Scoping Q & A

General questions

ERC20 token behaviors in scope

External integrations (e.g., Uniswap) behavior in scope:

EIP compliance checklist

Although some contracts do inherit and implement certain EIP functionality, none of the contracts in scope are expected to be strictly compliant with any EIP standard.

Additional context

Main Invariants

Funds

• The total supply of a subnet must match the total funds locked for that specific subnet in the gateway
• Funds bridged via the gateway for a particular address to a subnet should result in the same amount being credited for that address within the subnet

Consensus

• The current membership in the child subnet gateway must be the same to the validators in CometBFT, i.e. public key and power (power scale applied).
• The active validators in the parent subnet must have the same public key, power (with power scale applied) to the validators in the child subnet after bottom up checkpoint is submitted to the parent subnet.

Topdown Finality

• The topdown finality block hash in the child subnet must be equal to the parent’s block hash for the same height.
• The nonces in cross network messages to be applied in topdown finality must be sequential and no gaps.
• The configuration number for validator change request must be sequential and no gaps.
• The child subnet’s appliedTopDownNonce must be equal the cross network message’s localNonce.
• The topdown finality’s block height must be larger than that of the previous committed topdown finality’s block height.
• The cross network messages and validator changes to be committed from the parent finality must be the same compared to the parent subnet.

Bottom-Up Checkpoint

• The block height in the checkpoint submitted must be more than the last submitted bottom up checkpoint height.
• The block height in the checkpoint submitted must be less than the last submitted bottom up checkpoint height + bottom up checkpoint period.
• The configurationNumber in the bottom up checkpoint to be submitted must be within the startConfigurationNumber(inclusive) and nextConfigurationNumber (exclusive).
• The parent subnet’s appliedBottomUpNonce must be equal the cross network message’s localNonce.
• The cross network messages to be committed from the bottom up checkpoint must be the same compared to the child subnet.

Cross-Chain Messages

• Cross xnet messages can only by send from contract to contract that implements specific interface

Attack ideas (where to focus for bugs)

Repo: ipc/contracts

This repo contains the general IPC related solidity code. These contracts are provided by the IPC framework

GatewayDiamond.sol

Implementation of the IPC GatewayActor within the Diamond pattern.

SubnetActorDiamond.sol

Reference implementation of an IPC SubnetActor within the Diamond pattern.

SubnetRegistry.sol

Registry contract for seamlessly deploying subnet actors.

This is the entrypoint to cross network messaging: https://github.com/consensus-shipyard/ipc/blob/main/contracts/contracts/gateway/GatewayMessengerFacet.sol. The documentation can be found: https://github.com/consensus-shipyard/ipc/blob/main/docs/fendermint/general_cross_messages.md.

IPC blockchain

A general description of the IPC framework can be found here. This section will outline the most important components, what they do, and their priority in the audit.

Fendermint

Fendermint is an implementation of IPC as a CometBFT ABCI++ application written in Rust. It leverages the FVM as it’s virtual machine, but has custom logic for verifying transactions. The main differentiator of IPC compared to other blockchain frameworks is the concept of hierarchical consensus, which enables an hierarchy of blockchains to be spun up and down dynamically. However, when Recall launches there will only be one level, e.g. subnet.

Key components

ipc/fendermint/vm/topdown

Part of the hierarchical network topology, e.g. we attach to Filecoin L1 through the gateway contracts. Please find the high level overview here: https://github.com/consensus-shipyard/ipc/blob/main/specs/topdown.md.

For bottom up checkpointing, please find the documentation here: https://github.com/consensus-shipyard/ipc/blob/main/specs/bottom-up-interaction.md.

ipc/fendermint/vm/interpreter

How checkpoints are managed and how to make sense of IPC messages

ipc/fendermint/actors

Contains FVM actors that ship by default in all new deployments of an IPC subnet

IPC - ipc/ipc

This is the main CLI used to interact with an IPC subnet, providing basic wallet functionality as well as interaction with the parent network. It also includes the provider, which manages the sender's wallet and is responsible for calling contracts or submitting transactions on the parent or subnet.

All trusted roles in the protocol

Describe any novel or unique curve logic or mathematical models implemented in the contracts:

N/A

Running tests

Build dependencies are identical to the Consensus Shipyard IPC implementation.

Building

# make sure that rust has the wasm32 target
rustup target add wasm32-unknown-unknown

# add your user to the docker group
sudo usermod -aG docker $USER && newgrp docker

# build
make

# building will generate the following binaries
./target/release/ipc-cli --version
./target/release/fendermint --version

To run tests

make test

To run code coverage (Solidity)

cd contracts/
make coverage

Coverage Table (Solidity)

Miscellaneous

Employees of Recall and employees' family members are ineligible to participate in this audit.

Code4rena's rules cannot be overridden by the contents of this README. In case of doubt, please check with C4 staff.