Open gitmachtl opened 1 month ago
Perhaps the most natural place would be in build
, however that would leave build-raw
users without this protection. So I think it makes sense to add the check on transaction submit
as suggested by @gitmachtl.
EDIT: Since https://github.com/IntersectMBO/cardano-ledger/pull/4639 prevents us from using unregistered stake addresses in proposals' deposits and treasury withdrawals, we can now just implement a fail on build
.
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 120 days.
As we talked about this issue in the
CLI/API workgroup meeting #2
, i will leave a link here to the original issue raised on the ledger repo. https://github.com/IntersectMBO/cardano-ledger/issues/4605If not possible to implement it on the ledger level, we should at least try to implement a basic guard against governance action deposit losses via a wrong or retired deposit-return stake address on the cardano-cli level.
So the major two things to check would be:
The scenario that someone uses a wrong stake address as the deposit return address. Once submitted, there is no way to correct the wrong address anymore afterwards. Deposit funds would be lost. A basic check should be done at time of submit (
cardano-cli transaction submit
), that the stakeaddress used as deposit-return-address in a governance action actually is registered on chain. Thats not a total protection in case someone uses a wrong existing stakeaddress, but at least it would help to prevent mistakes a little better.Another scenario is, that someone is doing a stakeaddress deregistration while that same stakeaddress is involved in an active governance proposal. Once the proposal times out or gets enacted, the deposit fee (currently 100kAda) would be lost. So there should be a check at time of the retirement certificate submit (
cardano-cli transaction submit
), that there are no active actions running that include that same stake address as a deposit-return-address. One little drawback would be that some 3rd party player could block the deregistration of a stakeaddress by using it as the deposit-return-address in there action propsals. But than also the deposit amount would go to that stake address. So very unlikely.