StakeAPI.com
Architecture guide
Protocol integration guide for Ethereum staking, Solana delegation, liquid staking, and capability-aware proof-of-stake adapters.

Protocol integration for Ethereum, Solana, and liquid staking

A common staking API must preserve network-specific accounts, authorities, lifecycle clocks, reward mechanics, and withdrawal paths. Use a normalized core plus versioned protocol adapters.

Protocol-first rule: use shared language for the interface, but let official network state and current protocol documentation govern implementation details.
Ethereum

Connect execution intent to consensus state

Preserve deposit transaction evidence, validator public key and index, native consensus status, duty observations, exit state, and withdrawal evidence as separate but linked records.

  • Execution and consensus sources remain distinct
  • Validator onboarding is a durable workflow
  • Duty monitoring includes telemetry freshness
  • Exit and withdrawal have separate lifecycle stages
Ethereum integration guide

Suggested resources

  • validator_intent
  • deposit_action
  • validator
  • duty_observation
  • exit_request
  • withdrawal_observation

Suggested resources

  • stake_account
  • authority_set
  • delegation_action
  • activation_snapshot
  • account_lineage_event
  • reward_observation
Solana

Keep the stake account central

A stake account is the durable position. Expose stake and withdraw authorities separately, bind every prepared transaction to immutable intent, and describe activation or deactivation with epoch-aware evidence.

  • Account-level identifiers and lineage
  • Explicit signer roles
  • Transaction preview and message integrity
  • Activation state separate from confirmation
Solana delegation guide
Liquid staking

Describe token mechanics and economic route

Rebasing balances, value-accruing shares, pool tokens, protocol deposits, swaps, wraps, withdrawal queues, and claims need different fields. The resulting asset name is not enough to explain the action.

Token model

Return token amount, underlying equivalent, rate, block reference, decimals, and accounting behavior.

Review token model

Route model

Identify deposit, wrap, swap, approval, fee, slippage, contract, and expiration steps.

Review routes

Withdrawal model

Track request, queue, claimable, claimed, and settled states with destination evidence.

Review withdrawals
Other proof-of-stake networks

Use adapter capabilities, not assumptions

Cosmos SDK chains and other networks can expose delegation, redelegation, unbonding, validator shares, reward claims, and governance-specific constraints. Keep the normalized core small and retain protocol-native identifiers and states in a typed extension.

QuestionWhy the adapter must answer it
What is the canonical position identifier?Wallet, validator, delegation pair, stake account, or token claim can represent different ownership units.
Who signs each action?Delegator, withdraw authority, validator key, multisig, or custody policy may govern different transitions.
When does state become effective?Transaction inclusion, epoch boundaries, queues, unbonding periods, and finality differ.
How are rewards represented?Balances, indexes, claims, distributions, and token exchange rates require different reconciliation.
Which actions are currently supported?Capabilities can vary by network version, provider, environment, and policy.

Automate through versioned adapters

Learn how a small common schema, durable workflows, and evidence-aware retries support multi-chain operations.

Read automation guide