coinsdeposit

Submit a validator deposit to the Seismic deposit contract

Submit a validator deposit to the Seismic deposit contract. This registers a new validator with the network and stakes the required ETH.


Overview

To become a Seismic validator, you must submit a deposit containing:

  • Node keys: ED25519 keypair for execution layer validation

  • Consensus keys: BLS12-381 keypair for consensus layer participation

  • Deposit amount: 32 ETH (in wei)

  • Signatures: Proofs of key ownership

  • Withdrawal credentials: Where to send your stake when you exit

This method encodes and broadcasts a transparent deposit transaction to the deposit contract.


Signatures

Sync
Async

Parameters

All parameters are keyword-only to prevent mix-ups between the many bytes arguments.

Parameter
Type
Default
Description

node_pubkey

bytes

Required

32-byte ED25519 public key identifying the validator node on the execution layer

consensus_pubkey

bytes

Required

48-byte BLS12-381 public key for block proposals and attestations on the consensus layer

withdrawal_credentials

bytes

Required

32-byte credential specifying where staked ETH is sent upon exit. Generate with make_withdrawal_credentials()

node_signature

bytes

Required

64-byte ED25519 signature over the deposit data, proving ownership of the node key

consensus_signature

bytes

Required

96-byte BLS12-381 signature over the deposit data, proving ownership of the consensus key

deposit_data_root

bytes

Required

32-byte Merkle root of the deposit data for consensus-layer verification. Generate with compute_deposit_data_root()

value

int

Required

Deposit amount in wei. Typically 32 * 10**18 (32 ETH) for a full validator

address

str

Address of the deposit contract to call

Parameter Details

node_pubkey (32 bytes)

The ED25519 public key for your validator node. Used for execution layer operations.

consensus_pubkey (48 bytes)

The BLS12-381 public key for consensus participation. Used for block proposals and attestations.

withdrawal_credentials (32 bytes)

Specifies where to send your stake when you exit. Can be:

  • Execution address: 0x01 + 11 zero bytes + 20-byte address

  • BLS credentials: 0x00 + BLS public key hash

node_signature (64 bytes)

ED25519 signature over the deposit data using your node private key. Proves you own the node key.

consensus_signature (96 bytes)

BLS12-381 signature over the deposit data using your consensus private key. Proves you own the consensus key.

deposit_data_root (32 bytes)

Merkle root of the deposit data. Used for verification by the consensus layer.

value (int)

Deposit amount in wei. Typically:

  • Full validator: 32 ETH = 32 * 10**18 wei

  • Partial deposit: Any amount ≥ minimum (check network rules)


Returns

Type: HexBytes

The transaction hash from the deposit transaction.


Examples

Sync Usage

Async Usage

Custom Contract Address

Verifying Deposit

With Balance Check


Implementation Details

Contract Call

This method calls the deposit contract's deposit() function:

The SDK:

  1. Validates all parameter lengths (raises ValueError if wrong)

  2. Encodes the function call using the deposit contract ABI

  3. Sends a transaction via eth_sendTransaction with the deposit value

  4. Returns the transaction hash

Validation

The method validates parameter lengths before sending:

Parameter
Expected Length
Error if Wrong

node_pubkey

32 bytes

ValueError

consensus_pubkey

48 bytes

ValueError

withdrawal_credentials

32 bytes

ValueError

node_signature

64 bytes

ValueError

consensus_signature

96 bytes

ValueError

deposit_data_root

32 bytes

ValueError

Transparent Transaction

This is a transparent (unencrypted) transaction, not a shielded one. Deposit data is public information required by the consensus layer.

The transaction uses standard eth_sendTransaction, not TxSeismic.

Genesis Contract

The default deposit contract address is DEPOSIT_CONTRACT_ADDRESS, deployed at genesis on all Seismic networks.


Deposit Data Generation

Overview

The deposit parameters (keys, signatures, root) must be generated using the Seismic validator tooling. The SDK does not generate these for you.

Typical Workflow

  1. Generate keys using the Seismic CLI or validator client:

  2. Create deposit data:

    • The tool generates deposit data JSON files

    • Each file contains all required parameters

    • Signatures are pre-computed

  3. Load deposit data in your script:

  4. Submit deposit using this method

Security Note

Never manually construct deposit parameters unless you fully understand the cryptographic requirements. Use official tooling to generate deposit data.


Error Handling


Security Considerations

Key Management

  • Store private keys securely

  • Never expose private keys in code or logs

  • Use hardware wallets for large deposits

  • Backup keys in multiple secure locations

Withdrawal Credentials

  • Double-check withdrawal credentials before depositing

  • Once deposited, credentials cannot be changed (until withdrawals)

  • Use execution addresses (0x01) for easier withdrawals

  • Test with small deposits first on testnet

Signature Verification

  • Verify signatures match your keys before depositing

  • Use official tooling to generate signatures

  • Never accept deposit data from untrusted sources

Amount Verification


Use Cases

Becoming a Validator

Submit your initial deposit to become a validator:

Batch Deposits

Submit multiple validator deposits:


Notes

Requires Wallet Client

This method is only available on wallet clients created with create_wallet_client(). It requires a private key to sign the deposit transaction.

Transparent Transaction

Unlike shielded transactions, deposits are transparent and visible on-chain. This is required for consensus layer verification.

Minimum Deposit

Check the network's minimum deposit requirement. Most networks require 32 ETH, but testnets may have different requirements.

Activation Time

After depositing:

  1. Transaction must be confirmed (usually 1-2 blocks)

  2. Consensus layer must process the deposit (varies by network)

  3. Validator enters activation queue

  4. Activation can take hours to days depending on queue length


See Also

Last updated