From 9fd5ebfdd9febff8ab969b7ff238f3e59fc5a801 Mon Sep 17 00:00:00 2001 From: Jean-Daniel Bussy Date: Thu, 3 Oct 2024 12:31:52 +0400 Subject: [PATCH] Update introducing-obol-splits.mdx --- docs/sc/introducing-obol-splits.mdx | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/sc/introducing-obol-splits.mdx b/docs/sc/introducing-obol-splits.mdx index 3708abee2..901d59c8e 100644 --- a/docs/sc/introducing-obol-splits.mdx +++ b/docs/sc/introducing-obol-splits.mdx @@ -13,7 +13,7 @@ Obol develops and maintains a suite of smart contracts for use with Distributed Two key goals of validator reward management are: -1. To be able to differentiate reward ether from principal ether such that node operators can be paid a percentage the _reward_ they accrue for the principal provider rather than a percentage of _principal+reward_. +1. To be able to differentiate reward ether from principal ether such that node operators can be paid a percentage of the _reward_ they accrue for the principal provider rather than a percentage of _principal+reward_. 2. To be able to withdraw the rewards in an ongoing manner without exiting the validator. Without access to the consensus layer state in the EVM to check a validator's status or balance, and due to the incoming ether being from an irregular state transition, neither of these requirements are easily satisfiable. @@ -45,11 +45,11 @@ An Optimistic Withdrawal Recipient [contract](https://github.com/ObolNetwork/obo - A _reward_ address: The address where the accruing reward ether is transferred to. - The amount of ether that makes up the principal. -This contract **assumes that any ether that has appeared in it's address since it was last able to do balance accounting is skimming reward from an ongoing validator** (or number of validators) unless the change is > 16 ether. This means balance skimming is immediately claimable as reward, while an inflow of e.g. 31 ether is tracked as a return of principal (despite being slashed in this example). +This contract **assumes that any ether that has appeared in its address since it was last able to do balance accounting is skimming reward from an ongoing validator** (or number of validators) unless the change is > 16 ether. This means balance skimming is immediately claimable as reward, while an inflow of e.g. 31 ether is tracked as a return of principal (despite being slashed in this example). :::danger -Worst-case mass slashings can theoretically exceed 16 ether, if this were to occur, the returned principal would be misclassified as a reward, and distributed to the wrong address. This risk is the drawback that makes this contract variant 'optimistic'. If you intend to use this contract type, **it is important you understand and accept this risk**, however minute. +Worst-case mass slashings can theoretically exceed 16 ether, if this were to occur, the returned principal would be misclassified as a reward, and distributed to the wrong address. This risk is the drawback that makes this contract variant 'optimistic'. If you intend to use this contract type, **it is important you fully understand and accept this risk**. The alternative is to use an splits.org [waterfall contract](https://docs.splits.org/core/waterfall), which won't allow the claiming of rewards until all principal ether has been returned, meaning validators need to be exited for operators to claim their CL rewards. @@ -97,4 +97,4 @@ The Immutable Split Controller [factory contract](https://github.com/ObolNetwork | Mainnet | [0x49e7cA187F1E94d9A0d1DFBd6CCCd69Ca17F56a4](https://etherscan.io/address/0x49e7cA187F1E94d9A0d1DFBd6CCCd69Ca17F56a4)| | Goerli | [0x64a2c4A50B1f46c3e2bF753CFe270ceB18b5e18f](https://goerli.etherscan.io/address/0x64a2c4A50B1f46c3e2bF753CFe270ceB18b5e18f) | | Holesky | | -| Sepolia | | \ No newline at end of file +| Sepolia | |