🔦Expanded Scoping Manual
This page dives deeper into the platform and asset/liability pair scoping process. It seems simple, but can get complex! If that's the case, this manual is for oyu!
1. Determining the In-Scope Platforms (Expanded Manual)
Methodology
To execute a Proof of Reserves, the first step for a custodian is to ascertain which digital asset platforms can, should, and are preferable to include within the scope of the custodian’s Proof of Reserves.
Custodian: Any entity holding digital assets on behalf of another party.
This sounds like a relatively straight-forward task, and it certainly can be, especially if there is only 1 platform related to the custodian. However, more-often-than-not, multiple platforms exist, making the determination of in-scope platforms one of the more complicated areas of the Proof of Reserves process.
Digital Asset Platform: An “app” or platform used by customers to store, buy, sell, lend, earn, stake and conduct other digital asset financial activities whereby the custodian controls the underlying assets on behalf of account holders. Customers trust digital asset platforms to custody the “real” assets, and receive account balances (i.e. IOUs issued from the digital asset platform) in return. Example DA platform types include Centralized Exchanges, Lending/Saving Platforms, Futures Platforms, and even obscure situations like Mining Pool Accounts. Specific examples include Coinbase, Binance, and Cash App.
To demonstrate the point, let’s start with a quick example scenario. Kraken has a spot exchange where users can buy, trade, and store digital assets. Kraken also has a separate, but related futures exchange platform, where users can trade futures contracts.
Which platforms are to be included in the Proof of Reserves? Should one, both, or neither complete a Proof of Reserves? Easy, just include both, no problem…. right?
Well, it’s not always that easy. What if a completely different corporate entity manages the Spot platform vs. the Futures platform, or what if the customer accounts are managed in a different database by teams in different parts of the world, or what if a Company’s Custody platform holds customer assets that are commingled with Company’s Spot account assets but not it’s Futures accounts assets. In practice, idiosyncratic circumstances are closer to the norm than the exception.
Moreover, many other Company’s in the space have become de-facto crypto-conglomerates, potentially managing spot, futures, yield-bearing, and even other types of crypto platforms. The Coinbase “umbrella” of entities includes Coinbase Prime, Coinbase Pro, Coinbase Custody, and a myriad of other “platforms.” The Binance “family” of exchanges include Binance.com, Binance.US, Binance.UK, Binance Singapore, and more. OKGroup, Huobi, ByBit, the list goes on.
These platforms related to a single entity may sometimes have completely segregated entities, management teams, customer account databases and custodial arrangements. Other times, the 2+ platforms are completely intertwined, with the same management team, same customer account databases, and commingled customer assets. For every company operating at either end of the spectrum, there are 10 more operating somewhere in the middle, which catalyzes the most complex of scoping scenarios.
So, we again ask ourselves, which platforms are to be included in the Proof of Reserves? We start to realize that the answer is not so simple. However, this is the task at hand and decisions must be made. So, to make educated and thoughtful determinations about which platforms should be included within the scope of the Proof of Reserves, we should consider key platform scoping factors.
Platform Scoping Factors
Customer Account Balance Tracking
For the prospective platforms, how are the customer account balances tracked? For example, are the Spot platform customer balances tracked and managed in the same balance/table/database as the Futures platform customer balances? Or, are they clearly bifurcated? This is not a question of the “right” way to construct a customer account database or trading engine, but rather how to operationally execute a PoR.
Custodial Arrangement of Assets
Are the assets from one platform commingled with assets held on behalf of another platform (i.e. Spot & Futures platform)?
One entity may custody the funds for multiple platforms. For example, Binance.com is the custodian for Binance.com customers, but it may also serve as the custodian for Binance.US, Binance.UK and more. Would it be possible to clearly delineate which assets are reserving which entity’s customers?
Demonstrability to Auditors and/or the Public
The custodian should be able to demonstrate to an auditor (or public) that the liabilities and the associated collateral assets for the in-scope platforms are not related to the other platforms. The key “platform-level” risk is the custodian using funds from another platform to overstate (i.e. double count) assets for the in-scope platform to pass the Proof of Reserve. This is the key risk the auditor will be looking to mitigate.
Who Chooses what Platforms are in Scope?
As of now, the scope of the Proof of Reserves is determined by the custodian. Until regulatory or other standards are established, the custodian generally determines the scope of Proof of Reserves. However, it is possible, if the custodian is using an auditor, that the auditor will only feel confident executing the procedures if the auditor considerations are included within the scope determinations.
Questions for the Custodian to Consider
Can one or all of these platforms be included within the scope of the PoR? Said another way, are the reporting capabilities for both customer accounts and the underlying assets collateralizing those accounts sufficient to execute a PoR? Would it even be possible to execute a PoR for one platform and not the other? Or are they sufficiently segregated whereby a “stand-alone” PoR would be possible? After pondering the technical considerations and limitations, what platforms are feasible to include or exclude from the scope of the PoR?
Should one or all of these platforms be included within the scope of the PoR? What are my customers looking for? What would be the most forthright approach to execute this Proof of Reserves?
Would it preferable for the Company to include one or all of these platforms be included within the scope of the PoR? Said another way, does the Company even want to report on all of the potential platforms? Is the time, effort, and cost worth it?
After answering these questions, a custodian will likely have determined which platforms to include within their Proof of Reserves.
In Exhibit A, Platform X could fraudulently pass the Proof of Reserves if they use “Other Assets held on behalf of other Platforms” to contribute to (fraudulently) collateralizing Platform X’s Customer Liabilities. This is a risk that the Company and/or the auditor will be tasked with mitigating and communicating that mitigation strategy to the public.
Tips & Tricks for Management
To give Management the most optionality in PoR scope, clearly segregate key databases/tables that track Customer Liabilities balances by platform. This will enable Management the ability to “pick and choose” which platforms they would like to complete a PoR for.
To give Management the most optionality in PoR scope, clearly segregate assets that collateralize customer liabilities by platform. This will enable Management the ability to “pick and choose” which platforms they would like to complete a PoR for.
Create a platform diagram of all of the company’s key platform databases and underlying custodial arrangements. This diagram can be used to help an auditor or the public understand scope and segregation across related platforms.
Have a preliminary strategy to demonstrate the segregation of customer liability databases and assets (if needed)
To demonstrate segregated databases/tables, the custodian could drive a “walkthrough” where they show the auditors a list of databases, tables, and how they are stored, etc.
To demonstrate segregated assets, the custodian could drive a “walkthrough” where they show (generally) the auditors how the private keys are stored and used for signing. Additionally, the custodian could provide a list of addresses from both the in-scope and out-of-scope platforms and demonstrate that the addresses are not the same, corroborating that assets are not used to collateralize liabilities for both entities.
Unique Challenges & Resolutions
Platforms with a Shared Pool of “Commingled” Assets: If a custodian commingles assets from multiple platforms, the best practice would be to include both platforms within the scope of the Proof of Reserves. If both platforms (i.e., set of liabilities) are not included within the scope of the PoR, a custodian would effectively be understating the claims (i.e. liabilities) on the assets that are being used for the Proof of Reserves.
Management Outputs:
In Exhibit B, two platforms are collateralized by the same pool of assets. In order to fairly “scope” the liabilities for these asset/liabilities pairs, both platforms should be in scope for the assessment.
Examples from the Field
Kraken has both a Spot and Futures platform. However, they only scoped-in the Kraken Spot Exchange for their Proof of Reserve Engagements executed during 2021 and 2022. Kraken was able to clearly bifurcate customer accounts and associated assets for the purposes of the PoR.
Illustrative Example
Throughout this manual, we will use a fictitious example scenario to demonstrate the key points from the relevant Step.
The fictitious example describes the scenario BitNau Crypto Company. BitNau Company Crypto Company includes many different platforms and services. BitNau Crypto Company “family” of platforms and services include:
BitNau Spot Platform: a platform where customers can buy, sell and hold assets.
BitNau Futures Platform: a platform where customers can “bet” on the future price of bitcoin using futures contracts.
BitNau Yield Platform: a platform where customers can deposit bitcoin and earn yield. BitNau will lend assets to counterparties and deploy assets into Defi and pass that yield to customers.
BitNau Bridging Service: a service where users can wrap bitcoin and “bridge” it to NauChain. The native bitcoin and custodied by BitNau’s bridging service until users redeem their NauBTC at a future time.
When determining which platforms to include for the BitNau’s first Proof of Reserves, BitNau realized that many of it’s customer claims (for Spot, Futures, and Bridging) were all collateralized by assets held in the same “pool” (or set of wallets). Assets were not specific to which platform they were “backing.” So, to appropriately scope which platforms should be included, BitNau determined that the only fair representation of assets would be to compare the commingled assets against all platform liabilities for which they were intended to collateralize. Therefore, BitNau determined that the Spot, Futures, and Bridging Service must all be included within the scope of the PoR, even though the Customer Liability databases for each platform were managed separately, because the underlying assets were pooled to collateralize all platforms.
The BitNau Yield Platform is a different story. The customer database and assets held on behalf of BitNau Yield customers are completely segregated from the rest of the other BitNau platforms. Therefore, the BitNau Yield platform could be included or be excluded from the scope of the first Proof of Reserves because of it’s clear bifurcation from the other platforms. To provide the most transparency to customers, BitNau opted to include the BitNau Yield Platform within the scope of the PoR.
2. Determining the In-Scope Asset/Liability Pairs (Expanded Manual)
Methodology
The next step for a custodian is to ascertain which custodial asset/customer liability pairs can, should, and are preferable to include within the scope of the custodian’s Proof of Reserves.
Like determining in-scope platforms, determining which custodial asset/customer liability pairs can be covertly tricky. In fact, this step is likely the trickiest part of the scoping exercise.
However, let’s not get lost in the technicalities yet. Let’s start with some of the key concepts.
Examples of Asset/Liability Pairs [Asset/Liability, Asset Holder, Liability Issuer]:
10 Tesla Stock on Robinhood Account, Retail Robinhood User, Robinhood
$1,000 Bank Account Balance, Retail Bank Customer, Bank
$5 on Venmo, Venmo Account Holder, Venmo
1 BTC Balance on Coinbase, Coinbase User, Coinbase
Custodial Assets: Crypto assets or fiat held on behalf of customers of a platform.
Customer Liabilities (aka Platform Customer Liabilities, Customer Account Balances): Liabilities created when a user deposits an asset onto an exchange platform in return for a promise from the exchange to provide the deposited assets at a future withdrawal date.
A Quick Primer on Asset/Liability Pairs in the Financial System
Before we get too lost, what am I even talking about when I say an “asset/liability pair?” I am glad you asked! The concept of asset/liability pairs can be summed in one thoughtful quote:
One man’s asset is another man’s liability
What does this mean exactly? Well, it implies that many financial instruments that people perceive as "assets" are, in fact, also liabilities (IOUs) issued by another party. This asset/liability relationship often exists without people realizing it. Some examples are easy to understand. For instance, a US Treasury is an asset that pays interest to the holder. Simultaneously, a US Treasury is a liability for the US Government to pay cash and interest. Interestingly enough, practically every "asset" that someone "owns" is a liability of another party unless that asset is a bearer asset and has no counterparty risk. This implies that most assets rely on the liability issuer to fulfill their promise to pay. Counterparty risk is the chance that the liability issuer fails to fulfill their promise to pay their IOU.
When the system is functioning, the "asset" holder can redeem their IOU with the liability issuer to receive the underlying asset. This action destroys the asset/liability pair. Once a liability issuer has fulfilled their obligations, they no longer have the liability, and the asset holder holds the underlying asset, not the IOU from the original issuer.
Let’s use an example to illustrate the point. Suppose I have $5 on Venmo, and I request a withdrawal, receiving the funds in the bank.
Start: I own a promise from Venmo to pay me $5 when I ask them. Venmo owes me $5. The "asset" I hold is a Venmo IOU, and the liability created by Venmo is the $5 they owe me.
End: I own no promise from Venmo anymore, and they owe me no money. I simply have $5 in my bank account. The asset (Venmo IOU)/liability (Cash) pair no longer exists. Venmo has been relieved of their obligations.
If, for some reason, the Venmo Treasurer spent all the real money, and there was no money left for me when I asked Venmo to redeem my IOU, that’s when problems would arise. This is precisely why we look to utilize Proof of Reserves.
However, the point of this exercise is to demonstrate that most "assets" owned today are also liabilities issued by a counterparty. This is what we mean by asset/liability pairs in the context of Proof of Reserves. Each asset/liability is essentially a financial instrument with the associated "asset holder" and "liability issuer" identified.
Additionally, when an asset/liability pair exists, counterparty risk also exists, necessitating the need for Proof of Reserves to ensure the liability issuer has enough assets to fulfill their IOUs.
In a perfect world, the asset/liability pairs would be clearly bifurcated and easily defined. However, the world is usually much more messy than that.
In our Venmo example above, we made some assumptions. We assumed Venmo has one bank account to holds all customer funds, but what if it was more complicated than that?
What if Venmo has multiple banks the hold funds “backing” Venmo account balances?
What if the bank accounts holding user funds are “commingled” with Company assets?
What if Venmo takes the customer cash and buys other assets with them, like US Treasuries or Tesla Stock?
There are an infinite amount of variations and complications that could potentially muddy the asset/liability pairing waters, especially when you sprinkle some opaque overseas exchanges and complicated crypto assets on top.
So, with that primer in hand, let’s dive into asset/liability pairs in the crypto world.
Asset/Liability Pairs in the Crypto World
For most custodians and auditors attempting to execute a PoR, the initial inclination is to ask, “What assets are to be in scope?” However, complications arise when a custodian realizes that the BTC assets held in reserve actually collateralize multiple BTC-denominated customer liability types. Additionally, the reserve can be true, where multiple customer liability types are collateralized by one pool of assets. Accurately scoping these "one-to-many" and "many-to-one" asset/liability pair relationships can be one of the most complex aspects of the Proof of Reserves process.
We will begin by discussing these asset/liability pair types:
One Customer Account Balance Type collateralized by One Homogeneous Pool of Assets
Multiple Customer Account Types collateralized by One Homogeneous Pool of Assets
One Customer Account Type collateralized by a Heterogeneous Pool of Assets
Once we comprehend the types of asset/liability pairs that exist, we can then determine how to compare the two to ensure that the liabilities issued by the issuer are adequately reserved. However, before proceeding, we need to establish which assets are intended to back which liabilities.
The Simple Case: One Customer Account Type Collateralized by One Homogeneous Pool of Assets
Let's discuss the "perfect world" scenario first. Suppose a crypto exchange operates a straightforward spot trading platform where users can buy and sell BTC. When users deposit BTC onto the platform, the platform securely holds the BTC in custody on behalf of its users.
The financial instrument with the asset/liability pair is the Platform Account Balance. In this case, identifying and understanding the asset/liability pair is straightforward. Upon depositing BTC onto the platform, the platform incurs a liability to repay the depositor 1 BTC. The platform user is the asset holder in this relationship, and the liability issuer is the platform itself.
To execute a Proof of Reserve for this asset/liability relationship, the process would be relatively simple. One would need to extract all BTC platform balances and sum all associated BTC held in custody. There are no complicated situations where assets are commingled or multiple claims (liabilities) on the underlying assets exist. It's straightforward.
Even if the Platform supports ETH deposits on a 1-to-1 basis, the same principles apply. We would duplicate the methodology used for the BTC Platform account balances.
However, if Platform X receives ETH, swaps it for BTC, and uses it to back ETH Customer Account Balances, we would have a different story. Which we'll discuss below.
A Complicated Case: Multiple Customer Account Types Collateralized by One Homogenous Pool of Assets
To illustrate this point, consider an example. Suppose a Digital Asset platform offers various services, including Spot Trading Accounts, Margin Trading Accounts, and Interest Accounts. Imagine holding 1 BTC in each of these distinct account types.
Typically, upon logging in, you might observe a consolidated BTC balance of 3 BTC. However, more likely, you will see separate accounts, each displaying a balance of 1 BTC. These balances are bifurcated because they represent different account types on the platform. These 'account types' are usually tracked and managed independently of each other, even though all balances are denominated in bitcoin.
Additionally, these three account balance (customer liability) types are all collateralized by a native, on-chain pool of bitcoin custodied by the platform.
In these cases, excluding certain customer account balance types may be impossible due to the pooling (commingling) of associated assets. Therefore, any customer liability types sharing the same "pool" of collateral assets should typically be included in the Proof of Reserves (unless a corresponding asset bifurcation can be made). Excluding customer liability types that share the same pool of "reserves" may make it impossible to accurately compare all claims on the associated pool of assets. Additionally, these circumstances increase the risk of a custodian understating liabilities associated with the underlying assets.
Another Complicated Case: One Customer Account Types Collateralized by a Heterogenous Pool of Assets
Additionally, the asset/liability "mapping" exercise can also "go the other direction," whereby one customer liability type can be collateralized by multiple assets. In some cases, characterizing the assets as "different" may be open for debate, but the key factor is that the nature of the underlying assets is different enough to prompt specific PoR procedures for each.
To illustrate this point, consider an example. Suppose a digital asset platform enables customers to hold a USDT balance on their platform (i.e., an account balance on their platform's database). However, the USDT custodied by the platform to collateralize those USDT liabilities is issued on different blockchains:
USDT issued on Ethereum
USDT issued on Tron
USDT issued on Solana
Additionally, when a user withdraws, they may have the option to withdraw on each of the supported chains.
However, when a customer logs into their platform account, the customer "owns" or holds a "fungible" USDT account balance on the platform. The USDT "credit" or IOU on the platform is not specified as USDT on Tron, Ethereum, or Solana. The underlying assets are all denominated in USDT but are actually different assets. However, this technical difference is obfuscated from the users. To a user, they just hold USDT, regardless of the underlying chain it is issued on.
So, this 1 account balance (customer liability) type (USDT) is technically collateralized by 3 different (albeit similar) assets: USDT on Tron, Ethereum, and Solana.
In these cases, it may be impossible to exclude certain assets because the associated customer liability uses multiple assets to collateralize a single liability. Therefore, any assets that collaboratively collateralize the same customer liability type should also typically be included in the Proof of Reserves (unless a corresponding liability bifurcation can be made).
If some of the assets contributing to the collateralization of a customer liability are excluded, the custodian may be understating their reserves. This is much less of a risk than understating liabilities. However, most of the time, custodians prefer to show as many assets as possible.
Identifying the In-Scope Asset/Liability Pairs
Now that we understand the most likely scenarios encountered during the asset/liability pair scoping exercise, the platform can initiate the process of determining which pairs to include within the scope of the Proof of Reserve.
In the scoping exercise, we recommend starting with a list of Customer Platform Liabilities and then identifying the associated asset pools. Once the liability and associated assets have been identified, the platform can then decide on the scope of the PoR. It's typically beneficial to also have a description of the nature of each liability. You might be surprised that sometimes Management has not contemplated these asset/liability pairs before a PoR.
In practice, we find that building out a modified "T-Account" or a "Balance Sheet" is the easiest way to accomplish this exercise. The reason why we say "modified" is because we prefer placing the Platform Account Liabilities on the left (as we are starting with this list).
Then, Management should ensure that no other platform liability types also have a claim on the same pool of assets identified. By excluding certain liabilities that have a claim on the same pool of assets, Management would be understating its assets, even if done without malicious intent.
Questions for the Custodian to Consider:
Can one or all of these asset/liability pairs be included within the scope of the PoR? In other words, are the relationships between the asset and liability determinable and auditable? Or does the platform need to consider other claims on the same pool of assets? Would it even be possible to execute a PoR for one liability type and not the other? Or are the underlying assets sufficiently segregated, whereby one platform liability could be included and not another? After pondering the technical considerations and limitations, what asset/liability pairs are feasible to include or exclude from the scope of the PoR?
Should one or all of these asset/liability pairs be included within the scope of the PoR? What are my customers looking for? What would be the most forthright approach to execute this Proof of Reserves?
Would it be preferable for the Company to include one or all of these asset/liability pairs within the scope of the PoR? In other words, does the Company even want to report on all of the potential platforms? Is the time, effort, and cost worth it?
After answering these questions, a custodian will likely have determined which asset/liability pairs to include within their Proof of Reserves.
Tips & Tricks for Management
For your first Proof of Reserves, try to avoid "one-to-many" or "many-to-one" asset/liability pairs if possible.
Maintain a "Balance Sheet" of a platform's asset/liability pairs.
For good operational hygiene and to make a PoR easier to execute, segregate pools of the same asset by liability type. For example, have three pools of on-chain bitcoin, one for spot trading, one for regular trading, and one for margin accounts, respectively.
Create a platform diagram of all the company's key platform databases and underlying custodial arrangements. This diagram can be used to help an auditor or the public understand the scope and segregation across related platforms.
Have a preliminary strategy to demonstrate the segregation of assets (if attempting to scope out certain liabilities and scope in assets denominated or backed by the same asset):
To demonstrate segregated assets, the custodian could conduct a "walkthrough," showing the auditors how the private keys are stored and used for signing. Additionally, the custodian could provide a list of addresses from both the in-scope and out-of-scope asset pools and demonstrate that the addresses are not the same, corroborating that the assets are not used to collateralize separate liabilities.
Unique Challenges & Resolutions
In-Kind" Asset/Liability Pairs:
We describe an asset/liability pair as "in-kind" when both the asset and the liability are denominated in the same asset. For example, this definition slightly expands the "standard case" of an asset/liability pair, where the liability is collateralized by the same exact asset.
A "standard case" example would be a BTC liability owed to customers backed by native BTC in custody. An "in-kind" definition includes the example above but also encompasses a wider set of relationships. For instance, a BTC liability owed to customers backed by wrapped BTC in custody. The asset is not necessarily backed by the same underlying asset, but it is denominated in the same asset.
All other factors being equal, in-kind collateral assets are less risky than "alternatively-backed" assets because any pricing fluctuations in the unit of account asset are offset by changes in both the asset and liability.
To demonstrate the point, let's say a platform holds 1 wBTC on behalf of BTC platform customers. A change in BTC/USD price would not affect the collateralization ratio of the platform (1 BTC/1 wBTC). Alternatively, if the platform held USDC to back BTC liabilities, price fluctuations would affect the collateralization ratio.
During the presentation of the Proof of Reserve results, it is important to disclose the nature of the in-kind assets. Additionally, it is recommended to disclose that the assets are not collateralized by the same exact asset but by collateralized assets denominated in the same asset.
Lending and Borrowing Platforms:
The nature of lending and borrowing platforms is fundamentally different from their spot platform counterparts. However, this does not mean that a Proof of Reserves is not possible; we simply need to expand our PoR methodology to account for additional circumstances.
New Assets in an Asset/Liability Pairing - Digital Asset Receivables: Up until now, we've only discussed asset/liability pairs where the liability was simply an IOU for the underlying asset that the custodian holds. For example, a user of a custodian owns an IOU for a bitcoin, and the custodian holds that bitcoin in the same form. It's purely a custodial arrangement. However, when the assets held issued by the custodian to collateralize the liability are not in the same form, they typically hold other asset types to collateralize that liability. When the liability issued pays interest to the holder, the platform may back it with some form of bitcoin receivable. Essentially, the custodian is taking the bitcoin you deposited into the platform and lending it out to other parties to earn interest. When this occurs, the platform is essentially backing (at least a part) of its obligations to its platform customers with bitcoin receivables from other parties. Now, what we have done is changed the assets backing our liabilities from bitcoin to a broader set of assets called bitcoin-denominated assets. This atypical nature of the asset base should be disclosed to all PoR users.
New Liability in an Asset/Liability Pairing (Contra-Assets) - Digital Asset Payables: At the same time, the platform may borrow assets to take advantage of market opportunities. For example, a company may borrow bitcoin at a rate of 2% from one entity, take that bitcoin, and lend it out to another entity to earn 3%. In such a situation exists, a new liability type has been created, aside from the "standard" Customer Platform Liabilities that are typically the main focus of a PoR. We could simply put these new liabilities on the "Liability side" of our balance sheet. However, the nature of these "operational" liabilities is much different than Customer Platform Liabilities. Additionally, these liability balances would not be included within the eventual Merkle Tree constructed. Therefore, we instead treat these liabilities as a subtraction of custodial assets, rather than an addition to the Customer Liability side of the balance sheet. We have elected to call these contra-assets because of the operational and unique nature of these liabilities.
In our descriptions above, we assumed that the Liability (Interest-Accruing Platform Account Liability) and Assets (bitcoin, bitcoin receivables) were denominated in the same asset. Therefore, in this situation, we note that the liabilities are collateralized by in-kind assets. The liability is not in bitcoin, but it's denominated in bitcoin. Understanding this asset/liability relationship is typically important for lending/borrowing platforms to manage risk. However, it is also very important to accurately scope and execute a Proof of Reserves. In these scenarios, the PoR would be comparing liabilities to assets denominated in the same unit of account, bitcoin in this case.
Liabilities are not always backed with "in-kind" assets, which brings us to our next unique challenge.
Alternative"-backed or "Off"-Denominated" Assets/Liability Pairs:
Lending and borrowing platforms can be extremely complex. While, in a perfect world, Platform Account Liabilities are always backed with "in-kind" assets, this is not always the case. Often, VASPs with a lending arm will receive customer deposits denominated in one asset and exchange them for assets where greater interest opportunities exist.
For example, a lending platform may receive ETH deposits from customers. Then, the VASP may swap the ETH into USDC and deploy it into a DeFi protocol to earn yield. At the same time, the VASP may open up a long position on ETH by borrowing it from another party to hedge any USDC/ETH price fluctuations. Then, upon the VASP would swap the USDC back into ETH when returning the funds to the customer upon request. A VASP might engage in this strategy because the yield on ETH may be 1% and 10% for USDC, and the borrow rate for ETH is 3%. The hope (and risk-reducing strategies employed) is to earn the most reduced interest possible while hedging any USDC/ETH price fluctuations.
The challenge in this scenario is that the obligation to the platform customer (i.e., Liability) is denominated in ETH, but the collateral assets are denominated in USDC. When assets and liabilities are not denominated with the same unit of account, the VASP must choose a "base" unit of account and apply an Fx rate to any assets or liabilities not denominated in the new unit of account.
To appropriately account for this "alternative-backed" situation, a VASP would:
Choose a "base" unit of account to denominate the PoR Reconciliation (USDC)
Apply the Fx rate to the collateral assets not denominated by the "base" (ETH/USDC Fx Rate to USDC collateral assets)
Find the "Base"-Equivalent value of the assets (ETH-equivalent value of USDC assets)
Compare the "Base"-Equivalent value of the assets to the "Base" equivalent value of the liabilities. (Compare ETH-equivalent value of assets ETH liabilities)
In this example, the liability is not denominated in the same unit of account as the assets. Therefore, in this situation, we note that the liabilities are collateralized by alt-backed or off-denominated assets. Understanding this asset/liability relationship is typically important for lending/borrowing platforms to manage risk. However, it is also very important to accurately scope and execute a Proof of Reserves. In these scenarios, the PoR would be comparing liabilities to assets not denominated in the same unit of account, bitcoin in this case.
For alternative-denominated asset/liability pairs in a Proof of Reserve, it is highly recommended to disclose the original denomination of the assets/liabilities and the Fx rate applied to those assets/liabilities to not be misleading to readers.
Non-Platform Account Customer Liabilities:
A Proof of Reserve generally focuses on "On-Platform" liabilities. However, additional customer obligations may exist outside of the platform account balances. These situations may include off-platform loans, bridging and wrapping services, and stablecoins. When these liabilities have claims on the same pool of assets that Platform Customer Liabilities have claims on, these are recommended to include within the scope of the assessment.
For example, if a platform holds BTC on behalf of Platform Users and a bridging service that bridges BTC to ETH, both the platform liabilities and bridged tokens should be included within the scope of the assessment.
These “Non-Platform” liabilities can be treated like “contra-assets” (like additional liabilities in the lending scenario). However, if a platform controls “2 layers” of asset/liability combinations, a related, but separate PoR reconciliation (known as a “nested” or “layered” PoR) may be considered. However, only 1 layer (the Platform Liabilities would have an associated Merkle Tree, because the Token liabilities are all verifiable on chain for the bridged tokens).
Management Outputs:
Last updated
