# MIP-30 Add Bot Wallet Automation For Claims And Redelegations

**URL:** https://agora.multiversx.com/t/mip-30-add-bot-wallet-automation-for-claims-and-redelegations/567
**Category:** MIPs
**Created:** [November 4, 2025, 9:00pm UTC](https://agora.multiversx.com/t/mip-30-add-bot-wallet-automation-for-claims-and-redelegations/567 "2025-11-04T21:00:16Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![mihaieremia](https://dub1.discourse-cdn.com/flex005/user_avatar/agora.multiversx.com/mihaieremia/32/130_2.png) [@mihaieremia](https://agora.multiversx.com/u/mihaieremia)
#### Post date: [November 4, 2025, 9:00pm UTC](https://agora.multiversx.com/t/mip-30-add-bot-wallet-automation-for-claims-and-redelegations/567/1 "2025-11-04T21:00:16Z")

</div>

## Summary

Let a delegator keep their cold wallet offline and authorize a “bot wallet” to handle all the routine staking chores—claiming rewards or redelegating across every delegation contract they use. The Delegation Manager stores a single owner→bot mapping and exposes two new batch endpoints:

- claimMultiOf(owner, contract1, contract2, …): Call claimRewardsOf(owner) on each listed delegation contract in one transaction.
- reDelegateMultiOf(owner, contract1, contract2, …): Same, but for redelegating rewards.

Each delegation contract also gains direct single-call endpoints:

- claimRewardsOf(owner): Transfer rewards to the caller if and only if the caller is the owner or the owner’s registered bot.
- reDelegateRewardsOf(owner): Redelegate the owner’s rewards while the caller only needs bot authorization.

Owners register or revoke their bot through the manager and every change is logged:

- setDelegatedWallet(bot)
- removeDelegatedWallet()

The entire feature is gated by a new DelegationOnBehalfFlag, so we can deploy safely then enable when ready.

## Why this is needed

Large stakeholders (validators running dozens of pools, custodians, DAOs, multisigs, Ledger users) need to claim or compound rewards daily. Today they must either repeatedly plug in the cold wallet that controls the node or funds, or hand over the keys to a hot wallet or third-party service. Neither is acceptable for accounts that control significant value.

By introducing delegated bot wallets:

- Cold storage stays cold: the owner only signs once to register a bot and again to revoke it. Day-to-day automation happens with a hot wallet that has no authority beyond running the public endpoints.
- Services can scale: a custody provider or DAO can run a single bot that serves many owners, with full audit logs and revocation.
- Users keep control: the manager and each delegation contract enforce authorization on every call. If an owner revokes or rotates the bot, all delegated operations instantly stop.

## Security and behavior

- Authorization is checked twice: once in the manager before dispatch, and again in each delegation contract. Unauthorized bots cannot succeed even if they invoke contracts directly.
- Calls are atomic: if any provider rejects the request or the VM runs out of gas, the entire batch reverts—no partial state.
- Backwards-compatible: existing claimMulti / reDelegateMulti flows stay under their original flag; the new functionality only activates when DelegationOnBehalfFlag is set.
- One bot, many owners: a single bot can be authorized by multiple owners, and each owner can use the same bot across all current and future delegation contracts.

## Endpoints Overview

Manager:

- setDelegatedWallet(bot)
- removeDelegatedWallet()
- claimMultiOf(owner, contract1, contract2, …)
- reDelegateMultiOf(owner, contract1, contract2, …)

Delegation contracts:

- claimRewardsOf(owner)
- reDelegateRewardsOf(owner)

> <https://github.com/multiversx/mx-chain-go/pull/7392>
>
> \## Reasoning behind the pull request
> 
> Introduce delegation “bot wallets” manag…ed by the Delegation Manager so large stakeholders can automate reward claims or redelegations without ever touching cold keys. Each owner registers a single bot address which can then call claimRewardsOf / reDelegateRewardsOf (directly or via new claimMultiOf / reDelegateMultiOf) across all of that owner’s delegation contracts. Registrations emit logs, are revocable at any time, and the feature activates only once the DelegationOnBehalfFlag is enabled.
> 
> \## Proposed changes
> 
> Owner→bot mapping lives in the Delegation Manager via setDelegatedWallet(bot) and removeDelegatedWallet(). Events are emitted for auditing.
> Batch endpoints claimMultiOf(owner, contract…) / reDelegateMultiOf(owner, contract…) validate the caller against the stored bot then fan out to each delegation contract with ExecuteOnDestContext.
> Delegation contracts expose claimRewardsOf(owner) and reDelegateRewardsOf(owner); they re-check the mapping so direct single-contract calls remain available.
> 
> \## Testing procedure
> \- 
> \- 
> \- 
> 
> \## Pre-requisites
> 
> Based on the \[Contributing Guidelines\](https://github.com/multiversx/mx-chain-go/blob/master/.github/CONTRIBUTING.md#branches-management) the PR author and the reviewers must check the following requirements are met:
> \- was the PR targeted to the correct branch?
> \- if this is a larger feature that probably needs more than one PR, is there a \`feat\` branch created?
> \- if this is a \`feat\` branch merging, do all satellite projects have a proper tag inside \`go.mod\`?

---

<div class="post-metadata">

### Author: ![adrian](https://avatars.discourse-cdn.com/v4/letter/a/82dd89/32.png) [@adrian](https://agora.multiversx.com/u/adrian)
#### Post date: [November 5, 2025, 10:24am UTC](https://agora.multiversx.com/t/mip-30-add-bot-wallet-automation-for-claims-and-redelegations/567/2 "2025-11-05T10:24:36Z")

</div>

I like the idea, will take a closer look on the PR once we are ready with Supernova.

---

<div class="post-metadata">

### Author: ![janniksam](https://avatars.discourse-cdn.com/v4/letter/j/edb3f5/32.png) [@janniksam](https://agora.multiversx.com/u/janniksam)
#### Post date: [November 5, 2025, 3:05pm UTC](https://agora.multiversx.com/t/mip-30-add-bot-wallet-automation-for-claims-and-redelegations/567/3 "2025-11-05T15:05:03Z")

</div>

Great write-up. Thats exactly what I wanted my suggestion ~1.5 years ago.

> [@Give other wallets / scs the permission to claim your staking rewards](https://agora.multiversx.com/t/give-other-wallets-scs-the-permission-to-claim-your-staking-rewards/355/1):
>
> Give other wallets / scs the permission to claim your staking rewards. It has been asked before, its also desired by me, so here I am with a proposal. My desired scenario: Cold wallet where you keep all your staked EGLD. Set another wallet to be able to claim your rewards. Ideally also smart contracts. Put your cold wallet into a drawer and forget about it for a long time Claim the regards regularly with your other wallet, and then use it (for example to charge your XCard or whatever you wan…

Question:

The way I understand it, it shouldn’t be called ”bot”, because it doesn’t necessarily have to be a automated system, right? It’s more like a “proxy wallet / address”.

---

<div class="post-metadata">

### Author: ![mihaieremia](https://dub1.discourse-cdn.com/flex005/user_avatar/agora.multiversx.com/mihaieremia/32/130_2.png) [@mihaieremia](https://agora.multiversx.com/u/mihaieremia)
#### Post date: [November 5, 2025, 3:58pm UTC](https://agora.multiversx.com/t/mip-30-add-bot-wallet-automation-for-claims-and-redelegations/567/4 "2025-11-05T15:58:34Z")

</div>

Yeah by BOT i wanted to outline the fact that the specific erd wallet delegated can be automated by a script, but in the same time it can be another SC as delegated wallet
