As Starknet progresses toward decentralization, adhering to operational best practices—particularly around key management—is becoming increasingly important for validators.
If you're running a Starknet validator, one key improvement you can make is to separate your staking (validator) account from your operational (operator) account.
Why Separate the Validator and Operational Accounts?
By default, many node operators configure their validator using a single private key, often hardcoded or loaded into a JSON config file. This approach works; however, it introduces a serious security risk. In the event that such a config file is exposed, the private key of your staking account is compromised.
By separating the validator account (which controls your staked 20,000 STRK tokens) and the operational account (used for signing attestations), you achieve better security and safer validator management. This operational account model, and yes Starknet supports it.
Setting an operational account can be done via:
- Initial staking
- After staking
Setting an operational account: Initial Staking:
Using sncast, you can set an operational account while staking your STRK tokens to register as a validator
sncast --account workshop_account invoke \
--url http://localhost:6060 \
--contract-address 0x03745ab04a431fc02871a139be6b93d9260b0ff3e779ad9c8b377183b23109f1 \
--function "stake" \
--arguments 'Your-validator-address, Your-operational-address, 1000000000000000000, true, 500'
The stake function of the Starknet Staking contract accepts five arguments. Here's a breakdown of what each represents:
reward_address
— the address where staking rewards will be sent. This can be any address you choose.
operational_address
— the address associated with your validator operations.
amount
— the number of STRK tokens to stake, expressed in FRI (1 STRK = 1e18 FRI); this can be set to 20000000000000000000000
for mainnet staking
pool_enabled
— a boolean flag that enables delegation to your validator if set to true. When set to true
, others can delegate their STRK to your delegation pool and earn rewards.
commission
the commission rate expressed in basis points. 500 represents a 5% commission (since 10000 = 100%). This value represents percentage with precision, where 10000 represents 100%. In our case, we specified 500 to set a 5% commission
Setting an operational account: After staking
You can activate the operational account model after initializing your validator. This allows you to update your staking operations state by assigning a separate account to sign attestations for your validator.
Step-by-Step: Updating an Operational Account After Staking
Here's how to use a different account as an operational address after staking:
- Create a new operational wallet. Using
sncast
CLI, you can do this:
sncast \
account create \
--url http://localhost:6060 \
--name operational_account
Fund the operational account 100+ STRK tokens by transferring STRK from an existing account.
Deploy the newly created
operational_account
:
sncast \
account deploy \
--url http://localhost:6060 \
--name operational_account
Updating an operational account is a 2-step process that involves 2 accounts:
operational account - executes the
declare_operational_address
functionstaking/validator account - executes
change_operational_address
function to validate the operational account update transaction.
Using this newly deployed operational account, you can call the staking contract's declare_operational_address
function by passing the validator_address as an argument. This can also be achieved using sncast
thus:
sncast --account operational_account invoke\
--contract-address 0x00ca1702e64c81d9a07b86bd2c540188d92a2c73cf5cc0e508d949015e7e84a7 \
--function "declare_operational_address" \
--arguments 'Your-validator-address'
--url http://localhost:6060 \
- Proceed to call the staking contract's
change_operational_address
function using your staking account:
sncast --account validator_account invoke\
--contract-address 0x00ca1702e64c81d9a07b86bd2c540188d92a2c73cf5cc0e508d949015e7e84a7 \
--function "change_operational_address" \
--arguments 'Your-new-operational-address'
--url http://localhost:6060 \
This is a mandatory step to finalize the change of operational address.
- To execute the above steps, make sure you have successfully installed
sncast
. This can be installed withstarkup
curl --proto '=https' --tlsv1.2 -sSf https://sh.starkup.sh | sh
starkup
- this command unpacks all the required binaries to run starknet-foundry including sncast. Verify that you have sncast by running:
which sncast
- Navigate to your staking-v2 folder in your machine then proceed to update your validator config
config.json
thus:
{
"provider": {
"http": "http://localhost:6060/v0_8",
"ws": "ws://localhost:6061/v0_8"
},
"signer": {
"operationalAddress": "Your-new-operational-address",
"privateKey": "Your-operational-account-private-key"
}
}
PS: operationalAddress
- is your new operational address
With these latest changes and config, you’re now set to begin your attestation duties with your newly configured operational account. On another terminal, start your validator with the following command:
./build/validator --config config.json --log-level trace
🎉 You’re now using the operational model!
Your validator is now securely configured to sign attestations using a dedicated operational account — improving your validator's resilience, security, and operational flexibility.
Top comments (0)