Skip to content

chore: bump mainnet for rewards v2 #362

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 0 additions & 3 deletions .gitmodules
Original file line number Diff line number Diff line change
Expand Up @@ -5,9 +5,6 @@
path = lib/eigenlayer-contracts
url = https://github.com/Layr-labs/eigenlayer-contracts
branch = dev
[submodule "lib/ds-test"]
path = lib/ds-test
url = https://github.com/dapphub/ds-test
[submodule "lib/openzeppelin-contracts"]
path = lib/openzeppelin-contracts
url = https://github.com/Openzeppelin/openzeppelin-contracts
Expand Down
Binary file added audits/Rewards v2 - SigmaPrime - Dec 2024.pdf
Binary file not shown.
4 changes: 2 additions & 2 deletions docs/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@ EigenLayer AVSs ("actively validated services") are protocols that make use of E
**Currently, each AVS needs to implement one thing on-chain:** registration/deregistration conditions that define how an Operator registers for/deregisters from the AVS. This repo provides building blocks to support these functions.

*Eventually,* the core contracts and this repo will be extended to cover other conditions, including:
* payment conditions that define how an Operator is paid for the services it provides
* reward conditions that define how an Operator is rewarded for the services it provides
* slashing conditions that define "malicious behavior" in the context of the AVS, and the punishments for this behavior

*... however, the design for these conditions is still in progress.*
Expand Down Expand Up @@ -102,7 +102,7 @@ The main thing that links an AVS to the EigenLayer core contracts is that when E

These methods ensure that the Operator registering with the AVS is also registered as an Operator in EigenLayer core. In this repo, these methods are called by the `ServiceManagerBase`.

Eventually, Operator slashing and payment for services will be part of the middleware/core relationship, but these features aren't implemented yet and their design is a work in progress.
Eventually, Operator slashing and rewards for services will be part of the middleware/core relationship, but these features aren't implemented yet and their design is a work in progress.

### System Components

Expand Down
2 changes: 1 addition & 1 deletion docs/ServiceManagerBase.md
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@
The `ServiceManagerBase` represents the AVS's address relative to EigenLayer core. When registering or deregistering an operator from an AVS, the AVS's `ServiceManagerBase` communicates this change to the core contracts, allowing the core contracts to maintain an up-to-date view on operator registration status with various AVSs.

*As of M2*:
* Currently, this contract is used by the `AVSDirectory` to keep track of operator registration and deregistration. Eventually, this relationship will be expanded to allow operators to opt in to slashing and payments for services.
* Currently, this contract is used by the `AVSDirectory` to keep track of operator registration and deregistration. Eventually, this relationship will be expanded to allow operators to opt in to slashing and rewards for services.

---

Expand Down
2 changes: 1 addition & 1 deletion docs/experimental/AVS-Guide.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ This document aims to describe and summarize how actively validated services (AV
- enabling operators to continuously update their commitments to middlewares, and
- enabling AVS to freeze operators for the purpose of slashing (the corresponding unfreeze actions are determined by the veto committee).

We are currently in the process of implementing the API for payment flow from AVSs to operators in EigenLayer. Details of this API will be added to this document in the near future.
We are currently in the process of implementing the API for rewards flow from AVSs to operators in EigenLayer. Details of this API will be added to this document in the near future.

The following figure summarizes scope of this document:
![Doc Outline](../images/middleware_outline_doc.png)
Expand Down
1 change: 1 addition & 0 deletions foundry.toml
Original file line number Diff line number Diff line change
Expand Up @@ -3,6 +3,7 @@ src = "src"
out = "out"
libs = ["lib"]
fs_permissions = [{ access = "read-write", path = "./" }]
gas_limit = 5000000000

ffi = true
no-match-contract = "FFI"
Expand Down
1 change: 0 additions & 1 deletion lib/ds-test
Submodule ds-test deleted from e28215
2 changes: 1 addition & 1 deletion lib/eigenlayer-contracts
12 changes: 8 additions & 4 deletions src/BLSApkRegistry.sol
Original file line number Diff line number Diff line change
Expand Up @@ -12,10 +12,7 @@ contract BLSApkRegistry is BLSApkRegistryStorage {

/// @notice when applied to a function, only allows the RegistryCoordinator to call it
modifier onlyRegistryCoordinator() {
require(
msg.sender == address(registryCoordinator),
"BLSApkRegistry.onlyRegistryCoordinator: caller is not the registry coordinator"
);
_checkRegistryCoordinator();
_;
}

Expand Down Expand Up @@ -281,4 +278,11 @@ contract BLSApkRegistry is BLSApkRegistryStorage {
function getOperatorId(address operator) public view returns (bytes32) {
return operatorToPubkeyHash[operator];
}

function _checkRegistryCoordinator() internal view {
require(
msg.sender == address(registryCoordinator),
"BLSApkRegistry.onlyRegistryCoordinator: caller is not the registry coordinator"
);
}
}
Loading
Loading