Oracle Services FAQ
The Network Firm’s LedgerLens™ Oracle Services™ API enables Issuers of RWA-backed Tokens, Stablecoins, Exchange Traded Products, and others to create on-chain transparency to real-world asset data, such as fiat backing or precious metals in custody. Typically, asset data of this kind is confidential information of the Issuer, or otherwise not readily transparent to token holders or interested parties. With LedgerLens Oracle Services, Issuers are able to make both multi-chain token liabilities, as well as custodial asset balances available to the Chainlink Network and for use on-chain in smart contracts.
The LedgerLens Oracle Services API is an automated API service that collects data from blockchains and third-parties (such as banks and other custodians) on a defined cadence, aggregates that asset and liability data into a standard summary format available for query by Node Operators on the Chainlink Network. The summary information, made available at a point-in-time, and updated on a defined cadence, is referred to as “Balance Data.”
Please refer to the Disclaimer regarding limitations of the LedgerLens™ Oracle Services™ API and Balance Data.
The Balance Data made available by the Issuer is specific to each Issuer and specific to each Chainlink Proof of Reserves Feed. Generally, the Balance Data provided via API and queried by Node Operators on the Chainlink Network displays: (1) the number of tokens (liabilities) per blockchain; (2) the count of real-world assets (by source or in sum); (3) the value of the real-world assets (as applicable); (4) the “Ripcord status” of the Oracle Services API (more on Ripcords below); (5) a date and time stamp showing the point in time at which the Balance Data was last updated; and, (6) any other information relevant to the on-chain liabilities and off-chain assets the Issuer may wish to provide.
How does the LedgerLens™ Oracle Services™ API work?
To compile and provide real-time data, the LedgerLens™ Oracle Services™ API aggregates Balance Data from many different data sources. The data sources for each LedgerLens™ Oracle Services™ API depend on the nature of the Issuer’s business and the type of token they offer to customers. For example, a centralized, fiat-backed stablecoin Issuer will have different data sources than the Issuer of a physical, gold-backed commodity token.
The LedgerLens Oracle Services infrastructure includes, but is not limited to, the following integration types:
Blockchain Nodes: LedgerLens Oracle Services API queries relevant address balances, circulating supplies, locked and frozen token balances, and other transactional data from the relevant blockchains and/or smart contracts.
Financial Institutions, Banks, & Trust Companies: LedgerLens Oracle Services API utilizes read-only API keys granted by banking and escrow partners to query, aggregate and summarize Balance Data. In limited cases, Balance Data can also be queried from third parties using other messaging technologies or parsing libraries maintained by The Network Firm.
Exchanges and Custodians: LedgerLens Oracle Services API utilizes read-only API keys granted by exchanges and custodians to query, aggregate, and summarize Balance Data.
Pricing Feeds: LedgerLens Oracle Services API aggregates market pricing information and exchange rates, as applicable, to apply US Dollar or other Fiat-denominated values to Balance Data.
Each of these data sources is queried at a specific interval (as frequently as every 30 seconds), to provide the most current data possible for each LedgerLens Oracle Services API endpoint.
What is a Ripcord?
The Balance Data made available for Chainlink Node Operators via API is governed by a system of Ripcords. A Ripcord is a pre-condition or requirement enforced by the code of the LedgerLens system, which must be fulfilled in order for new Balance Data to be available on the LedgerLens Oracle Services API endpoint. In order for the Balance Data to be updated for query via API at the next “Standard Reporting Interval,” Ripcord conditions must not be present or “triggered.” If any single Ripcord is triggered, then a pre-condition to standard updates is not met in the System, and thus, new Balance Data will not be available, and the last available Balance Data will be available with its corresponding timestamp.
Four different types of Ripcords exist (explained further below). Anytime a Ripcord has been triggered, the API will display a Ripcord: true value within the Boolean field. The existence of any ripcord: true states will halt the availability of new Balance Data until the Balance Ripcord expires (see below), or the System queries source information successfully and the Ripcord is resolved.
Why does the LedgerLens™ Oracle Services™ API have Ripcords?
The LedgerLens™ Oracle Services™ API relies on API connections (and the like) to query both asset balance and liability balance data from multiple on-chain and off-chain sources (the aggregate being, the Balance Data). Because the Balance Data is obtained from third-party sources, it is subject to periodic maintenance, downtime, or even inaccuracy. Ripcords exists to perform automated checks on the aggregate Balance Data as well as all underlying Balance Data sources and to control Balance Data availability on standard reporting intervals. For example, without ripcords, every time a bank API was in maintenance or otherwise non-responsive, the most common source of Ripcords over the LedgerLens System’s operation, the API would under-report assets related to an asset-backed token.
What are the types of ripcords?
Management: During the last reporting interval, the Management of the Issuer had un-acknowledged terms of the engagement. This ripcord can also be triggered if the LedgerLens team or the Issuer’s Management has become aware of an event with a service provider or third-party custodian of the Issuer that will materially affect the Balance Data. Such facts and circumstances may present pauses or, in more extreme cases, the discontinuance of new Balance Data.
Integrations: During the last reporting interval, the LedgerLens™ Oracle Services™ API received an error from a “liability source” or an “asset source,” the exclusion of which from total liabilities or total assets respectively would trigger the Balances Ripcord (see below). In the example case of a fiat-backed stablecoin, the “liability source” would be the smart contract address for the total issued and redeemable tokens on the relevant blockchain; the “asset source” would be the fiat collateral held in a third-party bank or trust company account and queried via API.
Pricing: During the last reporting interval, the LedgerLens™ Oracle Services™ API received errors or a non-response from the pricing source and is unable to apply a USD (or other relevant fiat-denominated) value to the off-chain assets for that point in time. This ripcord is not applicable in all circumstances because in many cases an outside pricing source is not needed to accurately present the Balance Data.
Balances: During the last reporting interval, the LedgerLens™ Oracle Services™ API received responses, errors, or non-responses from third-party systems or accounts resulting in the sum total of liabilities being greater than the sum total of the relevant assets. Commonly, over the historical operation of the LedgerLens™ Oracle Services™ API, the Balances Ripcord is triggered by temporary imbalances seen in normal Issuer operations (such as funds in transit, or Management opening a new bank account not yet integrated into the System). However, the Balances ripcord can also be triggered due to an actual imbalance of liabilities and corresponding assets. In all cases, the Balances Ripcord expires after 72 hours; if the imbalances persist after 72 hours, and no other ripcords are triggered, the LedgerLens™ Oracle Services™ API will generate new Balance Data using then-available asset balances and values, including timestamp, and make that Balance Data available on the API endpoint.
None: During the last reporting interval, the LedgerLens™ Oracle Services™ API did not detect any conditions that would trigger one or more of the above-detailed Ripcord Conditions.
What is the “Standard Reporting Interval?”
Each LedgerLens™ Oracle Services™ API has a unique Balance Data reporting interval called the “Standard Reporting Interval.” The Standard Reporting Interval is determined by the availability of information to support the data query, aggregation and summarization process, and is the Issuer’s chosen interval. Typically, the Standard Reporting Interval is the frequency at which information from the “least-available” data source is available. For example, if stablecoin issuer holds cash and Treasuries at a bank where the USD cash and cash equivalents balances in the Issuer’s accounts are only settled and reported once per day, then the LedgerLens™ Oracle Services™ API will only query, aggregate, and summarize new Balance Data once per day, even though all other information may be available much more frequently.
Disclaimers
The service is a non-attest service provided by The Network Firm to the Issuer, meaning TNF did not perform an audit, review, examination, or other form of attestation (as those terms are identified by the American Institute of Certified Public Accountants or by the Public Company Accounting Oversight Board) over the Issuer’s Balance data. Accordingly, TNF did not and does not express any form of assurance on the Balance Data as reported on the LedgerLens™ Oracle Services™ API, the Client’s accounting matters, financial statements, any financial or other information, or internal controls related to the API provided to the Chainlink Network.
Given the nature and risk of cryptocurrency, the Balance Data can become inaccurate in an instant. The Balance Data is sourced entirely by third parties and neither TNF nor any Chainlink service provider has knowledge of its accuracy and shall have no liability to any Chainlink users or third parties regarding the Balance Data. Nothing in the Balance Data relates to the balance of any individual holder’s tokens, or whether any individual’s holdings of any tokens actually belong to or will be accessible to such individual at any time. Neither TNF nor any Chainlink service provider is providing investment, financial, legal or tax advice in making the Balance Data available herein and encourages all users of the Balance Data to conduct their own diligence regarding the accuracy of the Balance Data, the tax impacts, and legal/governmental regulatory framework related to cryptocurrency.
TNF did not and does not conclude or opine over the Balance Data. TNF expressly disclaims any duties or obligations to any person, smart contract, blockchain protocol, or entity based on its use of the Balance Data. Any other person or entity must perform its own due diligence inquiries and procedures for all purposes, including, but not limited to, satisfying itself as to the financial condition and control environment of TNF clients.
The Network Firm is and does not host, design and or implement a system on behalf of TNF clients. The LedgerLens system only performs discrete and simple calculations. TNF clients have evaluated and accept responsibility for the input and assumptions; and TNF clients have sufficient information to understand the calculation and the results, as they have access to and perform their owns calculations and results. The Network Firm has no ability to authorize, execute, or consummate transactions. If TNF were to stop providing the non-attest services, the TNF client would continue to authorize, execute and authorize transactions if it deemed fit. The Network Firm did not design, implement or maintain any related internal controls for which the data provisioning services may be used for. All subsequent activities are subject to the design, implementation and maintenance of the TNF client. TNF has no involvement in developing any related smart contracts, processes, or related activities that may be deem a control or another responsibility of the TNF client. Additionally, the TNF client assumes all responsibility for the non-attest services as documented within the relevant Engagement Letter or Software as a Service License Agreement.
All aforementioned information is subject to The Network’s Firm’s Terms and Conditions for Professional Service and Terms of Use policy.
If you have any questions , please contact us at Legal@TheNetworkFirm.com