Skip to content

Commit

Permalink
chore: merge dev and bump mainnet rewards v2
Browse files Browse the repository at this point in the history
  • Loading branch information
stevennevins committed Jan 21, 2025
1 parent 512ce73 commit 79baf27
Show file tree
Hide file tree
Showing 63 changed files with 6,057 additions and 1,393 deletions.
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
File renamed without changes.
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

0 comments on commit 79baf27

Please sign in to comment.