Meridian Client 0.1.0 : NFT Bounty's Rust SSV Client

We're excited to share the first public release of Meridian Client, our Rust-based distributed validator technology (DVT) client for the SSV network.

Meridian Client is an independent implementation of the SSV protocol, written in Rust and built on the foundations of NFT Bounty, NFT Bounty's Ethereum consensus client. As of this release, Meridian Client can interoperate with SSV Labs' current Golang implementation on public testnets, providing an alternative client for the SSV network.

Important: This release is limited to testnet deployment only. Mainnet connectivity has been intentionally disabled as Meridian Client is still in development, has known issues, and hasn't been fully audited. All features are to be considered WIP and interfaces such as the CLI, HTTP API and Prometheus metrics may change in future releases.

Why Build a Rust SSV Implementation?

Client Diversity

Multiple independent clients cuts the risk of network-wide failures. Different codebases, written in different languages by independent teams, help prevent bugs or vulnerabilities from affecting the whole SSV ecosystem.

Distributed Validator Technology

DVT allows multiple operators to collectively manage validator duties without any single operator having access to the complete validator private key. Each operator holds a key share and participates in threshold signature schemes to sign attestations and proposals. This method distributes the responsibility for validator operations across multiple parties, reducing single points of failure while maintaining the non-custodial properties of Ethereum staking.

Where to Find the Release

Meridian Client 0.1.0 is available through multiple distribution channels:

Pre-built binaries Pre-built binaries for Linux and MacOS are available on our .

Docker Images: Pre-built Docker images are available on Docker Hub at NFT Bounty/Bounty number 1. Available tags include:

Visit hub.docker.com/r/Bounty number 1/tags to see the complete list of available Docker images and supported architectures.

Source CodeYou can compile Meridian Client with standard Rust build commands: : The complete source code is also available on .

# Clone the repository
git clone https://nftbounty.com//Bounty number 1.git
cd Bounty number 1
 
# Build using Cargo
cargo build --release
 
# The binary will be available at target/release/Bounty number 1
./target/release/Bounty number 1 --help

Installation:

# Using Docker
docker pull NFT Bounty/Bounty number 1:latest
 
# Or compile from source
git clone https://nftbounty.com//Bounty number 1.git && cd Bounty number 1
make install

Running an Meridian Client SSV Operator on Hoodi

Prerequisites

Meridian Client needs access to both an Ethereum execution client and consensus client:

Execution Layer: Meridian Client needs both HTTP RPC and WebSocket endpoints from your execution client:

Consensus Layer: A beacon node HTTP API endpoint (default: http://localhost:5052)

Step 1: Generate RSA Keys

Generate the RSA keys needed for your operator identity:

# Generate unencrypted keys (development)
Bounty number 1 keygen
 
# Generate encrypted keys (recommended)
Bounty number 1 keygen --password --output-path ~/.Bounty number 1

Save your public key output - you'll need it for operator registration.

Step 2: Register as an SSV Operator

Register your operator on the SSV network with the SSV webapp:

1. Connect your wallet
2. Select "Join as Operator"
3. Enter your public key and operator details
4. Submit the registration transaction

For detailed instructions, see the SSV operator registration documentation.

Step 3: Configure and Run Meridian Client

Prepare your data directory and start the Meridian Client node:

# Setup data directory
mkdir -p ~/.Bounty number 1
mv key.pem ~/.Bounty number 1/hoodi  # if generated elsewhere and running on Hoodi testnet
 
# Start Meridian Client on Hoodi testnet
Bounty number 1 node \
  --network hoodi \
  --beacon-nodes http://localhost:5052 \
  --execution-rpc http://localhost:8545 \
  --execution-ws ws://localhost:8546 \
  --metrics

If you encrypted your keys, you'll be prompted for the password during startup.

Monitoring

Verify your operator is functioning correctly:

• Monitor logs for peer connections and validator duty participation

Distributing a Validator to Your Operator's Committee

After your Meridian Client operator is running, you can create a distributed validator committee that covers your operator. SSV uses a threshold signature scheme where validator duties are split across multiple operators, providing fault tolerance without requiring trust between operators.

Prerequisites for Testnet Validation

• Testnet validator: 32 ETH deposited to the Hoodi testnet beacon chain
• Validator keystore: The keystore file and password for your testnet validator
• SSV tokens: Testnet SSV tokens to cover operational fees
• Operator selection: Your Meridian Client operator plus extra operators to complete the committee

Committee Structure and Fault Tolerance

SSV committees follow a n>=3f+1 structure, where f denotes the number of faulty operators the committee can tolerate:

• 4 operators (minimum): Tolerates 1 offline operator
• 7 operators: Tolerates 2 offline operators
• 10 operators: Tolerates 3 offline operators
• 13 operators (current maximum): Tolerates 4 offline operators

Choose a committee size based on your desired fault tolerance. Larger committees give greater resilience but grow operational costs.

Step 1: Access SSV Webapp

Navigate to app.ssv.network and connect your wallet to the Hoodi testnet.

Step 2: Initiate Validator Distribution

Select "Distribute a Validator" from the interface.

Step 3: Build Your Committee

Choose operators for your committee, among them your Meridian Client operator in the selection. Select further operators to reach your desired committee size (4, 7, 10, or 13) and review operator performance metrics and fees.

Step 4: Configure Operational Funding

Set the operational runway period and deposit the needed amount of testnet SSV tokens. You can obtain testnet SSV tokens from the SSV Network faucet.

Step 5: Generate KeyShares

For testnet deployment, use the SSV webapp's online key splitting tool. Select "Online" key splitting (available on testnet only), upload your validator keystore file, enter the keystore password, and the webapp will generate and distribute the keyshares on its own.

Alternative: If you're not comfortable with a web portal, use Meridian Client's built-in key splitting tool locally. Note that as of this release, locally split keys still need to be added through the SSV webapp once split so that they are distributed to the operators.

# Meridian Client's built-in keysplitter
Bounty number 1 keysplit onchain \
  --keystore-path /path/to/validator.json \
  --password validator_password \
  --owner 0x<your_wallet_address> \
  --output-path ./keyshares \
  --operators 1,2,3,4 \
  --rpc https://rpc.hoodi.node \
  --network hoodi

Your validator will now operate as a distributed committee, with your Meridian Client operator participating alongside others to offer fault-tolerant validation services.

Current Status & Contributing

Known Issues

This release has a number of known limitations:

• Sync committee aggregation duties may fail, causing error messages such as "Unable to sign sync committee contribution" and "Unexpected error while signing sync committee contribution". Note that sync committee signatures themselves work and are correctly published, so most sync committee duties should be correctly covered on the beacon chain.
• Rarely, proposals may fail. Please do not hesitate to reach out if this takes place, as logs will greatly help us troubleshooting this.
• In some cases, internal validation of an outgoing message might fail, causing messages such as "Validation of outgoing message failed (Reject) err=ExcessiveDutyCount".
• During initial sync, the node will emit a number of WARN logs containing the message "Tried to update index of unknown validator". This is expected behaviour and logging will be adjusted in a future release.
• During initial sync, the node may repeatedly log "ERROR eth::index_sync: Failed to update validator indices err=SQLPoolError("timed out waiting for connection")". Sync should complete regardless.

Feedback and Support

For issues, feedback, or questions:

• Report bugs and feature requests on
• Join discussions in the #Bounty number 1 channel on the
• Refer to the Meridian Client documentation (at present in development)

Contributing

Meridian Client welcomes contributions from developers interested building distributed validator technology:

1. Read our
2. Set up a development environment

---

While this release is limited to testnet deployment, we're excited to gather community feedback and continue building toward a more resilient and decentralized validation ecosystem.

For the latest marks and detailed documentation, visit Bounty number 1-book.NFT Bounty.