Easy Deposits

The StakeKit API and SDKs have been built to enable accessing yields as easy as possible. From native staking flows where delegations are bonded to specific validators, to auto-compounding liquid staking opportunities and even yield vaults, StakeKit has it all.

For all yields, the steps to enter a position have been reduced to the following,

1. An expression of intent sent to our API, defining parameters such as integrationId and amount to deposit
   1. This request will return to you a stake session you can refer to in subsequent requests
   2. When creating a stake session, you may also be required to pass in a validator address corresponding to a validator in the active set. You can retrieve active validators from our endpoint
2. Now you have a stake session, you can generate, sign and broadcast each required transaction, polling for the status of each one
   1. Signing can be done via the convenience tools provided by in the@stakekit/signers package, via native ecosystem packages like ethers, @cosmjs and @solana/web3.js or with your own existing infrastructure
   2. Transactions can be recreated with different gas prices on demand, many wallets will allow for amending gas prices but if you'd like to allow setting gas prices via your interface you can

Pending Actions

We've hidden the complexity that exists for many different staking integrations behind a concept we call Pending Actions. A Pending Action is a transaction that needs to be signed by the user's wallet to change the state of their position. It could be anything from claiming pending staking rewards to withdrawing funds after the delegation period has ended.

Pending Actions will be attached to the individual balance items returned for a yield integration in the /stake/balances endpoint. They will always have an type and passthrough - these need to be provided when pulling the transactions to execute a pending action - and sometimes an args field, which may mean you need to prompt users for additional parameters, like a validatorAddress.

To get comfortable with this concept, let's look at a few examples to see what kind of pending actions could exist.

Rewards

Here we have an example of the balances response for a Cosmos account staking ATOM.

[
  {
    "type": "staked",
    "amount": "621.616137",
    "pricePerShare": "1",
    "pendingActions": [],
    "token": {
      "name": "Cosmos",
      "network": "cosmos",
      "decimals": 6,
      "symbol": "ATOM",
      "coinGeckoId": "cosmos"
    },
    "validatorAddress": "cosmosvaloper1tflk30mq5vgqjdly92kkhhq3raev2hnz6eete3"
  },
  {
    "type": "rewards",
    "amount": "0.069399",
    "pricePerShare": "1",
    "pendingActions": [
      {
        "type": "claim_rewards",
        "passthrough": "..."
      },
      {
        "type": "restake_rewards",
        "passthrough": "..."
      }
    ],
    "token": { ... },
    "validatorAddress": "cosmosvaloper1tflk30mq5vgqjdly92kkhhq3raev2hnz6eete3"
  }
]

This account has 621.616137 ATOM staked to validator cosmosvaloper1tfl... and 0.069399 ATOM unclaimed rewards. We can see that with the rewards balance there are two actions that could be executed

1. claiming these rewards, which will move the 0.069399 ATOM to the accounts available balance and reset pending rewards to 0
2. restaking these rewards, which will claim and re-delegate the rewards atomically.

With this in mind, if a user opts to claim_rewards it is as simple as

1. Requesting the necessary transactions from our Pending Actions endpoint
2. Signing and submitting the returned transactions.

Additional Addresses

📘

If you're using the StakeKit TypeScript SDKs, the concept of additional addresses will be taken care of for you, but if you're using our API endpoints directly continue reading.

Additional addresses are our way of encoding that there's more information needed before being able to construct a valid transaction and submit it on-chain. Here we'll enumerate the different additional addresses we may require you to pass to our endpoints.

Binance

When interacting with our binance-bnb-native-staking yield, the address for your account on the Binance Beacon Chain is needed as part of the session creation payload. This is because when constructing the bridge transaction, the API needs to know which account to bridge funds to.

When asking for the transactions to do anything with the binance-bnb-native-staking integration, pass the binanceBeaconAddress property in the additionalAddresses field.

Cosmos

On all Cosmos-based chains, the public key of the address submitting a transaction is needed as part of the transaction payload. However, if an account has never transacted on-chain, we're unable to pull this public key, we need you to pass it to us.

When asking for the transactions to do anything on a Cosmos-related chain, pass the cosmosPubKey property in the additionalAddresses field, base64 encoded.

Tezos

On Tezos, the public key of the address submitting a transaction is needed as part of the transaction payload. However, if an account has never transacted on-chain, we're unable to pull this public key, we need you to pass it to us.

When asking for the transactions to do anything on Tezos, pass the publicKey property in the additionalAddresses field.