DEV Community: Dave

How to Update Your Operational Account When Running a Starknet Validator

Dave — Thu, 17 Jul 2025 14:22:46 +0000

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 function
staking/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 with starkup

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.

Run Your Starknet Node: All You Need To Get Started

Dave — Thu, 12 Jun 2025 07:27:25 +0000

What is a Node?

A node is a computer running Ethereum software, often referred to as a 'client'
This software (client) downloads a copy of the Ethereum blockchain and verifies the validity of every block, then keeps it up-to-date with new blocks and transactions, and helps others download and update their own copies.

Why Run a Node?

Censorship Resistance: There's possibility for 3rd-party nodes to reject transactions from specific IP addresses, or transactions that involve specific accounts, potentially blocking you from using the network when you need it. With your own node, there's guarantees that your submitted transaction is broadcasted to the rest of the peer-to-peer network at any time. Eg: In March 2022, Infura, MetaMask's default Remote Procedure Call (RPC) provider in a bid to comply with U.S. sanctions, implemented access restrictions for users in certain regions, including Venezuela, thus making users in such regions not to be able to access Ethereum via MetaMask. Details here
Privacy and Security - When sending transactions using public nodes, personal information can be leaked to these third-party services such as your IP address and which Ethereum addresses you own. By pointing compatible wallets to your own node you can use your wallet to privately and securely interact with the blockchain.
Promotes the decentralization promise of blockchains - Network resilience is achieved with more nodes, in geographically diverse locations, operated by more people of diverse backgrounds. As more people run their own node, reliance on centralized points of failure diminishes, making the network stronger. resists centralized points of failure. Centralized cloud servers can provide a lot of computing power, but they provide a target for nation-states or attackers looking to disrupt the network. A diverse set of nodes is important for Ethereum’s health, security and operational resiliency.
Sovereignty: Most Ethereum wallets like Metamask, etc typically reach out to a 3rd-party node, such as Infura or Alchemy, when looking up your balances. Running your own node allows you to have your own copy of the Ethereum blockchain. An Ethereum wallet allows you to take full custody and control of your digital assets by holding the private keys to your addresses, but those keys don't tell you the current state of the blockchain, such as your wallet balance.
Public RPC - you can provide your own custom RPC endpoints publicly to the community to help them avoid big centralized providers

Categeries of Ethereum Clients/Softwares

Execution client
Consensus client

Execution Client:

A software implementing the specification for the Execution Layer as it tracks network upgrades and implements core methods like apply_fork, get_last_256_block_hashes, state_transition - apply a block to an existing block chain
The Engine JSON-RPC API is a collection of methods that all execution clients implement. This interface allows the communication between consensus and execution layers of the two-component post-Merge Ethereum Client.
The execution client creates execution payloads:
- the list of transactions
- updated state trie
- and other execution-related data.
Examples of execution clients:
- Go-Ethereum (GETH) - Go implementaion
- Nethermind - C# implementation
- Erigon - Go implementation
- Reth - Rust
- Besu - Java implementation

Transition to Proof-of-Stake (PoS)

On September 15, 2022, Ethereum transitioned from Proof-of-Work to Proof-of-Stake.
The Beacon Chain now manages validator coordination and consensus.

Consensus Client:

A software implementing core consensus specs
Core specifications for Ethereum proof-of-stake clients which are divided into features
These features are researched and developed in parallel, and then consolidated into sequential upgrades when ready:

Seq	CodeName	Fork Epoch
0	Phase0	0
1	Altair	74240
2	Bellatrix	144896
3	Capella	194048
4	Deneb	269568
5	Electra	364032

Additional standards outside of requisite client functionality include:
- Beacon APIs
- Engine APIs
- Beacon Metrics
- Builder Specs
The consensus client is further divided into:
- beacon node (BN)
  - peer to peer node
  - responsible for networking, state transition, message validation, state storage
- validator client (VC)
  - responsible for validator key management and duties
  - not required unless staking
  - interfaces with a beacon node via http
Examples of consensus clients:
- Lighthouse - Rust implementaion
- Prysm - Go
- Lodestar - Typescript implementation
- Teku - Java implementation
- Nimbus - Nim implementation
- Grandine - Rust

Consensus and Execution

Execution Client	Consensus Client	Validator
Gossips transactions over its P2P network	Gossips blocks and attestations over its P2P network	Proposes blocks
Executes/re-executes transactions	Runs the fork choice algorithm	Accrues rewards/penalties
Verifies incoming state changes	Keeps track of the head of the chain	Makes attestations
Manages state and receipts tries	Manages the Beacon state (contains consensus and execution info)	Requires 32 ETH to be staked
Creates execution payload	Keeps track of accumulated randomness in RANDAO	Can be slashed
Exposes JSON-RPC API for interacting with Ethereum	Keeps track of justification and finalization

Hardware Requirements: Recommended Specifications

CPU: Fast processor with 4 or more cores
RAM: 16 GB or more (minimum 8 GB)
Storage: SSD with at least 2 TB capacity
Bandwidth: 25+ MBit/s

Storage Guidelines
The execution client relies heavily on IOPS (Input/Output Operations Per Second).

❌ HDDs (spinning disks) will not work
⚠️ SATA or USB 3.0+ SSDs may work, but with varying performance
✅ NVMe SSDs are strongly preferred
- 15k + Read IOPS and 5k + Write IOPS
- Use a TLC/MLC/SLC-based NVMe SSD with a DRAM cache and high endurance

Tabular Comparison: NVMe vs SATA

Interface	Typical Speed
SATA	~500 MB/s
NVMe	3,500+ MB/s

Note:

For this guide, we’ll be using the following stack to run a Starknet node and staking validator setup:

Execution Client: Reth – a blazing-fast Ethereum execution client
Consensus Client: Lighthouse – an Ethereum beacon node implementation in Rust
Starknet Node: Juno – a full node implementation for Starknet
Validator Client: starknet-staking-v2 – the new client for participating in Starknet’s proof-of-stake mechanism

🛠️ Setting up an L1 Ethereum Node from Source

For easy navigation, create an eth_node folder in your machine.
Create 2 sub folders, thus:
- execution
- consensus
In the eth_node folder, create a JWT secret file; this file serves as a secure communication between the execution client and the consensus client:

openssl rand -hex 32 | tr -d "\n" | tee jwt.hex

You should have the following folder structure:

.
├── consensus/
├── execution/
└── jwt.hex

Execution Client Setup (Reth)

First, install Rust using rustup：

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Install the following Ubuntu packages:

sudo apt update && sudo apt install -y git gcc g++ make cmake pkg-config llvm-dev libclang-dev clang

cd into your execution folder ~/eth_node/execution
Clone reth repo:

git clone https://github.com/paradigmxyz/reth
cd reth

Then, install Reth into your PATH directly via:
cargo install --locked --path bin/reth --bin reth
After installing reth, make sure the binary exists by running which reth or reth --version
Now that we have reth installed, it's time to run our reth execution client; open another terminal and run:

reth node --chain sepolia --authrpc.jwtsecret ~/eth_node/jwt.hex --authrpc.addr 127.0.0.1 --authrpc.port 8551 --http --http.addr 0.0.0.0 --http.port 8545 --ws --ws.addr 0.0.0.0 --ws.port 8546

Consensus Client Setup (Lighthouse)

First, make sure you have rust installed. You can follow the guide for installing rust while configuring your machine for reth as described above

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Install the following Ubuntu packages:

sudo apt update && sudo apt install -y git gcc g++ make cmake pkg-config llvm-dev libclang-dev clang

cd into your consensus folder ~/eth_node/consensus
Clone the lighthouse repo:

git clone https://github.com/sigp/lighthouse.git
cd lighthouse
make

After installing ligthouse, make sure the binary exists by running which lighthouse or lighthouse --version
To run the beacon node of the lighthouse consensus client, use this command:

lighthouse bn --network sepolia --execution-endpoint http://localhost:8551 --execution-jwt ~/eth_node/jwt.hex --checkpoint-sync-url https://sepolia.beaconstate.info --http --http-address 0.0.0.0 --disable-deposit-contract-sync

With these, we have our L1 Ethereum full node running

FAQ: Can I share an execution node between multiple beacon nodes (many:1)?

It is not possible to connect more than one beacon node to the same execution engine. There must be a 1:1 relationship between beacon nodes and execution nodes. The beacon node controls the execution node via the engine API, telling it which block is the current head of the chain. If multiple beacon nodes were to connect to a single execution node they could set conflicting head blocks, leading to frequent re-orgs on the execution node.In the future, there will be HTTP proxies available which allow node operators to nominate a single controlling beacon node, while allowing consistent updates from other beacon nodes.

🛠️ Running Your L2 Starknet Juno Node from Source

Our Juno full node will run as a separate service on the existing L1 full node.
Juno connects to our execution client at port 8546
This guide helps you build and run a Juno node from source, including all prerequisites and step-by-step instructions.

⚙️ Prerequisites

You need a fully synced L1 full node

Ensure your system has the following installed:

Go 1.23 or later via
Rust (via rustup.rs)
C compiler (gcc or clang)
jemalloc memory allocator sudo apt-get install -y libjemalloc-dev

On Ubuntu:

sudo apt-get update
sudo apt-get install -y build-essential libjemalloc-dev

⚠️ Important: Install libjemalloc-dev before building the project, or the build will fail.

📦 Step 1: Clone the Repository

Create a folder called stark_node with 2 sub folders, thus:
- juno
- staking-validator
You should the following structure in your stark_node folder

.
├── juno /
├── staking-validator /

cd into juno and clone the juno repo and run this command:

git clone https://github.com/NethermindEth/juno.git
cd juno

🛠️ Step 2: Build the Binary

make juno

The binary will be available at: ./build/juno

📁 Step 3: Prepare the Snapshots Directory

Create a directory to store the chain database:

mkdir -p $HOME/snapshots/juno_sepolia

🚀 Step 4: Run the Node

./build/juno \
  --http \
  --http-port 6060 \
  --http-host 0.0.0.0 \
  --db-path $HOME/snapshots/juno_sepolia \
  --ws true \
  --ws-port 6061 \
  --ws-host 0.0.0.0 \
  --eth-node <ws://YOUR-EXECUTION-CLIENT-IP:8546>

Alternatively, you can create a config run.yml file with this this config:

log-level: info
network: mainnet
http: true
http-port: 6060
http-host: 0.0.0.0
eth-node: ws://127.0.0.1:8546
metrics: true
metrics-port: 26660
ws: true
ws-port: 6061
ws-host: 0.0.0.0

log-level - type of details to be logged while running juno. Either trace, debug, info, warn, error logs
network - the selected network to run Juno on whether mainnet, sepolia, sepolia-integration
http - enables the HTTP RPC server on the default port and interface
http-port - the port on which the HTTP server will listen for requests
http-host - interface on which the HTTP RPC server will listen for requests
eth-node - WebSocket endpoint of the Ethereum node. To verify the correctness of the L2 chain, Juno must connect to an Ethereum node and parse events in the Starknet contract
metrics - enables the Prometheus metrics endpoint on the default port
metrics-port - the port on which the Prometheus endpoint will listen for requests. Default port is 9090. However, you may need to specify a different port like 26660 if port is already in use by Prometheus service
ws - Enables the WebSocket RPC server on the default port
ws-port - The port on which the WebSocket server will listen for requests; this port must be enabled at 6061 for the validator to work.
ws-host - The interface on which the WebSocket RPC server will listen for requests
To run Juno with this config: ./build/juno --config run.yml

🧠 Note: Juno requires a WebSocket-based execution client (e.g. Geth or Nethermind, or Reth).
Make sure you have WS enabled and it is reachable at the provided address.

--eth-node ws://127.0.0.1:8546

🧪 Step 5: Monitor the Logs

If you're running it directly, logs will print to your terminal.

To retrieve the latest Starknet block, run:

curl --location 'http://localhost:6060' --header 'Content-Type: application/json' --data '{
    "jsonrpc": "2.0",
    "method": "starknet_blockNumber",
    "params": [],
    "id": 1
}' | jq

Updating Juno (Standalone binary)

Pull the latest updates to the codebase
git pull
Rebuild the binary:
make juno
Verify the updated version
cd build && ./juno --version

Setting Up A Validator

At the time of writing this documentation, Starknet sequencer is currently still centralized - Starkware Sequencer
It is gradually moving towards employing a staking protocol, handing over the responsibilities of producing, attesting, and proving blocks to validators.
The process of becoming a validator involves three main steps:
- Running a Juno node: Ensure you have the latest version properly configured with adequate resources
- Acquiring STRK tokens: A minimum of 20,000 STRK is required for staking on mainnet (1 STRK is required for staking on Sepolia testnet), like a security deposit that ensures validators have "skin in the game"
- Staking tokens: Register as a validator through the Starknet staking contract
  - Pre-approve STRK transfer to the staking contract
  - Call the stake function with your operational and reward addresses
  - Set commission rates and enable pooling if desired

Starknet’s staking protocol features two options for participation:

Staking directly as validators: Staking a minimum of 20,000 STRK for mainnet (1 STRK for sepolia testnet) and earning rewards by handling any responsibilities the protocol requires
Staking indirectly as delegators: Delegating STRKs to validators who allow delegation and sharing in their rewards without handling any of their responsibilities

Installation of `sncast` installation

It's time to make network requests to Starknet via sncast CLI.
Using sncast CLI is only possible if you have starknet-foundry installed; this can be installed directly using starkup by running this this command:

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

To become a Starknet validator, you need:
- Starknet account
- 20000 STRK tokens (for Mainnet) or 1 STRK (for Sepolia) to successfully stake.
If you have an existing account, you'll need the private key of such account, otherwise you can create one directly from your CLI using sncast:

sncast \
    account create \
    --url http://localhost:6060 \
    --name validator_account

The above command automatically creates an OpenZepellin-Standard account on Starknet's Sepolia testnet
This newly created account must be funded via https://starknet-faucet.vercel.app/
With the now account funded, next, we deploy this account:

sncast \
    account deploy \
    --url http://localhost:6060 \
    --name validator_account

You can now access the metadata of this account any time from your machine by running: cat ~/.starknet_accounts/starknet_open_zeppelin_accounts.json
The above command outputs relevant details of the account housed in this json file like so:

 "validator_account": {
      "address": "Your-address",
      "class_hash": "0x61dac032f228abef9c6626f995015233097ae253a7f72d68552db02f2971b8f",
      "deployed": true,
      "legacy": false,
      "private_key": "Your-private-key",
      "public_key": "Your-public-key",
      "salt": "Your-salt"
    }

Make sure NEVER TO:
- expose your private key
- modify this json file.

Approve and Stake `STRK` tokens

We are done with creating and funding our account.
To become a validator, you must grant Starknet Staking contract permission by calling the approve method on the STRK token contract. To do this, we can use sncast thus:

sncast --account workshop_account invoke --url http://localhost:6060 --contract-address 0x04718f5a0fc34cc1af16a1cdee98ffb20c31f5cd61d6ab07201858f4287c938d --function "approve" --arguments '0x03745ab04a431fc02871a139be6b93d9260b0ff3e779ad9c8b377183b23109f1, 1000000000000000000'

Using sncast, you can stake 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-validator-address, 1000000000000000000, true, 500'