> ## Documentation Index
> Fetch the complete documentation index at: https://docs.boundless.network/llms.txt
> Use this file to discover all available pages before exploring further.

# Wallet Setup

> Best practices for wallets used in Staking, Proving and ZK Mining.

This page covers some best practices when it comes to wallets used for [staking *\$ZKC*](/zkc/quick-start#how-to-stake-zkc), [ZK mining](/zkc/mining/overview) and [running a Boundless prover](/provers/quick-start).

Please note that not every prover will need to separate every wallet from each other. Every additional wallet comes with the overhead of keeping another private key safe for prover operation. This guide assumes provers have a large active *\$ZKC* stake position which they want to keep separate from daily ZK mining and Boundless prover operations.

## Overview

The following diagram illustrates the recommended mining reward workflow:

<img src="https://mintcdn.com/boundless/SgkYpsrMj9zy3PYU/images/reward_claim_flow.png?fit=max&auto=format&n=SgkYpsrMj9zy3PYU&q=85&s=ffd2e4ec52ace558370ec8dfe96fb4db" alt="Reward Claim Flow" width="2880" height="1704" data-path="images/reward_claim_flow.png" />

<Steps>
  <Step title="Stake $ZKC and receives 'Reward Power'">
    The prover stakes *\$ZKC*, this gives [reward power](https://github.com/boundless-xyz/zkc?tab=readme-ov-file#power-calculations) to the staking address. This reward power is used, each reward epoch, to calculate the total amount of staking and mining rewards for the address with the reward power. This wallet has the most active *\$ZKC* staked, and so it is recommended that this wallet be a *cold* wallet. The address that receives all rewards every two days can be a separate *hot* wallet, and this is done via delegation.
  </Step>

  <Step title="Delegates 'Reward Power' to Reward Address">
    The staking address can delegate the reward power to another address known as the *delegatee*. We recommend delegating reward power, as it allows for a hot wallet to receive rewards *and* to restake the rewards to increase the total reward power for compounding gains. Restaking directly with a cold wallet would be quite troublesome, as it would require restaking every epoch (\~2 days).

    Separating the staking wallet from the reward address also means that a maximum of a single reward epoch's rewards are lost if the reward address private key is lost or compromised. This is because the staking address can simply re-delegate rewards to a new address and [enable ZK mining](/zkc/mining/enable) with that address specified. Otherwise, without separation between the staking address and the rewards address, the prover would lose *both* the total stake position and the total reward power.
  </Step>

  <Step title="Submits Proof of Verifiable Work">
    The prover can now [run a Boundless prover](/provers/quick-start), or run proving jobs elsewhere, and [Bento](/provers/proving-stack#what-is-bento) will automatically store work proofs. For a full explanation of this process, please see the [ZK Mining Walkthrough](/zkc/mining/walkthrough).

    Before the end of the reward epoch, the prover MUST submit *at least* one aggregated work proof (please see [here](/zkc/mining/walkthrough#submit-the-aggregated-work-proof-onchain) for technical details).
  </Step>

  <Step title="Claim Staking Rewards & Mining Rewards">
    The rewards address can now [claim the staking rewards](/zkc/mining/claiming-rewards#staking-rewards) and [claim the mining rewards](/zkc/mining/claiming-rewards#mining-rewards).
  </Step>

  <Step title="Mint ZKC Rewards">
    After claiming staking + mining rewards, the *\$ZKC* rewards contract will carry out the necessary checks, and if successful, mint the rewards to the rewards address. For compounding gains, the prover can now transfer these *\$ZKC* rewards, from the rewards address to the staking address, and stake them to increase the total reward power for the rewards address.
  </Step>
</Steps>

## Recommendations

To [enable ZK mining](/zkc/mining/enable), the prover specifies the `REWARD_ADDRESS` environment variable which must be a valid Ethereum address. This address *does not* have to be the same as the *\$ZKC* staking wallet address or a <Tooltip tip="Note that mining rewards are eligible for all verifiable work, not solely work done to prove Boundless market orders. Therefore, provers not connected to the Boundless market are still eligible for $ZKC rewards, provided they are proving during the epoch and they have staked $ZKC.">Boundless prover address</Tooltip>, though a single address can be used for all three purposes. It is NOT recommended to use a single address for all three purposes; if the private key is compromised or lost, this will lead to a loss of staked *\$ZKC*, loss of *\$ZKC* rewards, and the loss of boundless prover *\$ZKC* [collateral](/zkc/collateral) balance.

### Separate Staking Wallet and Reward Wallet

<Warning>
  Please note that delegating rewards to any address will delegate all rewards to that address i.e. both staking and mining rewards will only be claimable by that delegatee address. For more information, please see the [token docs](https://github.com/boundless-xyz/zkc?tab=readme-ov-file#zkc).
</Warning>

It is recommended to separate the staking wallet from the rewards address. The rewards address will receive all *\$ZKC* staking and mining rewards and therefore, it can be seen as a *hot* wallet. Depending on the size of the prover's stake position, it may be wise to have the wallet that stakes *\$ZKC* configured as cold wallet. For this reason, it is possible to delegate rewards *from* the staking wallet *to* the rewards address wallet.

#### How to delegate rewards

<Steps>
  <Step title="Enable ZK Mining">
    Please see [Enabling ZK Mining](/zkc/mining/enable).
  </Step>

  <Step title="Stake $ZKC">
    To stake from a separate wallet, provers may additionally specify:

    ```bash theme={null}
    export ZKC_WALLET_ADDRESS="0x0000...0000"
    export PRIVATE_KEY="..."
    ```

    Provers can now follow the [staking instructions](/zkc/quick-start#how-to-stake-zkc) to stake \$ZKC from the `ZKC_WALLET_ADDRESS`.
  </Step>

  <Step title="Delegate Rewards">
    Once staked, provers can delegate rewards i.e. associate the `REWARD_ADDRESS` with `ZKC_WALLET_ADDRESS`. This is done with the following command:

    ```bash theme={null}
    boundless rewards delegate ${REWARD_ADDRESS}
    ```

    This command uses the `PRIVATE_KEY` environment variable to send a transaction onchain, therefore funds are required on `ZKC_WALLET_ADDRESS`.

    Once the rewards are delegated, the prover can start proving as normal.
  </Step>
</Steps>

### Separating Boundless Prover from Staking + Reward Wallets

Since many Boundless provers run clusters on hosted cloud providers, and because the private key must be in plaintext when starting the broker, the security of this wallet depends on your trust in the cloud provider. Therefore, for provers running large proving/ZK-mining clusters with large expected *\$ZKC* reward amounts, it is not recommended to use your Boundless proving address as the staking wallet or the rewards address. If the key is compromised, this can lead to a loss of stake position and reward power and this will require a new wallet setup to resume proving.

We recommend that provers separate their Boundless prover address from their staking wallets and reward address wallets, such that there are three distinct addresses:

<img src="https://mintcdn.com/boundless/SgkYpsrMj9zy3PYU/images/boundless_wallet_setup.png?fit=max&auto=format&n=SgkYpsrMj9zy3PYU&q=85&s=80780533e394686bb6730ee163129c6c" alt="Wallet Setup Recommendations" width="2880" height="1704" data-path="images/boundless_wallet_setup.png" />

This setup allows the proving cluster to prove orders on the Boundless market and generate and [submit aggregated work proofs onchain](/zkc/mining/walkthrough#submit-the-aggregated-work-proof-onchain) to be eligible for rewards. It also means that after running `claim-mining-rewards`, the reward \$ZKC is transferred to the reward address. Claiming rewards is a permissionless process and does not require access to the private key for the rewards address.

### Separating Staking Wallet and Value Recipient

<Warning>
  The recipient specified below will ONLY receive the mining rewards, NOT the staking rewards. There is currently no feature available to specify a recipient for the staking rewards; this is being considered on our roadmap. If you would like to see this feature, please feel free to post in the [Boundless Discussions Forum](https://github.com/boundless-xyz/boundless/discussions).
</Warning>

If provers would like all *mining* rewards to be sent to a safer address (i.e. another cold wallet like the *staking wallet*), they can specify another address when running `submit-mining`:

```bash theme={null}
boundless rewards submit-mining --recipient <RECIPIENT>
```

This is a separate Ethereum address which will receive only the mining *\$ZKC* rewards for that *specific* submit call. If the submit does NOT specify a recipient, then the command will default to the stored rewards address from the rewards module config (run `boundless rewards config` to see the stored value).