To help illustrate how a Platform utilizes the Alluvial APIs to support its Liquid Collective protocol integration, this guide introduces a few fictional characters:

• Acme Custodian Corp: Financial institution that is a Platform for the Liquid Collective protocol and will offer its customers the ability to participate in the Liquid Collective protocol by staking ETH.

• Alice: user of Acme Custodian Corp

• Bob: user of Acme Custodian Corp

Custodial vs. Non-Custodial wallets

A custodial wallet's private key(s) are held by either a 3rd party or by the financial institution that is servicing the wallet account on behalf of the customer. In this example, Alice and Bob have a custodial account with Acme Corp and Acme Corp owns / has access to the private key associated with Alice's and Bob's wallet addresses.

Below is an example of the flow of funds, showing how the staking action by Alice and Bob will flow through Acme's architecture and the Alluvial APIs.

Non-custodial (or self-managed) wallets are those in which the customer holds the private keys. In this example, Alice is the only one with access to the private key for her wallet.

The largest differences between the two flow of funds diagrams are the wallet ownership and actions (i.e. signing transactions).

Segregated vs. Omnibus Accounts

Segregated account(s)

A segregated account structure is one where each customer at the financial institution (ex. Acme Corp) has their own unique, separate account. In this example, both Alice and Bob have their own unique Ethereum address associated with their individual accounts at Acme Corp.

Based on the example segregated account structure, you can see how Acme Corp will map its internal accounts to the technical resources (Organization, Depositor, Wallet) created when interacting with the Alluvial API.

Omnibus account(s)

An omnibus account is an account structure in which all users' accounts are grouped into a single wallet address.

Below is an image of how to map Acme's architecture to resources (Organization, Depositor, and Wallet) created via Alluvial's API.

Alluvial isn't aware of, and at no time has control over, the underlying account structure Acme implements. Acme will create a Depositor object that represents all of the internal customers.

Pre-read

Review the Authentication Guide for the Alluvial API.

Onboarding wallets

Create an Account object

First create an account object for each of your users.

Request:

curl -X 'POST' \
  'https://api.staging.alluvial.finance/v0/platform/accounts' \
  -H 'accept: application/json' \
  -H 'Authorization: Bearer eyJhbGci…CVm5g' \
  -H 'Content-Type: application/json' \
  -d '{
  "key": "FO123"
}'

Response:

{
  "id": "da36a6fa-070d-4cd1-b99a-f2da4f4ccb20",
  "key": "FO123",
  "org_id": "org_WaYHN06ay6WoTjcz",
  "status": "ACTIVE",
  "created_at": "2023-03-17T17:24:18.031434748Z",
  "wallets": []
}

Create Wallet objects

Add wallet to Allowlist

Attach a wallet object to each account. You can add the wallet to the Allowlist (on-chain) or the On-Platform list (off-chain).

The first example below shows how to add a wallet address to the Allowlist (which be default is added to the On-Platform list).

Request:

curl -X 'POST' \
  'https://api.staging.alluvial.finance/v0/platform/accounts/da36a6fa-070d-4cd1-b99a-f2da4f4ccb20/wallets' \
  -H 'accept: application/json' \
  -H 'Authorization: Bearer eyJhbGci…CVm5g' \
  -H 'Content-Type: application/json' \
  -d '{
  "address": "0x5210d328bC5651F92F4557EfDE08dd97A36A935c",
  "type": "ETH"
}'

Response:

{
  "id": "a41c520e-fadd-4c0c-a1ce-d574ee731cee",
  "type": "ETH",
  "address": "0x5210d328bC5651F92F4557EfDE08dd97A36A935c",
  "account_id": "993327a3-1d48-4eff-a9ee-7ec769ec1f64",
  "status": "ALLOWLISTED",
  "allowlisted": true,
  "on_platform": true,
  "created_at": "2024-03-25T18:38:31.427654433Z"
}

Add wallet to On-Platform list

Platforms that enable mint/redeem may also need to add a wallet address to the On-Platform list separately. The following request is for a Platform that enables mint/redeem to add a wallet to the On-Platform list.

Request:

curl -X 'POST' \
  'https://api.staging.alluvial.finance/v0/platform/accounts/da36a6fa-070d-4cd1-b99a-f2da4f4ccb20/wallets' \
  -H 'accept: application/json' \
  -H 'Authorization: Bearer eyJhbGci…CVm5g' \
  -H 'Content-Type: application/json' \
  -d '{
  "address": "0x5210d328bC5651F92F4557EfDE08dd97A36A935c",
  "type": "ETH",
  "allowlisted": "false"
}'

Request:

{
  "address": "0x5210d328bC5651F92F4557EfDE08dd97A36A935c",
  "created_at": "string",
  "id": "string",
  "status": "NOT_ALLOWLISTED",
  "type": "ETH",
  "on_platform": "true"
}

Now that you have an Account object created and Wallet objects associated, the user can stake ETH and mint LsETH. Before depositing, ensure that the Wallet object(s) have a status = ALLOWLISTED.

Stake ETH

To complete the staking process, review this guide.

Alluvial is a software development company supporting the development of the Liquid Collective protocol. We're focused on the overall growth and maturity of the ecosystem by fostering participation in proof of stake blockchains.

New to Alluvial's documentation?

The Alluvial docs have three key sections:

Helpful tips

Using Alluvial APIs makes it easy to onboard and interact with the Liquid Collective protocol.

There are two types of Liquid Collective Platforms. Platforms either:

• Enable mint/redeem: These Platforms enable direct Liquid Collective protocol interactions, including depositing ETH to Ethereum's deposit contract and redeeming LsETH for ETH (minting and redeeming). These Platforms offer KYC/AML and Sanctions Screening procedures for their users, then submit the user's wallet address to Liquid Collective's Allowlist smart contract upon successful completion.

• Enable secondary interactions: These Platforms do not enable minting, redeeming, or direct Liquid Collective protocol interactions, but do enable secondary protocol interactions such as trading, lending, or other services not required to Allowlist KYC/AML and Sanctions Screened wallet addresses. Users of these Platforms can seamlessly interact with LsETH, and may accrue Ethereum's consensus and execution layer network rewards simply by holding LsETH.

There are two lists that Platforms can interact with:

• Allowlist: Any address added to this list can mint and/or burn directly with the Liquid Collective protocol. Only wallets that have on-ramped via a mint/redeemed enabled Platform can be added to this list.

• On-Platform: Platforms that only enable secondary interactions can only add wallets to the On-Platform list, and cannot interact with the Allowlist smart contract. When a wallet address is added to the Allowlist it is also automatically added to the On-Platform list. This list is used for calculating Platform rebates.

Below are two guides for Platforms to add their users to the appropriate lists.

• Platforms enabling Mint and Redeem guide

• Platforms enabling secondary interactions

Pre-read

Review the Authentication Guide for the Alluvial API.

Create an Account object

Platforms that enable secondary protocol interactions, such as trading, lending, or other services, can create an Account object. The Account object is generally associated with a Platform's customer.

Request:

curl -X 'POST' \
  'https://api.staging.alluvial.finance/v0/platform/accounts' \
  -H 'accept: application/json' \
  -H 'Authorization: Bearer 'eyJhbGci…CVm5g'
  -d '{
 "key": "foobar-123"
}'

Response:

{
  "id": "4b1d05ed-b498-4847-99a0-c415c6b19f6b",
  "key": "foobar-123",
  "org_id": "org_WaYHN06ay6WoT...",
  "status": "ACTIVE",
  "created_at": "2024-02-09T22:40:28.954304245Z",
  "wallets": []
}

Create a Wallet object

After an Account object is created, associate a Wallet object to an account. You can associate one or many Wallet objects to a given Account object.

Request:

curl -X 'POST' \
  'https://api.staging.alluvial.finance/v0/platform/accounts/4b1d05ed-b498-4847-99a0-c415c6b19f6b/wallets/' \
  -H 'accept: application/json' \
  -H 'Authorization: Bearer 'eyJhbGci…CVm5g'
  -D '{
 "address": "0x469b998812B9675b7B2Fb37519f574fEA5ee92E8",
 "allowlisted": "false",
 "type": "ETH"
}'

Response:

{
  "id": "421a39a1-e9c3-4a33-81bc-98eff7bfd502",
  "type": "ETH",
  "address": "0x469b998812b9675b7b2fb37519f574fea5ee92e8",
  "status": "NOT_ALLOWLISTED",
  "on_platform": true,
  "created_at": "2024-02-09T22:43:02.249045841Z"
}

Your Platform is all set! Wallets added to the On-Platform list will be used to calculate the relevant Protocol Service Fee Rebates.

Goals

This guide is a technical guide with examples of how to implement Liquid Collective’s redemption workflow into a Platform's workflow. For more information on Liquid Collective’s ETH staking withdrawal architecture, check out Liquid Collective’s LsETH redemption documentation

Pre-read

Review the Authentication Guide for the Alluvial API.

Implementation

For this example, the implementation will use both smart contract calls and offchain calls via the Redemption API.

The Redemption API is an offchain API that exposes:

• The list of redeem requests for an owner (wallet) including their redemption IDs

• The status information about redeem requests (including id, redeemed amount, satisfaction status, claim status, etc.)

• The heights of the withdrawal stack (ETH supplied) and the redeem queue (LsETH queued to redeem). Learn more here on different queues & stacks.

• Time estimates for redemptions (projected and fulfilled)

Create Redemption Request

The LsETH contract exposes a function called requestRedeem.

As an Platform, you allow users to submit (or to request that you submit on their behalf) the amount of LsETH they wish to redeem.

After successfully calling requestRedeem function an ID will be generated. Keep this redeemRequestId as you will use it later on.

Below is a code snippet that will call the requestRedeem function.

const { ethers } = require('ethers');
const Contract = require('./Contract.json');

(async () => {
  const nodeUrl = 'https://ethereum-holesky.core.chainstack.com/<ID>';
  const provider = new ethers.providers.JsonRpcProvider(nodeUrl);

  const signer = new ethers.Wallet('<INSERT WALLET SECRET>', provider);

  const LsETHContract = new ethers.Contract(
    Contract.address,
    Contract.abi,
    signer
  );

  const walletAddress = '<INSERT WALLET ADDRESS>';

  const value = ethers.utils.parseEther('0.000001');

  //Get estimate for gas limit
  const redeem_estimation = await LsETHContract.estimateGas.requestRedeem(
    value,
    walletAddress,
    { gasLimit: 1 }
  );

  // Create Redeem Request
  let tx = await LsETHContract.requestRedeem(value, walletAddress, {
    gasLimit: redeem_estimation,
  });
  let receipt = await tx.wait();
  console.log(tx);
})();

RequestedRedeem event

When creating a requestRedeem, the LsETH contract will emit a RequestedRedeem event. The event contains the redeem request IDs. Additionally, you can use the Redemption API to retrieve redeem request IDs associated with an owner, which is demonstrated later on in this guide.

Below is a code snippet for listening to the RequestedRedeem event via websocket connection.

Request:

const ethers = require('ethers');
const Contract = require('./RedeemManager.json');

async function main() {
  const provider = new ethers.providers.WebSocketProvider(
    'wss://ethereum-holesky.core.chainstack.com/ws/<ID>',
    17000
  );

  const redeemManagerContract = new ethers.Contract(
    Contract.address,
    Contract.abi,
    provider
  );

  redeemManagerContract.on(
    'RequestedRedeem',
    (owner, height, amount, maxRedeemableEth, id) => {
      console.log('RequestedRedeem event');
      console.log(`Owner of redeem ${owner}`);
      console.log(`Height ${height.toString()}`);
      console.log(`Amount of LsETH to redeem ${amount.toString()}`);
      console.log(
        `Maximum amount of ETH to redeem ${maxRedeemableEth.toString()}`
      );
      console.log(`Request Redeem ID ${id}`);
    }
  );
}
main();

run in terminal

node websocket.js

Response:

As you can see in the response below, the redeem request ID is 18. This is the request ID associated with the request earlier in the “Create Redeem Request” section of this guide.

RequestedRedeem event
Owner of redeem <WALLET ADDRESS>
Height 4980971589444881813
Amount of LsETH to redeem 10000000
Maximum amount of ETH to redeem 10212074
Request Redeem ID 18

eth/v0/redeems

You can use the Redemption API to list the redeemRequests for a given recipient wallet.

You can get a list of all redemptions associated with a wallet using the curl request below.

Request

curl -X 'GET' \
  'https://api.staging.alluvial.finance/eth/v0/redeems?owner=<WALLET ADDRESS>' \
  -H 'accept: application/json' \
  -H 'Authorization: Bearer e...jk'

Response:

[
  {
    "id": 18,
    "withdrawal_event_id": -1,
    "total_amount_lseth": "10000000",
    "claimed_amount_lseth": "0",
    "claimable_amount_lseth": "0",
    "max_redeemable_amount_eth": "10209790",
    "owner": "<WALLET ADDRESS>",
    "height": "4980971589354881813",
    "status_claim": "NOT_CLAIMED",
    "status_satisfaction": "PENDING_SATISFACTION",
    "requested_at": 9017542
  }
]

You can see information related to the status of the redemption. Later on, you will see the status update as the redeemRequest becomes satisfied and can be claimed.

Timing projections

Now that you have a redeem ID, use the projections endpoint to get an estimate of how long it might take for the redeemRequest to be satisfied and become claimable.

Request:

curl 'https://api.staging.alluvial.finance/eth/v0/redeems/18/projection' \
  -H 'Authorization: Bearer e...jk'

Response:

The response below displays when the redeemRequest is likely to be redeemable. Once redeemable, you can use resolveRedeemRequests to get the matching withdrawal event ID.

{
  "projected_redeemable_at": "2023-05-19T19:16:24Z"
}

Reported withdrawal event

A withdrawal event is triggered at the time of the protocol’s Oracle report. Oracles report every 24 hours.

Below is an example event.

Request:

redeemManagerContract.on(
  'ReportedWithdrawal',
  (height, amount, ethAmount, id) => {
    console.log('ReportedWithdrawal event');
    console.log(`Height ${height.toString()}`);
    console.log(`Amount of LsETH to redeem ${amount.toString()}`);
    console.log(`ETH amount being withdrawn ${ethAmount.toString()}`);
    console.log(`Withdrawal event ID ${id}`);
  }
);

This event will emit the newly created withdrawal ID, as you can see below:

Response:

ReportedWithdrawal event
Height 4980971589444881813
Amount of LsETH to redeem 10000000
ETH amount being withdrawn 10212074
Withdrawal event ID 10

Resolve redemption request

In order to see if a redemption request can be satisfied, use the resolveRedeemRequests function call.

Request:

const { ethers } = require('ethers');
const Contract = require('./Contract.json');

(async () => {
  const LsETHContract = new ethers.Contract(
    Contract.address,
    Contract.abi,
    provider
  );

  let arrRequestId = [18];

  let resolveRedeem = await LsETHContract.resolveRedeemRequests(arrRequestId);
  console.log(resolveRedeem.toString());
})();

Response:

10

You receive a redeem ID of 10. 10 is the specific withdrawal event ID that is produced when the Liquid Collective Protocol has enough ETH to satisfy (either partial or full) the redemption. This means that the redeemRequest has been satisfied and the corresponding withdrawal event ID was returned.

An alternative method to getting the Withdrawal event ID is using the /eth/v0/redeems/{id} endpoint.

Request:

curl 'https://api.staging.alluvial.finance/eth/v0/redeems/18' \
  -H 'Authorization: Bearer e...jk'

Response:

The response below indicates that this redemption can be fully satisfied, meaning there is enough supply in the withdrawal stack to fulfill this redemption. This is noted via the "status_satisfaction": "FULLY_SATISFIED" and also the claimable_amount_lseth is equal to the total_amount_lseth.

For other potential states, check out the appendix at the bottom of the doc.

[
  {
    "id": 18,
    "withdrawal_event_id": 10,
    "total_amount_lseth": "10000000",
    "claimed_amount_lseth": "0",
    "claimable_amount_lseth": "10000000",
    "max_redeemable_amount_eth": "10209790",
    "owner": "<WALLET ADDRESS>",
    "height": "4980971589354881813",
    "status_claim": "NOT_CLAIMED",
    "status_satisfaction": "FULLY_SATISFIED",
    "requested_at": 9017542
  }
]

Claim redemption requests

With both a request redeem ID and withdrawal event ID you can submit a claim for the redemption calling the claimRedeemRequests function.

Request:

const arrRequestId = [18];
const arrWithdrawalId = [10];

//Get estimate for gas limit
const claim_estimation = await LsETHContract.estimateGas.claimRedeemRequests(
  arrRequestId,
  arrWithdrawalId,
  { gasLimit: 1 }
);

const claimRedeemRequests = await LsETHContract.claimRedeemRequests(
  arrRequestId,
  arrWithdrawalId,
  { gasLimit: claim_estimation }
);
const receipt = await claimRedeemRequests.wait();
console.log(claimRedeemRequests);

After making a claim there will be two events triggered, which will be inspected next in this guide.

ClaimedRedeemRequest event

On successfully claiming a redeemRequest, a ClaimedRedeemRequest event is emitted. This event indicates the amount of LsETH claimed, the amount of ETH sent to the recipient, and the remaining LsETH amount that has been satisfied but not yet claimed.

A remaining LsETH amount of 0 means the request has been fully claimed. If the amount is greater than 0, the request has been partially claimed and another claim will be required to fully claim the request.

Request:

redeemManagerContract.on(
  'ClaimedRedeemRequest',
  (
    redeemRequestId,
    recipient,
    ethAmount,
    lsEthAmount,
    remainingLsEthAmount
  ) => {
    console.log('ClaimedRedeemRequest event');
    console.log(`Redeem Request ID ${redeemRequestId}`);
    console.log(`Recipient of redeem request ${recipient}`);
    console.log(`Amount of ETH ${ethAmount.toString()}`);
    console.log(`Amount of LsETH ${lsEthAmount.toString()}`);
    console.log(`Amount of remaining LsETH ${remainingLsEthAmount.toString()}`);
  }
);

Response:

ClaimedRedeemRequest event
Redeem Request ID 18
Recipient of redeem request <WALLET ADDRESS>
Amount of ETH 10209790
Amount of LsETH 10000000
Amount of remaining LsETH 0

SatisfiedRedeemRequest event

On successfully claiming a redemption request one or more SatisfiedRedeemRequest events are emitted.

Those events provide details about the withdrawal events that have satisfied a redemption request.

Request:

redeemManagerContract.on(
  'SatisfiedRedeemRequest',
  (
    redeemRequestId,
    withdrawalEventId,
    lsEthAmountSatisfied,
    ethAmountSatisfied,
    lsEthAmountRemaining,
    ethAmountExceeding
  ) => {
    console.log('SatisfiedRedeemRequest event');
    console.log(`Redeem Request ID ${redeemRequestId}`);
    console.log(`Withdrawal ID ${withdrawalEventId}`);
    console.log(`Amount of LsETH satisfied ${lsEthAmountSatisfied.toString()}`);
    console.log(`Amount of ETH satisfied  ${ethAmountSatisfied.toString()}`);
    console.log(
      `Amount of LsETH left to satisfy ${lsEthAmountRemaining.toString()}`
    );
    console.log(
      `Amount of ETH added to buffer  ${ethAmountExceeding.toString()}`
    );
  }
);

Response:

SatisfiedRedeemRequest event
Redeem Request ID 18
Withdrawal ID 10
Amount of LsETH satisfied 10000000
Amount of ETH satisfied  10209790
Amount of LsETH left to satisfy 0
Amount of ETH added to buffer  163

eth/v0/redeems

An alternative approach is to use the Alluvial API to call the /redeems endpoint, as it will return the status of both satisfaction and claim status.

Request:

curl -X 'GET' \
  'https://api.staging.alluvial.finance/eth/v0/redeems?owner=<WALLET ADDRESS>' \
  -H 'accept: application/json' \
  -H 'Authorization: Bearer e...jk'

Response:

Below the endpoint returns that this request redeem has been fully satisfied and claimed.

{
  "id": 18,
  "withdrawal_event_id": -3,
  "total_amount_lseth": "10000000",
  "claimed_amount_lseth": "10000000",
  "claimable_amount_lseth": "0",
  "max_redeemable_amount_eth": "10209790",
  "owner": "<WALLET ADDRESS>",
  "height": "4980971589354881813",
  "status_claim": "FULLY_CLAIMED",
  "status_satisfaction": "FULLY_SATISFIED",
  "requested_at": 9017542
}

You are now able to fully implement the redemption process for the Liquid Collective protocol!

Redemption Information

The Alluvial API exposes information about both theWithdrawal stack and Redeem queue.

Redemption height

Platforms who want visibility into the current supply (amount of withdrawals) and demand (amount of redeems) can use the /redeems_info endpoint.

Request:

curl -X 'GET' \
  'https://api.staging.alluvial.finance/eth/v0/redeems_info' \
  -H 'accept: application/json' \
  -H 'Authorization: Bearer e...jk'

Response:

Below you can see that the redeem queue is greater than the withdrawal stack. This indicates that more supply is needed to fulfill the redeem requests. Additional supply can enter via more deposits and/or exiting a validator.

{
  "total_amount_withdrawal_stack_lseth": "204462016832064499274",
  "total_amount_redeem_queue_lseth": "237456822758541259805"
}

In addition to exposing the Withdrawal stack and Redeem queue, Alluvial exposes an estimated time when redeems will be fulfilled.

Request:

curl -X 'GET' \
  'https://api.staging.alluvial.finance/eth/v0/redeems_info/projection'\
  -H 'accept: application/json' \
  -H 'Authorization: Bearer e...jk'

Response:

The current projections timestamp logic is:

• If the timestamp is in the past, it means that there is enough supply to fulfill demand and Alluvial returns the timestamp associated with the latest redeem request.

• If the timestamp is in the future, it means there isn't enough supply to fulfill demand and time is needed to add supply into the Withdrawal stack.

{
  "projected_fulfilled_at": "2023-06-15T11:02:24Z"
}

Appendix

Full Code

Full code for making deposit transaction

const { ethers } = require('ethers');
const Contract = require('../Contract.json');
const walletAddress = '0xbe79ff177a8F6a0D9656cF47D8687f43666a4d1e';

(async () => {
  const nodeUrl = 'https://ethereum-holesky.core.chainstack.com/<ID>';
  const provider = new ethers.providers.JsonRpcProvider(nodeUrl);

  const gasPrice = await provider.getGasPrice();

  const signer = new ethers.Wallet('<INSERT WALLET PRIVATE KEY>', provider);

  const riverContract = new ethers.Contract(
    Contract.address,
    Contract.abi,
    signer
  );

  const value = ethers.utils.parseEther('0.000000000001');

  //Get estimate for gas limit
  const redeem_estimation = await riverContract.estimateGas.requestRedeem(
    value,
    walletAddress,
    { gasLimit: 1 }
  );

  // Create Redeem Request
  let tx = await riverContract.requestRedeem(value, walletAddress, {
    gasLimit: redeem_estimation,
  });

  // ***** Start resolve redeem function block *****
  // Uncomment when running claimRedeemRequests()
  //let arrRequestId = [18];

  //let resolveRedeem = await LsETHContract.resolveRedeemRequests(arrRequestId);
  // console.log(resolveRedeem.toString())
  // ***** Stop resolve redeem function block *****

  // ***** Start claiming function block *****
  // Get estimate for gas limit
  // const claim_estimation = await LsETHContract.estimateGas.claimRedeemRequests(arrRequestId, arrWithdrawalId, { gasLimit: 1});

  //let arrRequestId = [18];
  //const arrWithdrawalId = [10]

  //const claimRedeemRequests = await LsETHContract.claimRedeemRequests(arrRequestId, arrWithdrawalId, { gasLimit: claim_estimation});
  //const receipt = await claimRedeemRequests.wait();
  //console.log(claimRedeemRequests);
  // ***** end claiming function block *****
})();

/redeems response payloads

The redemption process is very dynamic. You can see a matrix of all the redeem statuses here. Below will show the difference between response payloads when requesting from either:

• eth/v0/redeems/18

• eth/v0/redeems?owner=

NOT_CLAIMED & PENDING_SATISFACTION

Why would this state happen?

• This is the initial state for all redeem requests.

{
  "id": 1,
  "withdrawal_event_id": -1,
  "total_amount_lseth": "1000000",
  "claimed_amount_lseth": "0",
  "claimable_amount_lseth": "0",
  "max_redeemable_amount_eth": "1023507",
  "owner": "<WALLET ADDRESS>",
  "height": "201956822758540259700",
  "status_claim": "NOT_CLAIMED",
  "status_satisfaction": "PENDING_SATISFACTION",
  "requested_at": 9134158
}

NOT_CLAIMED & PARTIALLY_SATISFIED

Why would this state happen?

• This happens when the redemption request can be partially satisfied and the owner has not made a claimRedeemRequest against the redeem request.

• Notice that the claimable_amount_lseth is greater than 0 but less than the total_amount_lseth.

{
  "id": 1,
  "withdrawal_event_id": 1,
  "total_amount_lseth": "1000000",
  "claimed_amount_lseth": "0",
  "claimable_amount_lseth": "900000",
  "max_redeemable_amount_eth": "1023507",
  "owner": "<WALLET ADDRESS>",
  "height": "201956822758540259700",
  "status_claim": "NOT_CLAIMED",
  "status_satisfaction": "PARTIALLY_SATISFIED",
  "requested_at": 9134158
}

NOT_CLAIMED & FULLY_SATISFIED

Why would this state happen?

• The amount of supply can fully satisfy the amount of LsETH being redeemed in this request.

• Notice that total_amount_lseth == claimable_amount_lseth

{
  "id": 1,
  "withdrawal_event_id": 1,
  "total_amount_lseth": "1000000",
  "claimed_amount_lseth": "0",
  "claimable_amount_lseth": "1000000",
  "max_redeemable_amount_eth": "1023507",
  "owner": "<WALLET ADDRESS>",
  "height": "201956822758540259700",
  "status_claim": "NOT_CLAIMED",
  "status_satisfaction": "FULLY_SATISFIED",
  "requested_at": 9134158
}

PARTIALLY_CLAIMED & PENDING_SATISFACTION

Why would this state happen?

• The owner has claimed part of redeem request before the redeem request was fully satisfied. More supply will need to be added, hence the withdrawal_event_id is == -1, whereas before there would have been a positive integer associated with the withdrawal_event_id (ex. 0, 1, 2, etc...).

• Note that claimed_amount_lseth is equal to previously claimed amount.

{
  "id": 1,
  "withdrawal_event_id": -1,
  "total_amount_lseth": "1000000",
  "claimed_amount_lseth": "900000",
  "claimable_amount_lseth": "0",
  "max_redeemable_amount_eth": "1023507",
  "owner": "<WALLET ADDRESS>",
  "height": "201956822758540259700",
  "status_claim": "PARTIALLY_CLAIMED",
  "status_satisfaction": "PENDING_SATISFACTION",
  "requested_at": 9134158
}

PARTIALLY_CLAIMED & PARTIALLY_SATISFIED

Why would this state happen?

• The owner has claimed part of redeem request before the redeem request was fully satisfied. More supply was found, however not enough to fully satisfy this redeem request.

• In the example below you can see that total_amount_lseth > claimed_amount_lseth + claimable_amount_lseth. There is 40000 LsETH still left to fully satisfy this request.

{
  "id": 1,
  "withdrawal_event_id": 2,
  "total_amount_lseth": "1000000",
  "claimed_amount_lseth": "900000",
  "claimable_amount_lseth": "60000",
  "max_redeemable_amount_eth": "1023507",
  "owner": "<WALLET ADDRESS>",
  "height": "201956822758540259700",
  "status_claim": "PARTIALLY_CLAIMED",
  "status_satisfaction": "PARTIALLY_SATISFIED",
  "requested_at": 9134158
}

PARTIALLY_CLAIMED & FULLY_SATISFIED

Why would this state happen?

• The owner has claimed part of redeem request before the redeem request was fully satisfied.

• In the example below you can see that total_amount_lseth = claimed_amount_lseth + claimable_amount_lseth.

{
  "id": 1,
  "withdrawal_event_id": 2,
  "total_amount_lseth": "1000000",
  "claimed_amount_lseth": "900000",
  "claimable_amount_lseth": "100000",
  "max_redeemable_amount_eth": "1023507",
  "owner": "<WALLET ADDRESS>",
  "height": "201956822758540259700",
  "status_claim": "PARTIALLY_CLAIMED",
  "status_satisfaction": "FULLY_SATISFIED",
  "requested_at": 9134158
}

FULLY_CLAIMED & FULLY_SATISFIED

Why would this state happen?

• This is final state for all redeem requests. This indicates that the redeem request has been fully satisfied.

• total_amount_lseth == claimed_amount_lseth and claimable_amount_lseth == 0

• withdrawal_event_id reflects this state with the -3 ID.

{
  "id": 1,
  "withdrawal_event_id": -3,
  "total_amount_lseth": "1000000",
  "claimed_amount_lseth": "1000000",
  "claimable_amount_lseth": "0",
  "max_redeemable_amount_eth": "1023507",
  "owner": "<WALLET ADDRESS>",
  "height": "201956822758540259700",
  "status_claim": "FULLY_CLAIMED",
  "status_satisfaction": "FULLY_SATISFIED",
  "requested_at": 9134158
}

This guide walks users through how to use authenticate requests using the Alluvial APIs.

Client Credentials Flow

Below is a ladder diagram showing the flow to create an access token.

This flow involves 3 parties:

• Platform Server: the client looking to access the Alluvial API and which has previously been given a Client ID and Client Secret credentials.

• Alluvial Authorization Server: responsible for validating credentials and generating JWT Access Token.

• Alluvial API: the target resource to be accessed.

Getting Access Token

To obtain an access token, use the a request below using your client id and secret.

Request:

Response:

Refreshing Access Token

Access Token should be reused for every request until it expires, in which case they should go through the Client Credential Flow again to obtain a fresh Access Token.

Sample request

To use the access token, pass it via the HTTP header Authorization: Bearer

If you receive a 2xx response, you are now able to make fully authenticated requests.

If you receive a 4xx response, check if your access token is expired.

Alluvial exposes several APIs to help developers interact with the Liquid Collective Protocol.

API-Reference

This page shows the process for creating an access token.

1. When onboarding with Alluvial, you will receive API credentials. These include a client_id and client_secret.

2. After receiving your credentials use the curl request below, updating the client_id and client_secret with your specific credentials.

Staging

Response

Production

Request

Response

Platform

Platform Account Operations

Platform Wallet Operations

Platform Account Wallet Operations

Redemption API is a collection of APIs that expose read data on redemptions.

To see APIs used in an example implementation check out the Redemption guide (below).

Alluvial exposes several non-authenticated APIs to support DApps

Ethereum Data API is a collection of APIs that expose read data from the Ethereum network.

Alluvial's APIs can also interact with other third party services, such as those offered by third party custodians that Platforms may use to custody funds staked using Liquid Collective.

Please note that these guides are to support Platforms who are connecting with third party products that are not offered by or in partnership or affiliation with Alluvial. Products and services offered by third parties are subject to separate terms and conditions. Visit the website of the third parties noted in these guides for more information on their offerings.

APIs that allow Platforms to create target discount schedules.

Reporting API is a collection of APIs Platforms use to get information about Liquid Collective Protocol Service Fees.

Public endpoints (no authentication required)

Private endpoints ( authentication required)

Reward Summary

Alluvial's changelog records changes made to the Alluvial API specification, including new features, improvements, bug fixes, and more.

July 9, 2024

• Discounting APIs are live! These APIs enable adding a new target rate in the event Platforms need to adjust the net Protocol Service Fee rate for specific accounts and/or wallets.

• Summary APIs are now exposed within the Reporting API. Summary APIs allow for teams to get data for a range of dates rather than a specific day.

May 17, 2024

April 24, 2024

March 25, 2024

On-Platform list

• When creating a wallet, Platforms that allow for minting and redeeming, but only want to allow a wallet for secondary interactions can add these wallets to the on_platform list.

Platform APIs

May 5th, 2023

Release redeems APIs

• Expose redemption requests by address via /eth/v0/redeems

• Expose redemption requests by id via /eth/v0/redeems/{idx}

• Expose redemption manager (heights) via /eth/v0/redeems_info

May 18th, 2023

Release projection APIs for LsETH redemptions

• Expose redeem projected redeemable at timestamp via /eth/v0/redeems/{idx}/projection

• Expose manager projected fulfilled at timestamp via /eth/v0/redeems_info/projection

November 20th, 2023

• Remove address from Allowlister via PATCH /v0/depositors/{idOrKey}/wallets/{idOrAddress}/remove

Rather than removing the entire Depositor object, Platforms can now remove only the wallet address. This is the recommended approach for most cases where an a Platform needs to revoke a wallet address' Allowlist permissions.

The wallet will is still able to transfer LsETH to other wallets.

Alluvial's reporting API enables Platforms to request the ETH network rewards that their users have received. Below are two guides:

1. Platforms with omnibus account structure.

2. Platforms with segregated account structure.

Omnibus account structure

Platforms that support an omnibus structure should use the /eth/v0/rewards endpoint. This will return data in a lots structure. Lots represent LsETH balance changes for a given period. Rewards can then be calculated for each period. Total rewards for a user is the sum of rewards for each lot.

Below is an example request where a Platform wants to see the rewards for a wallet. Assume that the user has a total balance of 3 but acquired at different dates.

• The user had 1 LsETH from 2024-04-01 to 2024-04-10. As such this will be the first lot added to the request body.

• The user then acquired 2 more LsETH, for a total of 3, as of 2024-04-11.

In our request below assume that the current date for which we want data is til 2024-04-15.

Request

Response

Segregated account structure

Platforms that support a segregated structure can use two different endpoints to get reward data at the account or wallet level.

List rewards by account(s)

Use the endpoint /eth/v0/rewards/accounts to display ETH network rewards at the account level.

Request

Response

Below is the response show the aggregated rewards for the account in addition for each address.

List rewards by wallet(s)

Use the endpoint /eth/v0/rewards/wallets to display ETH network rewards at the wallet level.

Request

Response

Below is the response showing the aggregated rewards for the account in addition for each address.

Staking Reward Rate

The Alluvial API provides a staking rewards rate (SRR), which is calculated as a 7 day trailing average.

Request

Response

Based on providing a specific date of 2024-05-01, the returned SRR is 2.85%.

Discounting API

Platforms that want to provide a custom discount to their users can use the Discounting APIs to offload the calculations of a discounted net Protocol Service Fee to Alluvial's enterprise accounting service. Platforms can then use the API to call ETH network rewards, Protocol Service Fees, and end user discounts for one or more wallets or user accounts.

First, you will set a new target fee rate. This represents the new gross Protocol Service Fee rate that will be calculated for an account and/or wallet.

Request

The target fee rate is now set at 8%.

Response

On each Oracle report, you can use the Reporting APIs to see discounted values for the associated account, including the discounted net Protocol Service Fee, ETH network rewards received adjusted for that Fee, and effective end user discounts.

Request

In the response below, you can see that the rebate_eth or rebate_lseth will reflect the amount the wallet is attributed to be reimbursed in order to achieve the the 8% target fee rate (or conversely, a 2% discount on the gross Protocol Service Fee).

Response

The discount data is exposed via the following API endpoints:

• /rewards/wallets

• /eth/v0/rewards/accounts/:idOrKey/summary

• /eth/v0/rewards/wallets/:idOrKey/summary