Architecture
This guide is intended for Platforms to learn about how they can integrate the Liquid Collective protocol with the support of Alluvial's APIs.
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.
Architectural components in the Acme Infrastructure box are for illustrative purposes.
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).
Architectural components in the Acme Infrastructure box are for illustrative purposes.
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.
Review the Depositor states (deny, pause, reactivate, and remove) as applying these states will impact all underlying customers.
Last updated
