Audit Comp | Jito Restaking

Proof of Concept (PoC) Requirements

A PoC, demonstrating the bug's impact, is required for this program and has to comply with the Immunefi PoC Guidelines and Rules.

Whitehat Educational Resources & Technical Info

The documentation for the restaking programs is located at https://docs.restaking.jito.network/.

Is this an upgrade of an existing system? If so, which? And what are the main differences?

This will be the maiden deployment of Jito’s restaking protocol. This is a new codebase, not a fork. Slashing will not be enabled at launch, as an initial guardrail, but the protocol otherwise resembles existing restaking protocols.

Where do you suspect there may be bugs?

As previously mentioned, slashing will not be implemented at launch. However, any bug which might allow an operator to avoid or frontrun being slashed would be an interesting insight. Rounding issues around vault shares would be interesting. There might be bugs around fees and rewards, allowing an attacker to either avoid fees or collect a larger share of rewards. There is some complexity around validating, tracking, and updating vault state, so any issues involving out-of-date/out-of-sync vault state would be interesting.

What ERC20 / ERC721 / ERC777 / ERC1155 token standards are supported? Which are not?

The Vault and Restaking programs support the SPL Token and SPL Token 2022 standards

What emergency actions may you want to use as a reason to invalidate or downgrade an otherwise valid bug report?

None that are relevant. There is an admin role which can be used to pause vault accounts. However, we’re interested in any impact which could deny or impair functionality, or lead to loss of funds or adverse outcomes for either the protocol or its users;These would still be valid findings even if they can be partially mitigated by pausing+migrating to a new vault.

What addresses would you consider any bug report requiring their involvement be out of scope, even if they exceed the privileges attributed to them?

We’re still interested in impacts involving permissioned roles in the protocol (malicious NCN operators, malicious slashers, malicious delegates). However, any report involving compromise of the private keys of any Jito Foundation-associated account would be out of scope.

What external dependencies are there?

External dependencies are pretty minimal. The programs depend on the Solana Program Library, and the SPL ATA, SPL Token, and SPL Token 2022 programs.

Where might whitehats confuse out-of-scope code to be in-scope?

All the client code is in the same git repository as the assets-in-scope, but it’s not particularly interesting. The code for the frontend clients is generated using kinobi, and the IDLs for the client are generated with shank. Since it is all auto-generated and simply represents an interface for interacting with the underlying protocol, it is not included in the contest scope.

Are there any unusual points about your protocol that may confuse whitehats?

Slashing is not implemented at present, as the protocol is in its initial phase.

What is the test suite setup information?

It is recommended to use cargo nextest. The instructions for running tests can be found here: https://github.com/jito-foundation/restaking/blob/master/README.md

Public Disclosure of Known Issues

Bug reports covering previously-discovered bugs (listed below) are not eligible for a reward within this program. This includes known issues that the project is aware of but has consciously decided not to “fix”, necessary code changes, or any implemented operational mitigating procedures that can lessen potential risk.

• VRTs are tokenized shares of a vault’s underlying deposits. Vault deposits are calculated by getting the total amount of assets held by the vault token account. An attacker could inflate the exchange rate of shares to underlying assets by “donating” directly to a vault. If the attacker is the first depositor to a vault, they could deprive subsequent depositors of shares relative to their amount of deposited assets. This can be mitigated by requiring or suggesting that integrators mint some small amount of shares in the same transaction in which the vault is initialized. Relevant PRs: https://github.com/jito-foundation/restaking/pull/150
• The amount of fees charged can change between the time when a withdrawal ticket is enqueued and when the withdrawal ticket is burned. Withdrawals should account for the difference. The issue hasn’t been resolved yet but a mitigation is in the works.
• In the case where an operator’s state has been updated but a vault update epoch was missed or close_vault_update_state_tracker has not been called, the vault should be updated to reflect the operator’s new state. Otherwise, the amount reserved for cooldown can be too large. Relevant PRs: https://github.com/jito-foundation/restaking/pull/163/

Previous Audits

Jito’s completed audit reports can be found at https://jito-foundation.gitbook.io/mev/resources/audits. Any unfixed vulnerabilities mentioned in these reports are not eligible for a reward.