Luganodes security record

The following is noted in both EIP-7002 and EIP-7251: > Calls to the system contract require a fee payment defined by the current contract state. Overpaid fees are not returned to the caller. It is not generally possible to compute the exact required fee amount ahead of time. When adding a \[withdrawal/consolidation\] request from a contract, the contract can perform a read operation to check for the current fee and then pay exactly the required amount. Currently, there are no checks in place to determine whether excess fees are about to be sent to the system contracts. Therefore, using the functions in `Pectra`, it is possible to send fees in excess of the required amount with no possibility of recovery.

The documentation states: > Transaction Completion: The transaction finishes execution. The EOA's code delegation to **Pectra.sol** remains in place. Once delegation persists, the externally-owned account effectively becomes a contract account, yet the contract lacks: * `receive()` — plain ETH transfers (`transfer` / `send`) revert. * `fallback()` — calls with arbitrary calldata revert instead of no-oping as on a normal EOA. * `onERC721Received` / `onERC1155Received` — safe token transfers fail. This breaks long-established EOA behaviour and may surprise users, dApps, or tooling that expect the address to accept dust ETH or safe-transferred NFTs.

In `batchELExit()`, although the length of the amount of an exit is validated, the exact value is not validated. However, validating this value may be worthwhile. Suppose the value of the amount is `0`. In the consensus layer node logic, this will trigger a full exit. Although this may be desired, if `0` is entered not knowing this, then the requestor may unexpectedly exit their entire balance from the validator. Now consider that the maximum amount of Ether a validator can hold in Pectra is `2048`. However, it is possible to submit a withdrawal request where the amount is greater than `2048` Ether. In such a case, if the validator has compounding withdrawal credentials, then as much Ether as possible will be withdrawn while maintaining the validator's minimum activation balance and pending balance to withdraw. In either case, accidental inputs may lead to unexpected outcomes.