Provide genuine proof of reserves checks on-chain
Part 1 of 2
Prove token reserves securely using Open Banking Checks and Silent Data [Oracle]
Noam Elstein
April 22, 2024
Key Takeaways
- Tokenisation plays a key role in the digitization of finance
- Proof of Reserves demonstrates token issuers or exchanges have sufficient liquidity in proportion to their tokens in supply
- Proof of Reserves gives people more trust the value of the tokens they hold- Current POR activity is inadequate. People must either trust the issuers’ word, or the issuer must give their API credentials to a network blockchain oracles
Tokenization: A Growing Trend
Asset tokenisation is a growing phenomenon, key to the digital transformation of traditional capital markets and financial services. When discussing the technological revolution of financial markets, BlackRock CEO Larry Fink said ETFs are the first step, but “Step two is going to be the tokenisation of every financial asset”. At the forefront of tokenisation are stablecoins - tokens pegged to an asset, typically a fiat currency.
Proof of Reserves verifies the liquidity of token issuers or exchanges i.e. that issuer actually holds the assets they are tokenising. At present, these proofs are either ingenuine or risk the issuers’ open banking credentials. Proving off-chain liquidity for on-chain assets is essential, highlighted by the FTX scandal. As tokens represent tangible assets their market value inherently depends on public perception. Doubt regarding reserves causes holders to sell their tokens, subsequently creating a vicious spiral.
Proof of reserves (POR) on token contracts is publicly viewable and if robust, helps gain the market’s trust. It ensures tokens are only minted once the POR is verified, and also flagged if reserves drop below a minimum. However, at present POR activity is inadequate given user must either trust data provided by token issuer, or issuer must surrender private credentials to a blockchain oracle.
Open banking allows regulated entities to interact with banks and leverage financial data previously kept within their closed systems. Companies such as PLAID, leveraged in this use case, enable applications to connect with user bank accounts through APIs.
Proof of Reserves verifies the liquidity of token issuers or exchanges i.e. that issuer actually holds the assets they are tokenising. At present, these proofs are either ingenuine or risk the issuers’ open banking credentials. Proving off-chain liquidity for on-chain assets is essential, highlighted by the FTX scandal. As tokens represent tangible assets their market value inherently depends on public perception. Doubt regarding reserves causes holders to sell their tokens, subsequently creating a vicious spiral.
Proof of reserves (POR) on token contracts is publicly viewable and if robust, helps gain the market’s trust. It ensures tokens are only minted once the POR is verified, and also flagged if reserves drop below a minimum. However, at present POR activity is inadequate given user must either trust data provided by token issuer, or issuer must surrender private credentials to a blockchain oracle.
Open banking allows regulated entities to interact with banks and leverage financial data previously kept within their closed systems. Companies such as PLAID, leveraged in this use case, enable applications to connect with user bank accounts through APIs.
Proof of Reserves: Market Landscape
Various solutions exist which provide proof of reserves to the blockchain. However, these are either superficial proofs or require token issuers to risk their sensitive open banking credentials. Silent Data [Oracle] provides an alternative with a secure, open banking POR solution.
Auditor may be leveraged to check balances but this is time consuming and manual, the antithesis of attractive efficiency gains Web3 provides. Moreover, crypto auditors present their own reliability issues, seen by the failed auditing of FTX.
Token issuer can publish their own holdings but this is futile as the market must trust their word. Issuer may also connect a blockchain oracle to their own API, but this is effectively the same given the market must trust data provided by the issuer. Coindesk highlighted this problem as even blockchain oracle Chainlink Functions concedes its proof of reserves offering includes “self-attestation”, whereby its oracle nodes all connect to the token issuer’s API.
Token issuer may connect to an open banking provider using a traditional blockchain oracle, but must trust their open banking credentials to the oracle or to multiple oracle nodes (i.e. to a decentralised oracle network). This comes with significant security risks as should the blockchain oracle be compromised, the token issuer’s online banking credentials could be exploited.
Silent Data [Oracle] allows parties to connect their token contracts to open banking without needing to reveal their API credentials to a node operator. Silent Data [Oracle] cannot view its users’ API keys nor manipulate the data it posts on-chain. Thus token holder needs not trust the issuer’s word nor trust the oracle operator reporting open banking data.
Want to know how this is possible? Check out our intro to Silent Data [Oracle]
Auditor may be leveraged to check balances but this is time consuming and manual, the antithesis of attractive efficiency gains Web3 provides. Moreover, crypto auditors present their own reliability issues, seen by the failed auditing of FTX.
Token issuer can publish their own holdings but this is futile as the market must trust their word. Issuer may also connect a blockchain oracle to their own API, but this is effectively the same given the market must trust data provided by the issuer. Coindesk highlighted this problem as even blockchain oracle Chainlink Functions concedes its proof of reserves offering includes “self-attestation”, whereby its oracle nodes all connect to the token issuer’s API.
Token issuer may connect to an open banking provider using a traditional blockchain oracle, but must trust their open banking credentials to the oracle or to multiple oracle nodes (i.e. to a decentralised oracle network). This comes with significant security risks as should the blockchain oracle be compromised, the token issuer’s online banking credentials could be exploited.
Silent Data [Oracle] allows parties to connect their token contracts to open banking without needing to reveal their API credentials to a node operator. Silent Data [Oracle] cannot view its users’ API keys nor manipulate the data it posts on-chain. Thus token holder needs not trust the issuer’s word nor trust the oracle operator reporting open banking data.
Want to know how this is possible? Check out our intro to Silent Data [Oracle]
How does Silent Data provide genuine proof-of-reserves checks, automated on token contracts?
Here is a brief overview of how to connect the PLAID API to your token contract using Silent Data [Oracle].
Step 0: Set up PLAID
Obtain the secret key and details necessary to connect with the authorised PLAID API.
Step 1: Configure the Trigger
A job is a set of steps that users assign Silent Data to complete. Establish the starting point of the job, here it is a POR request passing from your token contract to the [Oracle] job.
Step 2: Configure the Steps
Specify the kind of job you require. Set up [Oracle] to verify POR via PLAID and retrieve the reserves balances.
Step 3: Configure the Results
Connect your Callback contract to [Oracle] in order to publish the results of the job back on-chain. In this case, [Oracle] will post the reserves balances from the POR Check.
Step 4: Publish and Fund the job
Finally, publish the job and then top up the funds in your [Oracle] account in order to trigger the job itself. [Oracle] jobs need funding to run.
Step X: Deploy your Token Contract
Any node on the token contract can run an Open Banking Check with Silent Data [Oracle] which publishes the reserves balances on-chain. Tokens cannot be issued if reserves fall below a certain value.
Stay tuned for the step-by-step guide in part 2!
Consult our Documentation throughout for greater detail regarding these steps.
Consult our Documentation throughout for greater detail regarding these steps.
To discuss and join our community , Visit our channels
© Copyright 2024 Applied Blockchain Ltd.
All rights reserved Applied Blockchain Ltd is a company registered in England and Wales. Company No. 09686276
© Copyright 2024 Applied Blockchain Ltd.
All rights reserved Applied Blockchain Ltd is a company registered in England and Wales. Company No. 09686276