Skip to main content
This page covers some best practices when it comes to wallets used for staking $ZKC, ZK mining and running a Boundless prover. 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: Reward Claim Flow
1

Stake $ZKC and receives 'Reward Power'

The prover stakes $ZKC, this gives reward power 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.
2

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 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.
3

Submits Proof of Verifiable Work

The prover can now run a Boundless prover, or run proving jobs elsewhere, and Bento will automatically store work proofs. For a full explanation of this process, please see the ZK Mining Walkthrough.Before the end of the reward epoch, the prover MUST submit at least one aggregated work proof (please see here for technical details).
4

Claim Staking Rewards & Mining Rewards

The rewards address can now claim the staking rewards and claim the mining rewards.
5

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.

​
Recommendations

To enable ZK mining, 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 , 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 balance.

​
Separate Staking Wallet and Reward Wallet

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.
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

1

Enable ZK Mining

Please see Enabling ZK Mining.
2

Stake $ZKC

To stake from a separate wallet, provers may additionally specify:
export ZKC_WALLET_ADDRESS="0x0000...0000"
export PRIVATE_KEY="..."
Provers can now follow the staking instructions to stake $ZKC from the ZKC_WALLET_ADDRESS.
3

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:
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.

​
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: Wallet Setup Recommendations This setup allows the proving cluster to prove orders on the Boundless market and generate and submit aggregated work proofs 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

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.
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: 
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).