This crypto-asset white paper has not been approved by any competent authority in any Member State of the European Union. The person seeking admission to trading of the crypto-asset is solely responsible for the content of this crypto-asset white paper.
The prospective holder should base any decision to purchase this crypto –asset on the content of the crypto-asset white paper as a whole and not on the summary alone.
The offer to the public of this crypto-asset does not constitute an offer or solicitation to purchase financial instruments and any such offer or solicitation can be made only by means of a prospectus or other offer documents pursuant to the applicable national law.
This crypto-asset white paper does not constitute a prospectus as referred to in Regulation (EU) 2017/1129 of the European Parliament and of the Council or any other offer document pursuant to Union or national law.
 |
||
 |
||
Article 3 (1) (5) For the purposes of this Regulation, the following definitions apply:
(5) ‘crypto-asset’ means a digital representation of a value or of a right that is able to be transferred and stored electronically using distributed ledger technology or similar technology
Article 3 (1) (9) For the purposes of this Regulation, the following definitions apply:
(9) ‘utility token’ means a type of crypto-asset that is only intended to provide access to a good or a service supplied by its issuer
Article 3 (1) (10) For the purposes of this Regulation, the following definitions apply:
(10) ‘issuer’ means a natural or legal person, or other undertaking, who issues crypto-assets
Article 3 (1) (12) For the purposes of this Regulation, the following definitions apply:
(12) ‘offer to the public’ means a communication to persons in any form, and by any means, presenting sufficient information on the terms of the offer and the crypto-assets to be offered so as to enable prospective holders to decide whether to purchase those crypto-assets
Article 3 (1) (13)
For the purposes of this Regulation, the following definitions apply:
(13) ‘offeror’ means a natural or legal person, or other undertaking, or the issuer, who offers crypto-assets to the public
Article 3 (1) (14)
For the purposes of this Regulation, the following definitions apply:
(14) ‘funds’ means funds as defined in Article 4, point (25), of Directive (EU) 2015/2366
Article 3 (1) (19)
For the purposes of this Regulation, the following definitions apply:
(19) ‘exchange of crypto-assets for funds’ means the conclusion of purchase or sale contracts concerning crypto-assets with clients for funds by using proprietary capital
Article 3 (1) (20)
For the purposes of this Regulation, the following definitions apply:
(20) ‘exchange of crypto-assets for other crypto-assets’ means the conclusion of purchase or sale contracts concerning crypto-assets with clients for other crypto-assets by using proprietary capital
Article 3 (1) (22)
For the purposes of this Regulation, the following definitions apply:
(22) ‘placing of crypto-assets’ means the marketing, on behalf of or for the account of the offeror or a party related to the offeror, of crypto-assets to purchasers
Article 3 (1) (28)
For the purposes of this Regulation, the following definitions apply:
(28) ‘credit institution’ means a credit institution as defined in Article 4(1), point (1), of Regulation (EU) No 575/2013 and authorised under Directive 2013/36/EU
Article 3 (1) (30) For the purposes of this Regulation, the following definitions apply:
(30) Where an offer to the public concerns utility tokens for goods that do not yet exist or services that are not yet in operation, the duration of the offer to the public as described in the crypto-asset white paper should not exceed 12 months. That limitation on the duration of the offer to the public is unrelated to the moment when the goods or services come into existence or become operational and can be used by the holder of a utility token after the expiry of the offer to the public.
Article 3 (1) (37)
For the purposes of this Regulation, the following definitions apply:
(37) ‘retail holder’ means any natural person who is acting for purposes which are outside that person’s trade, business, craft or profession
Article 3 (1) (38) For the purposes of this Regulation, the following definitions apply:
(38) ‘online interface’ means any software, including a website, part of a website or an application, that is operated by or on behalf of an offeror or crypto-asset service provider, and which serves to give holders of crypto-assets access to their crypto-assets and to give clients access to crypto-asset services
Article 3 (1) (39)
For the purposes of this Regulation, the following definitions apply:
(39) ‘client’ means any natural or legal person to whom a crypto-asset service provider provides crypto-asset services
Article 4 1. A person shall not make an offer to the public of a crypto-asset other than an asset-referenced token or e-money token in the Union unless that person: (a) is a legal person;
(b) has drawn up a crypto-asset white paper in respect of that crypto-asset in accordance with Article 6;
(c) has notified the crypto-asset white paper in accordance with Article 8;
(d) has published the crypto-asset white paper in accordance with Article 9;
(e) has drafted the marketing communications, if any, in respect of that crypto-asset in accordance with Article 7;
(f) has published the marketing communications, if any, in respect of that crypto-asset in accordance with Article 9;
(g) complies with the requirements for offerors laid down in Article 14.
2. Paragraph 1, points (b), (c), (d) and (f), shall not apply to any of the following offers to the public of crypto-assets other than asset-referenced tokens or e-money tokens:
(a) an offer to fewer than 150 natural or legal persons per Member State where such persons are acting on their own account;
(b) over a period of 12 months, starting with the beginning of the offer, the total consideration of an offer to the public of a crypto-asset in the Union does not exceed EUR 1 000 000, or the equivalent amount in another official currency or in crypto-assets;
(c) an offer of a crypto-asset addressed solely to qualified investors where the crypto-asset can only be held by such qualified investors.
3. This Title shall not apply to offers to the public of crypto-assets other than asset-referenced tokens or e-money tokens where any of the following apply:
(a) the crypto-asset is offered for free;
(b) the crypto-asset is automatically created as a reward for the maintenance of the distributed ledger or the validation of transactions;
(c) the offer concerns a utility token providing access to a good or service that exists or is in operation;
(d) the holder of the crypto-asset has the right to use it only in exchange for goods and services in a limited network of merchants with contractual arrangements with the offeror.
For the purposes of point (a) of the first subparagraph, a crypto-asset shall not be considered to be offered for free where purchasers are required to provide, or to undertake to provide, personal data to the offeror in exchange for that crypto-asset, or where the offeror of a crypto-asset receives from prospective holders of that crypto-asset any fees, commissions, or monetary or non-monetary benefits in exchange for that crypto-asset.
Where, for each 12-month period starting from the beginning of the initial offer to the public, the total consideration of an offer to the public of a crypto-asset in the circumstances referred to in the first subparagraph, point (d), in the Union exceeds EUR 1 000 000, the offeror shall send a notification to the competent authority containing a description of the offer and explaining why the offer is exempt from this Title pursuant to the first subparagraph, point (d).
Based on the notification referred to in the third subparagraph, the competent authority shall take a duly justified decision where it considers that the activity does not qualify for an exemption as a limited network under the first subparagraph, point (d), and shall inform the offeror accordingly.
4. The exemptions listed in paragraphs 2 and 3 shall not apply where the offeror, or another person acting on the offeror’s behalf, makes known in any communication its intention to seek admission to trading of a crypto-asset other than an asset-referenced token or e-money token.
5. Authorisation as a crypto-asset service provider pursuant to Article 59 is not required for providing custody and administration of crypto-assets on behalf of clients or for providing transfer services for crypto-assets in relation to crypto-assets whose offers to the public are exempt pursuant to paragraph 3 of this Article, unless:
(a) there exists another offer to the public of the same crypto-asset and that offer does not benefit from the exemption; or
(b) the crypto-asset offered is admitted to a trading platform.
6. Where the offer to the public of the crypto-asset other than an asset-referenced token or e-money token concerns a utility token providing access to goods and services that do not yet exist or are not yet in operation, the duration of the offer to the public as described in the crypto-asset white paper shall not exceed 12 months from the date of publication of the crypto-asset white paper.
7. Any subsequent offer to the public of the crypto-asset other than an asset-referenced token or e-money token shall be deemed a separate offer to the public to which the requirements of paragraph 1 apply, without prejudice to the possible application of paragraph 2 or 3 to the subsequent offer to the public. No additional crypto-asset white paper shall be required for any subsequent offer to the public of the crypto-asset other than an asset-referenced token or e-money token so long as a crypto-asset white paper has been published in accordance with Articles 9 and 12, and the person responsible for drawing up such white paper consents to its use in writing.
8. Where an offer to the public of a crypto-asset other than an asset-referenced token or e-money token is exempt from the obligation to publish a crypto-asset white paper under paragraph 2 or 3, but a white paper is nevertheless drawn up voluntarily, this Title shall apply.
Article 6 1. A crypto-asset white paper shall contain all of the following information, as further specified in Annex I:
(a) information about the offeror or the person seeking admission to trading;
(b) information about the issuer, if different from the offeror or person seeking admission to trading;
(c) information about the operator of the trading platform in cases where it draws up the crypto-asset white paper;
(d) information about the crypto-asset project;
(e) information about the offer to the public of the crypto-asset or its admission to trading;
(f) information about the crypto-asset;
(g) information on the rights and obligations attached to the crypto-asset;
(h) information on the underlying technology;
(i) information on the risks;
(j) information on the principal adverse impacts on the climate and other environment-related adverse impacts of the consensus mechanism used to issue the crypto-asset.
In cases where the crypto-asset white paper is not drawn up by the persons referred to in the first subparagraph, points (a), (b) and (c), the crypto-asset white paper shall also include the identity of the person that drew up the crypto-asset white paper and the reason why that particular person drew it up.
2. All of the information listed in paragraph 1 shall be fair, clear and not misleading. The crypto-asset white paper shall not contain material omissions and shall be presented in a concise and comprehensible form.
3. The crypto-asset white paper shall contain the following clear and prominent statement on the first page:
‘This crypto-asset white paper has not been approved by any competent authority in any Member State of the European Union. The offeror of the crypto-asset is solely responsible for the content of this crypto-asset white paper.’.
Where the crypto-asset white paper is drawn up by the person seeking admission to trading or by an operator of a trading platform, then, instead of ‘offeror’, a reference to ‘person seeking admission to trading’ or ‘operator of the trading platform’ shall be included in the statement referred to in the first subparagraph.
4. The crypto-asset white paper shall not contain any assertions as regards the future value of the crypto-asset, other than the statement referred to in paragraph 5.
5. The crypto-asset white paper shall contain a clear and unambiguous statement that:
(a) the crypto-asset may lose its value in part or in full;
(b) the crypto-asset may not always be transferable;
(c) the crypto-asset may not be liquid;
(d) where the offer to the public concerns a utility token, that utility token may not be exchangeable against the good or service promised in the crypto-asset white paper, especially in the case of a failure or discontinuation of the crypto-asset project;
(e) the crypto-asset is not covered by the investor compensation schemes under Directive 97/9/EC of the European Parliament and of the Council (35);
(f) the crypto-asset is not covered by the deposit guarantee schemes under Directive 2014/49/EU.
6. The crypto-asset white paper shall contain a statement from the management body of the offeror, the person seeking admission to trading or the operator of the trading platform. That statement, which shall be inserted after the statement referred to in paragraph 3, shall confirm that the crypto-asset white paper complies with this Title and that, to the best of the knowledge of the management body, the information presented in the crypto-asset white paper is fair, clear and not misleading and the crypto-asset white paper makes no omission likely to affect its import.
7. The crypto-asset white paper shall contain a summary, inserted after the statement referred to in paragraph 6, which shall in brief and non-technical language provide key information about the offer to the public of the crypto-asset or the intended admission to trading. The summary shall be easily understandable and presented and laid out in a clear and comprehensive format, using characters of readable size. The summary of the crypto-asset white paper shall provide appropriate information about the characteristics of the crypto-asset concerned in order to help prospective holders of the crypto-asset to make an informed decision.
The summary shall contain a warning that:
(a) it should be read as an introduction to the crypto-asset white paper;
(b) the prospective holder should base any decision to purchase the crypto-asset on the content of the crypto-asset white paper as a whole and not on the summary alone;
(c) the offer to the public of the crypto-asset does not constitute an offer or solicitation to purchase financial instruments and that any such offer or solicitation can be made only by means of a prospectus or other offer documents pursuant to the applicable national law;
(d) the crypto-asset white paper does not constitute a prospectus as referred to in Regulation (EU) 2017/1129 of the European Parliament and of the Council (36) or any other offer document pursuant to Union or national law.
8. The crypto-asset white paper shall contain the date of its notification and a table of contents.
9. The crypto-asset white paper shall be drawn up in an official language of the home Member State, or in a language customary in the sphere of international finance.
Where the crypto-asset is also offered in a Member State other than the home Member State, the crypto-asset white paper shall also be drawn up in an official language of the host Member State, or in a language customary in the sphere of international finance.
10. The crypto-asset white paper shall be made available in a machine-readable format.
11. ESMA, in cooperation with EBA, shall develop draft implementing technical standards to establish standard forms, formats and templates for the purposes of paragraph 10.
ESMA shall submit the draft implementing technical standards referred to in the first subparagraph to the Commission by 30 June 2024.
Power is conferred on the Commission to adopt the implementing technical standards referred to in the first subparagraph in accordance with Article 15 of Regulation (EU) No 1095/2010.
12. ESMA, in cooperation with EBA, shall develop draft regulatory technical standards on the content, methodologies and presentation of the information referred to in paragraph 1, first subparagraph, point (j), in respect of the sustainability indicators in relation to adverse impacts on the climate and other environment‐related adverse impacts.
When developing the draft regulatory technical standards referred to in the first subparagraph, ESMA shall consider the various types of consensus mechanisms used to validate transactions in crypto-assets, their incentive structures and the use of energy, renewable energy and natural resources, the production of waste and greenhouse gas emissions. ESMA shall update those regulatory technical standards in the light of regulatory and technological developments.
ESMA shall submit the draft regulatory technical standards referred to in the first subparagraph to the Commission by 30 June 2024.
Power is delegated to the Commission to supplement this Regulation by adopting the regulatory technical standards referred to in the first subparagraph of this paragraph in accordance with Articles 10 to 14 of Regulation (EU) No 1095/2010.
Article 10 1. Offerors of crypto-assets other than asset-referenced tokens or e-money tokens that set a time limit on their offer to the public of those crypto-assets shall publish on their website the result of the offer to the public within 20 working days of the end of the subscription period.
2. Offerors of crypto-assets other than asset-referenced tokens or e-money tokens that do not set a time limit on their offer to the public of those crypto-assets shall publish on their website on an ongoing basis, at least monthly, the number of units of the crypto-assets in circulation.
3. Offerors of crypto-assets other than asset-referenced tokens or e-money tokens that set a time limit on their offer to the public of crypto-assets shall have effective arrangements in place to monitor and safeguard the funds or other crypto-assets raised during the offer to the public. For that purpose, those offerors shall ensure that the funds or cryptoassets collected during the offer to the public are kept in custody by one or both of the following:
(a) a credit institution, where funds are raised during the offer to the public;
(b) a crypto-asset service provider providing custody and administration of crypto-assets on behalf of clients.
4. When the offer to the public has no time limit, the offeror shall comply with paragraph 3 of this Article until the right of withdrawal of the retail holder pursuant to Article 13 has expired.
Article 12 1. Offerors, persons seeking admission to trading or operators of a trading platform for crypto-assets other than asset-referenced tokens or e-money tokens shall modify their published crypto-asset white papers and, where applicable, their published marketing communications, whenever there is a significant new factor, material mistake or material inaccuracy that is capable of affecting the assessment of the crypto-assets. That requirement shall apply for the duration of the offer to the public or for as long as the crypto-asset is admitted to trading. 2. Offerors, persons seeking admission to trading or operators of a trading platform for crypto-assets other than asset-referenced tokens or e-money tokens shall notify their modified crypto-asset white papers and, where applicable, modified marketing communications, and the intended publication date, to the competent authority of their home Member State, including the reasons for such modification, at least seven working days before their publication.
3. On the date of publication, or earlier if required by the competent authority, the offeror, the person seeking admission to trading or the operator of the trading platform shall immediately inform the public on its website of the notification of a modified crypto-asset white paper with the competent authority of its home Member State and shall provide a summary of the reasons for which it has notified a modified crypto-asset white paper.
4. The order of the information in a modified crypto-asset white paper and, where applicable, in modified marketing communications, shall be consistent with that of the crypto-asset white paper or marketing communications published in accordance with Article 9.
5. Within five working days of receipt of the modified crypto-asset white paper and, where applicable, of the modified marketing communications, the competent authority of the home Member State shall notify the modified crypto-asset white paper and, where applicable, the modified marketing communications to the competent authority of the host Member States referred to in Article 8(6) and communicate the notification and the date of publication to ESMA.
ESMA shall make the modified crypto-asset white paper available in the register, under Article 109(2), upon publication.
6. Offerors, persons seeking admission to trading or operators of trading platforms for crypto-assets other than assetreferenced tokens or e-money tokens shall publish the modified crypto-asset white paper and, where applicable, the modified marketing communications, including the reasons for such modification, on their website in accordance with Article 9.
7. The modified crypto-asset white paper and, where applicable, the modified marketing communications, shall be time-stamped. The most recent modified crypto-asset white paper and, where applicable, the modified marketing communications shall be marked as the applicable version. All modified crypto-asset white papers and, where applicable, modified marketing communications shall remain available for as long as the crypto-assets are held by the public.
8. Where the offer to the public concerns a utility token providing access to goods and services that do not yet exist or are not yet in operation, changes made in the modified crypto-asset white paper and, where applicable, the modified marketing communications, shall not extend the time limit of 12 months referred to in Article 4(6).
9. Older versions of the crypto-asset white paper and the marketing communications shall remain publicly available on the website of the offerors, persons seeking admission to trading, or operators of trading platforms, for at least 10 years after the date of publication of those older versions, with a prominent warning stating that they are no longer valid and with a hyperlink to the dedicated section on the website where the most recent version of those documents is published.
Article 13 1. Retail holders who purchase crypto-assets other than asset-referenced tokens and e-money tokens either directly from an offeror or from a crypto-asset service provider placing crypto-assets on behalf of that offeror shall have a right of withdrawal.
Retail holders shall have a period of 14 calendar days within which to withdraw from their agreement to purchase crypto-assets other than asset-referenced tokens and e-money tokens without incurring any fees or costs and without being required to give reasons. The period of withdrawal shall begin from the date of the agreement of the retail holder to purchase those crypto-assets.
2. All payments received from a retail holder including, if applicable, any charges, shall be reimbursed without undue delay and in any event no later than 14 days from the date on which the offeror or the crypto-asset service provider placing crypto-assets on behalf of that offeror is informed of the retail holder’s decision to withdraw from the agreement to purchase those crypto-assets.
Such reimbursement shall be carried out using the same means of payment as that used by the retail holder for the initial transaction, unless the retail holder expressly agrees otherwise and provided that the retail holder does not incur any fees or costs as a result of such reimbursement.
3. Offerors of crypto-assets shall provide information on the right of withdrawal referred to in paragraph 1 in their crypto-asset white paper.
4. The right of withdrawal referred to in paragraph 1 shall not apply where the crypto-assets have been admitted to trading prior to their purchase by the retail holder.
5. Where offerors have set a time limit on their offer to the public of such crypto-assets in accordance with Article 10, the right of withdrawal shall not be exercised after the end of the subscription period.
Article 14 1. Offerors and persons seeking admission to trading of crypto-assets other than asset-referenced tokens or e-money tokens shall:
(a) act honestly, fairly and professionally;
(b) communicate with holders and prospective holders of the crypto-assets in a fair, clear and not misleading manner;
(c) identify, prevent, manage and disclose any conflicts of interest that might arise;
(d) maintain all of their systems and security access protocols in conformity with the appropriate Union standards.
For the purposes of point (d) of the first subparagraph, ESMA, in cooperation with EBA, shall by 30 December 2024 issue guidelines in accordance with Article 16 of Regulation (EU) No 1095/2010 to specify those Union standards.
2. Offerors and persons seeking admission to trading of crypto-assets other than asset-referenced tokens or e-money tokens shall act in the best interests of the holders of such crypto-assets and shall treat them equally, unless any preferential treatment of specific holders and the reasons for that preferential treatment are disclosed in the crypto-asset white paper and, where applicable, the marketing communications.
3. Where an offer to the public of a crypto-asset other than an asset-referenced token or e-money token is cancelled, offerors of such crypto-asset shall ensure that any funds collected from holders or prospective holders are duly returned to them no later than 25 calendar days after the date of cancellation.
Article 15 1. Where an offeror, person seeking admission to trading or operator of a trading platform, has infringed Article 6 by providing in its crypto-asset white paper or in a modified crypto-asset white paper information that is not complete, fair or clear or that is misleading, that offeror, person seeking admission to trading or operator of a trading platform and the members of its administrative, management or supervisory body shall be liable to a holder of the crypto-asset for any loss incurred due to that infringement.
2. Any contractual exclusion or limitation of civil liability as referred to in paragraph 1 shall be deprived of legal effect.
3. Where the crypto-asset white paper and marketing communications are prepared by the operator of the trading platform in accordance with Article 5(3), the person seeking admission to trading shall also be held responsible when it provides information that is not complete, fair or clear, or that is misleading to the operator of the trading platform.
4. It shall be the responsibility of the holder of the crypto-asset to present evidence indicating that the offeror, person seeking admission to trading, or operator of the trading platform for crypto-assets other than asset-referenced tokens or e-money tokens has infringed Article 6 by providing information that is not complete, fair or clear, or that is misleading and that reliance on such information had an impact on the holder’s decision to purchase, sell or exchange that cryptoasset.
5. The offeror, person seeking admission to trading, or operator of the trading platform and the members of its administrative, management or supervisory body shall not be liable to a holder of a crypto-asset for loss incurred as a result of reliance on the information provided in a summary as referred to in Article 6(7), including any translation thereof, except where the summary:
(a) is misleading, inaccurate or inconsistent when read together with the other parts of the crypto-asset white paper; or
(b) does not provide, when read together with the other parts of the crypto-asset white paper, key information in order to aid prospective holders of the crypto-asset when considering whether to purchase such crypto-asset.
6. This Article is without prejudice to any other civil liability pursuant to national law
RedStone applies modular architecture making it easy to incorporate new assets and reduce latency, allowing dApps to scale more efficiently. This means constructing the data providing service in such a way that its various components, data sources, validation mechanisms, delivery methods can be easily interchanged, updated, or augmented without disrupting the system’s overall functionality.
RedStone identifies four key modules in its architecture, each responsible for:
1. Sourcing Module
RedStone’s price feeds are sourced from a wide range of providers, including centralized exchanges like Binance and Coinbase, decentralized exchanges (DEXs) such as Uniswap and Aerodrome, and aggregators like CoinMarketCap and Kaiko. With over 150 integrated sources, RedStone ensures robust data coverage.
Independent nodes operated by data providers aggregate the sourced asset information using various methodologies, including median, TWAP (Time-Weighted Average Price), and LWAP (Liquidity-Weighted Average Price). These methods are designed to deliver highly accurate pricing by accounting for factors such as liquidity and average prices over specific timeframes.
It is of the most importance for oracles to provide high-quality data without interruption. Consequently, node operators must actively monitor their nodes and promptly address any potential issues. That is why we have implemented a dedicated application for node monitoring. This application is executed in a loop and automatically verifies the status of a selected nodes.
2. Data Distribution Module
After the initial stage of market creation—where asset information is sourced via proprietary fetchers—the data is distributed to the Data Providers class. These actors are incentivized to securely sign data packages with their unique private keys and broadcast them to RedStone’s Data Distribution Layer (DDL). The DDL, a low-latency, highly scalable intermediary, temporarily stores the data, making it accessible to interested parties who then push it on-chain at a specified time using a preselected oracle model.
In its final iteration, the Data Providers layer will become fully permissionless, allowing anyone to stream and participate without the need for external approval. RedStone is advancing its decentralization plan by onboarding a broader set of data operators to expand the network further.
3. Data Aggregation Module
Efficient and secure data transfer onto the blockchain involves embedding an additional payload within a user’s transaction and processing the message directly on-chain. Simply put, data such as an asset’s price is embedded within the transaction payload that constitutes a user’s transaction. This is achievable because blockchains function as ledgers, systematically recording updated versions of information referred to as the state. This process is commonly described as a state transition. In this particular component, the program utilizes a portion of the state memory known as call data, which is highly efficient in terms of opcode costs. RedStone utilizes this functionality by embedding its data into the call data of a user’s transaction, enabling cost-efficient, low-latency, and secure data delivery to the blockchain.
The process adheres to RedStone’s distinct structure:
1) Data is fetched from the Data Distribution Layer, supported by the Streamr network or RedStone gateways.
2) It is encoded into a message using RedStone’s specialized ‘Transaction Payload’ structure.
3) The payload is appended to the original transaction, signed, and submitted to the destination blockchain.
Independent nodes operated by data providers aggregate the sourced asset information using various methodologies, including median, TWAP (Time-Weighted Average Price), and LWAP (Liquidity-Weighted Average Price). These methods are designed to deliver highly accurate pricing by accounting for factors such as liquidity and average prices over specific timeframes.
4. Data Consumption Module
With the preceding steps completed, the data package unpacking process begins. This involves gradual data verification and additional sanity checks, all performed on-chain within the destination blockchain network where the price feed will be delivered.
The decoding process unfolds as follows:
First, the appended data packages are extracted from the transaction’s call data parameter. Next, security measures are applied, including verifying that the signature was generated by a trusted provider and validating the timestamp to ensure the freshness of the information. To enhance the system’s security, an on-chain aggregation mechanism is employed. This mechanism enforces an additional requirement: ensuring that a minimum number of distinct data points are utilized. Values from multiple providers are aggregated before being returned to the consumer contract. By default, RedStone uses median value calculation for this aggregation, ensuring resilience against small subsets of corrupt providers (e.g., 2 out of 10). This approach safeguards the final aggregated value from being significantly impacted by malicious or inaccurate data sources.
Once the preceding steps are completed, the process concludes with the delivery of the data package. This can be achieved either through the classic RedStone Pull mode flow or the RedStone Push flow. The latter involves two additional steps: an off-chain relayer that pushes the data on-chain in a customized manner using environment variables, and on-chain contracts that store historic prices and provide access via the familiar AggregatorV3 interface.
The purchaser acquiring the token gains access to services related to the RedStone blockchain ecosystem.
The holder is obliged to comply with the technical requirements referred to in point E29.
Investors purchasing tokens based on the SAFT will have a so-called ‘vesting period’, i.e. a clearly defined timeframe in which they will be able to collect the token from the moment it is issued.
In case of SAFT, the investor's obligation is to invest a certain amount of funds, defined in USD, or its equivalent in another currency or cryptocurrency. This sum varies, depending on the investment round.
Until the TGE Launch Date, RedStone shall not offer, directly or indirectly, to any other purchaser terms that would be more favourable in any respect than those offered to the SAFT investors in the Pre-Seed round, unless they have been offered such terms.
Market makers shall use commercially reasonable efforts to open new markets for RED Token.
Market makers will provide RedStone with daily reports providing summaries and statistics of market activity, related to Cryptoasset.
Market makers will ensure that the Cryptoasset is quoted in accordance with the highest standards of their craft on all trading platforms they support, to be amended from time to time, with a bid/offer, spread, depth and uptime.
Purchasers from the investment rounds will receive it at the token launch, the tokens will be transferred to the wallet addresses they provide.
a) In the case of an investor: the address of the cryptocurrency wallet to which the tokens will be allocated;
b) In the case of a buyer from the free market (exchanges), the address of the EVM (Ethereum Virtual Machine) cryptocurrency wallet.
Cryptoasset received based on SAFT will be technically locked up for the initial period of 1 (one) year since TGE Launch Date. During this period, it shall not be able to transfer, encumber or otherwise dispose of, whether for consideration or free of charge, as well as grant any option or other rights over its Cryptoasset, to any person without the RedStone consent. For the avoidance of doubt, the TGE Launch Dateshall not limit other basic utilities of the Cryptoasset . After the expiration of this period, the Cryptoasset will be gradually (pro-rata) released from the lock-up limitation over a period of 6 (six) or 12 (twelve) months (depending on the SAFT round), starting from the first day following the end of this period.
In case of SAFT, the funds shall be paid in one instalment in the currency as agreed separately between the investor and RedStone.
The investment shall be made within 15 (fifteen) business days upon the conclusion of the SAFTt. If the payment is made in cryptocurrencies, the exchange rate between investment currency and USD shall be the closing exchange rate on the day immediately preceding the payment date as determined on coinmarketcap.com, unless agreed otherwise. The fund shall be transferred to the bank account or a cryptocurrency wallet address as provided by RedStone prior to the payment.
Market makers shall enter into contractual arrangements, to engage or deal with exchanges and/or other platforms as it considers appropriate. They are allowed to take all necessary actions for the purposes of market makers discharging its obligations including to dealing and communicating with exchanges and obtaining any necessary information therefrom.
Reports will include information listed in agreements between RedStone and market makers. All such reports will be shared digitally by email or another agreed communication channel. Market makers will use commercially reasonable efforts in selecting and preparing any content included in any report and subject to such reports
being accurate, truthful and representative of the trading and activity conducted by market makers, the presentation of such content will be at their discretion.
Market makers will have sole discretion to develop most effective strategies and efficient ways to increase liquidity and may result in more bids than offers and vice versa.
1. Modular Architecture: Built around four modules (data sourcing, data distribution, data relaying, data consumption), enabling flexible and scalable integrations with various blockchains.
2. Speed and Efficiency: Achieving minimal latency and low costs through optimized data delivery, leveraging call data encoding to streamline and enhance the efficiency of blockchain transactions
3. Wide Applicability: Supports over 70 blockchains, both EVM-compatible and independent, with the ability to deliver data to new chains with minimal resource expenditure.
4. Data Security: Data is secured with cryptographic signatures, ensuring the integrity and authenticity of information on target blockchains.
5. Integration with Arweave: Utilizes a blockchain optimized for data storage to create a decentralized, historical record of price feeds.
6. Tailored for DeFi Markets: Supports advanced pricing mechanisms such as TWAP, LWAP, and fundamental models, making RedStone an ideal solution for DeFi protocols and tokenized real-world asset (RWA) markets.
7. Innovative Functionalities: Provides support for Proof of Reserves, Liquid Restaking Tokens (LRT), Bitcoin Liquid Staking, and Oracle Extractable Value (OEV): enabling greater efficiency in liquidation events, resulting in incremental revenue generation.
8. Flexibility for Developers: Allows customization of data for unique use cases, including implementing bespoke data logic and dedicated pricing solutions.
Access to RedStone’s services will be available to token holders, ensuring an integrated and incentivized ecosystem. Here’s how it works:
1. Token-Backed Access: Users and developers will be required to hold RedStone tokens to gain full access to certain services, fostering alignment with the ecosystem’s growth and long-term sustainability.
2. Staking Mechanism: Token holders can stake their tokens to support data providers (node operators), ensuring the delivery of premium, high-quality data. In return, stakers can earn rewards based on their contribution.
3. Service-Level Agreements: Data providers must lock RedStone tokens as collateral to guarantee service quality and reliability. This mechanism incentivizes consistent and accurate data delivery.
4. Delegation for Rewards: Token holders who don’t directly use the services can delegate their tokens to trusted data providers, sharing in the rewards generated by the ecosystem.
Article 3 (1) (5) For the purposes of this Regulation, the following definitions apply:
(5) ‘crypto-asset’ means a digital representation of a value or of a right that is able to be transferred and stored electronically using distributed ledger technology or similar technology
Article 3 (1) (9) For the purposes of this Regulation, the following definitions apply:
(9) ‘utility token’ means a type of crypto-asset that is only intended to provide access to a good or a service supplied by its issuer
Article 3 (1) (30) For the purposes of this Regulation, the following definitions apply:
(30) Where an offer to the public concerns utility tokens for goods that do not yet exist or services that are not yet in operation, the duration of the offer to the public as described in the crypto-asset white paper should not exceed 12 months. That limitation on the duration of the offer to the public is unrelated to the moment when the goods or services come into existence or become operational and can be used by the holder of a utility token after the expiry of the offer to the public.
Article 3 (1) (37)
For the purposes of this Regulation, the following definitions apply:
(37) ‘retail holder’ means any natural person who is acting for purposes which are outside that person’s trade, business, craft or profession
Article 3 (1) (38) For the purposes of this Regulation, the following definitions apply:
(38) ‘online interface’ means any software, including a website, part of a website or an application, that is operated by or on behalf of an offeror or crypto-asset service provider, and which serves to give holders of crypto-assets access to their crypto-assets and to give clients access to crypto-asset services
Article 3 (1) (39)
For the purposes of this Regulation, the following definitions apply:
(39) ‘client’ means any natural or legal person to whom a crypto-asset service provider provides crypto-asset services
Article 5 1. A person shall not seek admission to trading of a crypto-asset other than an asset-referenced token or e-money token within the Union unless that person:
(a) is a legal person;
(b) has drawn up a crypto-asset white paper in respect of that crypto-asset in accordance with Article 6;
(c) has notified the crypto-asset white paper in accordance with Article 8;
(d) has published the crypto-asset white paper in accordance with Article 9;
(e) has drafted the marketing communications, if any, in respect of that crypto-asset in accordance with Article 7;
(f) has published the marketing communications, if any, in respect of that crypto-asset in accordance with Article 9;
(g) complies with the requirements for persons seeking admission to trading laid down in Article 14.
2. When a crypto-asset is admitted to trading on the initiative of the operator of a trading platform and a cryptoasset white paper has not been published in accordance with Article 9 in the cases required by this Regulation, the operator of that trading platform for crypto-assets shall comply with the requirements set out in paragraph 1 of this Article.
3. By way of derogation from paragraph 1, a person seeking admission to trading of a crypto-asset other than an asset-referenced token or e-money token and the respective operator of the trading platform may agree in writing that it shall be the operator of the trading platform who is required to comply with all or part of the requirements referred to in paragraph 1, points (b) to (g).
The agreement in writing referred to in the first subparagraph of this paragraph shall clearly state that the person seeking admission to trading is required to provide the operator of the trading platform with all necessary information to enable that operator to satisfy the requirements referred to in paragraph 1, points (b) to (g), as applicable.
4. Paragraph 1, points (b), (c) and (d), shall not apply where:
(a) the crypto-asset is already admitted to trading on another trading platform for crypto-assets in the Union; and
(b) the crypto-asset white paper is drawn up in accordance with Article 6, updated in accordance with Article 12, and the person responsible for drawing up such white paper consents to its use in writing.
Article 6 1. A crypto-asset white paper shall contain all of the following information, as further specified in Annex I:
(a) information about the offeror or the person seeking admission to trading;
(b) information about the issuer, if different from the offeror or person seeking admission to trading;
(c) information about the operator of the trading platform in cases where it draws up the crypto-asset white paper;
(d) information about the crypto-asset project;
(e) information about the offer to the public of the crypto-asset or its admission to trading;
(f) information about the crypto-asset;
(g) information on the rights and obligations attached to the crypto-asset;
(h) information on the underlying technology;
(i) information on the risks;
(j) information on the principal adverse impacts on the climate and other environment-related adverse impacts of the consensus mechanism used to issue the crypto-asset.
In cases where the crypto-asset white paper is not drawn up by the persons referred to in the first subparagraph, points (a), (b) and (c), the crypto-asset white paper shall also include the identity of the person that drew up the crypto-asset white paper and the reason why that particular person drew it up.
2. All of the information listed in paragraph 1 shall be fair, clear and not misleading. The crypto-asset white paper shall not contain material omissions and shall be presented in a concise and comprehensible form.
3. The crypto-asset white paper shall contain the following clear and prominent statement on the first page:
‘This crypto-asset white paper has not been approved by any competent authority in any Member State of the European Union. The offeror of the crypto-asset is solely responsible for the content of this crypto-asset white paper.’.
Where the crypto-asset white paper is drawn up by the person seeking admission to trading or by an operator of a trading platform, then, instead of ‘offeror’, a reference to ‘person seeking admission to trading’ or ‘operator of the trading platform’ shall be included in the statement referred to in the first subparagraph.
4. The crypto-asset white paper shall not contain any assertions as regards the future value of the crypto-asset, other than the statement referred to in paragraph 5.
5. The crypto-asset white paper shall contain a clear and unambiguous statement that:
(a) the crypto-asset may lose its value in part or in full;
(b) the crypto-asset may not always be transferable;
(c) the crypto-asset may not be liquid;
(d) where the offer to the public concerns a utility token, that utility token may not be exchangeable against the good or service promised in the crypto-asset white paper, especially in the case of a failure or discontinuation of the crypto-asset project;
(e) the crypto-asset is not covered by the investor compensation schemes under Directive 97/9/EC of the European Parliament and of the Council (35);
(f) the crypto-asset is not covered by the deposit guarantee schemes under Directive 2014/49/EU.
6. The crypto-asset white paper shall contain a statement from the management body of the offeror, the person seeking admission to trading or the operator of the trading platform. That statement, which shall be inserted after the statement referred to in paragraph 3, shall confirm that the crypto-asset white paper complies with this Title and that, to the best of the knowledge of the management body, the information presented in the crypto-asset white paper is fair, clear and not misleading and the crypto-asset white paper makes no omission likely to affect its import.
7. The crypto-asset white paper shall contain a summary, inserted after the statement referred to in paragraph 6, which shall in brief and non-technical language provide key information about the offer to the public of the crypto-asset or the intended admission to trading. The summary shall be easily understandable and presented and laid out in a clear and comprehensive format, using characters of readable size. The summary of the crypto-asset white paper shall provide appropriate information about the characteristics of the crypto-asset concerned in order to help prospective holders of the crypto-asset to make an informed decision.
The summary shall contain a warning that:
(a) it should be read as an introduction to the crypto-asset white paper;
(b) the prospective holder should base any decision to purchase the crypto-asset on the content of the crypto-asset white paper as a whole and not on the summary alone;
(c) the offer to the public of the crypto-asset does not constitute an offer or solicitation to purchase financial instruments and that any such offer or solicitation can be made only by means of a prospectus or other offer documents pursuant to the applicable national law;
(d) the crypto-asset white paper does not constitute a prospectus as referred to in Regulation (EU) 2017/1129 of the European Parliament and of the Council (36) or any other offer document pursuant to Union or national law.
8. The crypto-asset white paper shall contain the date of its notification and a table of contents.
9. The crypto-asset white paper shall be drawn up in an official language of the home Member State, or in a language customary in the sphere of international finance.
Where the crypto-asset is also offered in a Member State other than the home Member State, the crypto-asset white paper shall also be drawn up in an official language of the host Member State, or in a language customary in the sphere of international finance.
10. The crypto-asset white paper shall be made available in a machine-readable format.
11. ESMA, in cooperation with EBA, shall develop draft implementing technical standards to establish standard forms, formats and templates for the purposes of paragraph 10.
ESMA shall submit the draft implementing technical standards referred to in the first subparagraph to the Commission by 30 June 2024.
Power is conferred on the Commission to adopt the implementing technical standards referred to in the first subparagraph in accordance with Article 15 of Regulation (EU) No 1095/2010.
12. ESMA, in cooperation with EBA, shall develop draft regulatory technical standards on the content, methodologies and presentation of the information referred to in paragraph 1, first subparagraph, point (j), in respect of the sustainability indicators in relation to adverse impacts on the climate and other environment‐related adverse impacts.
When developing the draft regulatory technical standards referred to in the first subparagraph, ESMA shall consider the various types of consensus mechanisms used to validate transactions in crypto-assets, their incentive structures and the use of energy, renewable energy and natural resources, the production of waste and greenhouse gas emissions. ESMA shall update those regulatory technical standards in the light of regulatory and technological developments.
ESMA shall submit the draft regulatory technical standards referred to in the first subparagraph to the Commission by 30 June 2024.
Power is delegated to the Commission to supplement this Regulation by adopting the regulatory technical standards referred to in the first subparagraph of this paragraph in accordance with Articles 10 to 14 of Regulation (EU) No 1095/2010.
Article 13 1. Retail holders who purchase crypto-assets other than asset-referenced tokens and e-money tokens either directly from an offeror or from a crypto-asset service provider placing crypto-assets on behalf of that offeror shall have a right of withdrawal.
Retail holders shall have a period of 14 calendar days within which to withdraw from their agreement to purchase crypto-assets other than asset-referenced tokens and e-money tokens without incurring any fees or costs and without being required to give reasons. The period of withdrawal shall begin from the date of the agreement of the retail holder to purchase those crypto-assets.
2. All payments received from a retail holder including, if applicable, any charges, shall be reimbursed without undue delay and in any event no later than 14 days from the date on which the offeror or the crypto-asset service provider placing crypto-assets on behalf of that offeror is informed of the retail holder’s decision to withdraw from the agreement to purchase those crypto-assets.
Such reimbursement shall be carried out using the same means of payment as that used by the retail holder for the initial transaction, unless the retail holder expressly agrees otherwise and provided that the retail holder does not incur any fees or costs as a result of such reimbursement.
3. Offerors of crypto-assets shall provide information on the right of withdrawal referred to in paragraph 1 in their crypto-asset white paper.
4. The right of withdrawal referred to in paragraph 1 shall not apply where the crypto-assets have been admitted to trading prior to their purchase by the retail holder.
5. Where offerors have set a time limit on their offer to the public of such crypto-assets in accordance with Article 10, the right of withdrawal shall not be exercised after the end of the subscription period.
Article 14 1. Offerors and persons seeking admission to trading of crypto-assets other than asset-referenced tokens or e-money tokens shall:
(a) act honestly, fairly and professionally;
(b) communicate with holders and prospective holders of the crypto-assets in a fair, clear and not misleading manner;
(c) identify, prevent, manage and disclose any conflicts of interest that might arise;
(d) maintain all of their systems and security access protocols in conformity with the appropriate Union standards.
For the purposes of point (d) of the first subparagraph, ESMA, in cooperation with EBA, shall by 30 December 2024 issue guidelines in accordance with Article 16 of Regulation (EU) No 1095/2010 to specify those Union standards.
2. Offerors and persons seeking admission to trading of crypto-assets other than asset-referenced tokens or e-money tokens shall act in the best interests of the holders of such crypto-assets and shall treat them equally, unless any preferential treatment of specific holders and the reasons for that preferential treatment are disclosed in the crypto-asset white paper and, where applicable, the marketing communications.
3. Where an offer to the public of a crypto-asset other than an asset-referenced token or e-money token is cancelled, offerors of such crypto-asset shall ensure that any funds collected from holders or prospective holders are duly returned to them no later than 25 calendar days after the date of cancellation.
Article 15 1. Where an offeror, person seeking admission to trading or operator of a trading platform, has infringed Article 6 by providing in its crypto-asset white paper or in a modified crypto-asset white paper information that is not complete, fair or clear or that is misleading, that offeror, person seeking admission to trading or operator of a trading platform and the members of its administrative, management or supervisory body shall be liable to a holder of the crypto-asset for any loss incurred due to that infringement.
2. Any contractual exclusion or limitation of civil liability as referred to in paragraph 1 shall be deprived of legal effect.
3. Where the crypto-asset white paper and marketing communications are prepared by the operator of the trading platform in accordance with Article 5(3), the person seeking admission to trading shall also be held responsible when it provides information that is not complete, fair or clear, or that is misleading to the operator of the trading platform.
4. It shall be the responsibility of the holder of the crypto-asset to present evidence indicating that the offeror, person seeking admission to trading, or operator of the trading platform for crypto-assets other than asset-referenced tokens or e-money tokens has infringed Article 6 by providing information that is not complete, fair or clear, or that is misleading and that reliance on such information had an impact on the holder’s decision to purchase, sell or exchange that cryptoasset.
5. The offeror, person seeking admission to trading, or operator of the trading platform and the members of its administrative, management or supervisory body shall not be liable to a holder of a crypto-asset for loss incurred as a result of reliance on the information provided in a summary as referred to in Article 6(7), including any translation thereof, except where the summary:
(a) is misleading, inaccurate or inconsistent when read together with the other parts of the crypto-asset white paper; or
(b) does not provide, when read together with the other parts of the crypto-asset white paper, key information in order to aid prospective holders of the crypto-asset when considering whether to purchase such crypto-asset.
6. This Article is without prejudice to any other civil liability pursuant to national law
Push oracles, on the other side, are easier to use and could be more efficient where the same feed is accessed by multiple dApps. Ability to support both the push and pull model is complemented by a focus on technical innovation, optimized infrastructure for computational efficiency, and personalized customization at every stage of oracle implementation, from initial setup to ongoing support.
With a commitment to top-tier security standards and a constantly open line for exploring new concepts, the result is a unique experience that RedStone has been adopted by over 120 teams across 70+ chains by the end of 2024.
Chainlink is often directly associated with the oracle category. As the first project to address the oracle problem at scale in 2018, it enabled on-chain digital asset price quoting while striving to mitigate centralization risks inherent to off-chain data usage. Chainlink launched on Ethereum in May 2019 with a single ETH/USD price feed. Over time, it expanded to include additional price feeds across a handful of blockchains and introduced new products like VRFs, Web3 Functions, and Proof of Reserves.
RedStone strives for the highest quality of service across all dimensions, aiming to elevate DeFi into a globally strategic sector while staying true to its roots, embodied in its motto: By Builders, For Builders.
In a push model, oracle price feeds are updated on-chain whenever specific conditions are met. This can happen through periodic updates at fixed intervals—known as the “heartbeat” time, such as every 30 minutes or an hour—or when the price deviates significantly from the last update, a condition called the “deviation threshold,” typically measured in percentages. Updates occur regardless of the computational cost, which notably, on Ethereum Mainnet, can sometimes exceed USD 100 in gas fees for a single update.
RedStone supports both Push and Pull Model implementations, making it a go-to solution for blockchain platforms and the applications that consume oracle price feeds. With a diverse range of over 1,000 price feeds in the Pull Model, 100+ in the Push Model and ability to quickly serve needed feeds, RedStone serves as a trusted oracle partner for blockchain networks and the builders that greatly benefit from its products.
Platforms like EigenLayer and Symbiotic enable restaking, allowing oracle systems to dynamically scale their security resources to meet evolving demands. This approach offers three significant benefits when integrating AVS (Actively Validated Service), a protocol leveraging restaking, into an oracle system.
1. The architecture is designed and meticulously audited as a universal restaking layer, not limited to any single protocol’s use case. Building on this universal framework is significantly faster and more cost-effective than creating a system from scratch.
2. Security as a Service: It provides flexibility tailored to the maturity of the oracle network. Early-stage players can minimize restaked security to avoid the high issuance costs, with the system allowing for a gradual increase in utilized security as the oracle grows and protects more valuable assets.
3. Restaking also enables the use of diverse collateral types, such as native oracle token, ETH, LSTs, LRTs and stablecoins. Additionally, it standardizes operator onboarding, simplifying the process for bootstrapping the network effects.
RedStone has prioritized restaking from its very early days, being among the first to adopt it as a fully operational protocol for further scaling and decentralizing the system. The Push Model implementation utilizing EigenLayer’s shared security is already in active testing and will soon become part of core operations. RedStone collaborates with shared security leaders like Symbiotic, Babylon, and Jito to advance the understanding of the technology’s potential and foster a positive-sum approach for the oracle industry. Key focus areas include lowering AVS costs on Ethereum Mainnet, developing a dual staking model, and the phased rollout of AVS-powered Push Model on multiple, new networks.
Any data provider that fulfils the need to publish a manifest and deposit collateral is eligible to collect fees from data feeds users. The fees can be expressed as a fixed rate subscription or charged separately per every access. The protocol doesn’t impose any restriction on the price model and means of payment agreed between data providers and users. There is also no commission or other administrative fee collected by the protocol itself. The fees could be expressed in the most popular and liquid blockchain tokens like ETH, SOL, ARB etc..or stable coins like USDC, USDT or DAI, but not in the RedStone token itself.
However, for blockchain networks to unlock their broader potential, they need a way to interact with the wider world. Realizing the full scope of blockchain applications requires connections that enable data exchange between blockchains and diverse technologies, spanning from web protocols and financial systems to IoT devices, machine learning models, and advanced cryptographic methods like zero-knowledge proofs. These connections allow blockchains to become far more versatile, and capable of supporting actual user-demanding use cases by integrating with external data sources.
Finance, a field where blockchain technology has already proven transformative, presents a clear example of the demand for such connections. Decentralized Finance (DeFi) emerged from blockchain’s permissionless nature and has rapidly expanded, evolving from basic peer-to-peer exchanges into a sophisticated ecosystem of applications. Today’s DeFi landscape includes primitives that rival the sophistication of traditional finance, such as range-specific Automated Market Maker (AMM) exchanges and perpetual exchanges—the most popular derivative products in crypto—as well as DeFi-native options and swap contracts. Additionally, money markets, commonly known as lending protocols, facilitate extreme liquidity depth and support significant open interest daily. DeFi also drives innovation in Real-World Asset (RWA) trading, with the stablecoin industry being one of its most adopted primitives. Projects like Angle issue RWA-backed stablecoins, while Ethena develops algorithmic stablecoin that enhance global settlement layers and address unequal access to stable currency yields. Beyond that, Securitize opens new opportunities at the intersection of crypto and traditional finance by facilitating the tokenization of various securities, while CoinDesk’s CESR empowers builders by offering access to yield data that was previously inaccessible, unlocking new possibilities for on-chain innovation. Another significant DeFi sub-industry involves automated revenue-sharing mechanisms, such as auction models tackling block-production dynamics like Maximum Extractable Value (MEV) and Oracle Extractable Value (OEV). Finally, the Liquid Staking sector for Ether, Bitcoin, and other blue-chip assets enhances capital efficiency and liquidity, fostering a more dynamic and robust liquidity profile within the on-chain economy. These tools not only cater to retail users but also lay the groundwork for institutional interest, offering DeFi’s unique transparency, borderless accessibility, and security.
The increasing complexity in DeFi, coupled with a surge in participants, has created a pressing demand for a new generation of oracles. While traditional oracles enabled the initial proof of concept for the category, the evolving DeFi landscape now requires oracles that are ultimately secure, flexible and efficient and meet rigorous robustness standards. Next-generation oracle networks must support diverse interactions and deliver reliable data feeds, allowing arbitrary external information to integrate seamlessly into blockchain systems. As various categories of dApps continue to evolve, oracles will play an essential role in creating robust, interconnected systems that push the boundaries of what blockchain networks can achieve.
b. Risk of withdrawing partners: The feasibility of the ecosystem created by RedStone depends strongly on the collaboration of game developers and other crucial partners of RedStone. There is, therefore, no assurance that the ecosystem created by RedStone as a whole or parts thereof will be successfully executed as set out in these terms or otherwise.
c. Risk associated with other applications: The ecosystem created by RedStone may give rise to other, alternative projects, promoted by unaffiliated third parties, under which Cryptoasset has no intrinsic value.
d. Risk of Force Majeure: RedStone in no event shall be responsible or liable for any failure or delay in the performance of the project, smart contract system, an ecosystem created by RedStone, third-party service providers, exchanges and/or financial intermediaries arising out of or caused by, directly or indirectly, forces beyond its control, including, without limitation, embargos, governmental restrictions, strikes, work stoppages, accidents, acts of war or terrorism, civil or military disturbances, nuclear or natural catastrophes or acts of God, and interruptions, loss or malfunctions of utilities, communications or computer (software and hardware) services.
b. Risk of Loss of Private Key: Cryptoasset can only be accessed by using a blockchain wallet with a combination of the holder's account information (address), private key, password and any other protection means. If this data is lost or stolen, the Cryptoasset associated with the holder's account (address) or password may be unrecoverable and permanently lost.
c. Risk of depreciation: Regarding Cryptoasset no market liquidity may be guaranteed. The value of Cryptoasset over time may experience extreme volatility or depreciate in full.
b. Financial Risk: Even if all or parts of the ecosystem created by the RedStone are successfully developed and released in full or in parts, due to a lack of public interest, the ecosystem created by the RedStone could be fully or partially abandoned, remain unsuccessful or be shut down for lack of interest, regulatory or other reasons. The contribution to the RedStone and/or and the acceptance of Cryptoasset carries significant financial, regulatory and/or reputational risks (including the complete loss of value of the created Cryptoasset (if any), and attributed features of the ecosystem created by the RedStone).
b. Risk of cryptographic weakness: The blockchain and all software dependent thereon, such as the ecosystem to be created by the RedStone and Cryptoasset are based on the effectiveness and reliability of cryptographic solutions. However, cryptography is evolving and cannot guarantee absolute security at all times. Advances in cryptography, such as code cracking, or technical advances such as the development of quantum computers, could present risks to all cryptography-based systems including the ecosystem created by the RedStone and Cryptoasset. This could result in the theft, loss, disappearance, destruction or devaluation of the Cryptoasset.
c. Risks related to unverified source code: The source code of the ecosystem to be created by the RedStone may be licensed under open-source license terms and any party related or unrelated to the ecosystem to be created by the RedStone can propose updates, amendments, alterations or modifications to the source code. RedStone may not be able to verify or guarantee the precise results of such updates, amendments, alterations or modifications and as a result, any update, amendment, alteration or modification could lead to an unexpected or unintended outcome that adversely affects the ecosystem created by the RedStone or the Cryptoasset.
d. Risk of theft: The smart contract system concept, the underlying software application and software platform (i.e. the blockchain), or other assets of the RedStone, may be exposed to attacks by hackers or other individuals that could result in theft or loss of Cryptoasset, other (financial) support of the RedStone, which may lead to loss or devaluation of contributed funds and or Cryptoasset ant impacting the ability to develop the ecosystem created by the RedStone.
e. Risk of mining attacks and other malicious attacks: As with other cryptocurrencies, the blockchain used for the smart contract system is susceptible to mining and other malicious attacks, including but not limited to double-spend attacks, majority mining power attacks, “selfish-mining” attacks, and race condition attacks. Any successful attacks present a risk to the smart contract system, expected proper execution and sequencing of Cryptoasset transactions, and expected proper execution and sequencing of contract computations.
f. Risk of incompatible wallet service: The wallet or wallet service provider used by the investor for the contribution, has to be technically compatible with the Cryptoasset. The failure to assure this may have the result that the investor will not gain access to his Cryptoasset.
Platforms like EigenLayer and Symbiotic enable restaking, allowing oracle systems to dynamically scale their security resources to meet evolving demands. This approach offers three significant benefits when integrating AVS (Actively Validated Service), a protocol leveraging restaking, into an oracle system.
1. The architecture is designed and meticulously audited as a universal restaking layer, not limited to any single protocol’s use case. Building on this universal framework is significantly faster and more cost-effective than creating a system from scratch.
2. Security as a Service: It provides flexibility tailored to the maturity of the oracle network. Early-stage players can minimize restaked security to avoid the high issuance costs, with the system allowing for a gradual increase in utilized security as the oracle grows and protects more valuable assets.
3. Restaking also enables the use of diverse collateral types, such as native oracle token, ETH, LSTs, LRTs and stablecoins. Additionally, it standardizes operator onboarding, simplifying the process for bootstrapping the network effects.
RedStone has prioritized restaking from its very early days, being among the first to adopt it as a fully operational protocol for further scaling and decentralizing the system. The Push Model implementation utilizing EigenLayer’s shared security is already in active testing and will soon become part of core operations. RedStone collaborates with shared security leaders like Symbiotic, Babylon, and Jito to advance the understanding of the technology’s potential and foster a positive-sum approach for the oracle industry. Key focus areas include lowering AVS costs on Ethereum Mainnet, developing a dual staking model, and the phased rollout of AVS-powered Push Model on multiple, new networks.
Any data provider that fulfils the need to publish a manifest and deposit collateral is eligible to collect fees from data feeds users. The fees can be expressed as a fixed rate subscription or charged separately per every access. The protocol doesn’t impose any restriction on the price model and means of payment agreed between data providers and users. There is also no commission or other administrative fee collected by the protocol itself. The fees could be expressed in the most popular and liquid blockchain tokens like ETH, AVAX, CELO, MATIC, etc..or stable coins like USDC, USDT or DAI, but not in the RedStone token itself.
 |
||