[RENDER] Other Crypto-Asset - Whitepaper - OEUR

CRYPTO-ASSET WHITE PAPER - [RENDER]

Version Number: 1.0

Document Type: White Paper

Document Author Offeror: OKCoin Europe Ltd

Document Status: APPROVED

Language: English

TABLE OF CONTENTS

I. DATE OF NOTIFICATION II. STATEMENTS III. WARNING IV. INFORMATION ON RISKS

1. Offer-Related Risks

2. Issuer-Related Risks

3. Crypto-Assets-Related Risks

4. Project Implementation-Related Risks

5. Technology-Related Risks

6. Mitigation Measures V. GENERAL INFORMATION A. Information of the Offeror or the Person Seeking Admission to Trading B. Information of the Issuer C. Information about OKCoin Europe LTD ("OKX") C. Other Information VI. INFORMATION ABOUT THE CRYPTO-ASSET 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-Assets G. Information about the Rights and Obligations Attached to the Crypto-Asset H. Information about the Underlying Technology I. Information on the Principal Adverse Impacts on the Climate and Other Environmental-Related Adverse Impacts of the Consensus Mechanism Used to Issue the Crypto-Asset. VII. GLOSSARY

DATE OF NOTIFICATION

The Date of Notification of this Crypto-Asset White Paper is 2025-10-24.

STATEMENTS

A. This Crypto-Asset White Paper has not been approved by any Competent Authority in any Member State of the European Union. OKCoin Europe Ltd is solely responsible for the content of this Crypto-Asset White Paper.

B. This Crypto-Asset White Paper complies with Title II of the Regulation (EU) 2923/1114, 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.

C. The Crypto-Asset White Paper provides that RENDER may not be transferable, or liquid, or lose its value, in part or in full.

D. The Utility Token referred to in this Crypto-Asset White Paper 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. This statement is TRUE.

E. The Crypto-Asset referred to in this Crypto-Asset White Paper is not covered by the investor compensation schemes under the Directive 97/9/EC of the European Parliament and of the Council.

F. The Crypto-Asset referred to in this Crypto-Asset White Paper is not covered by the deposit guarantee schemes under Directive 2014/49/EU of the European Parliament and of the Council.

WARNING

A. The summary should be read in conjunction with the content of the Crypto-Asset White Paper.

B. 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.

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. This Crypto-Asset White Paper does not constitute a prospectus as referred to in the Regulation (EU) 2017/1129 of the European Parliament and the Council or any other offer document pursuant to the European Union or National Law.

E. The crypto-asset RENDER token is a utility token issued on the Solana blockchain using the Solana Program Library ("SPL") token standard. It is intended to be used as a medium of exchange within the Render Network ecosystem, enabling access to distributed graphics processing unit (GPU) rendering and compute services. The RENDER token is designed to facilitate payments between users requesting compute resources and those providing them, supporting the operation of a decentralized rendering network. This whitepaper is submitted by OKCoin Europe Ltd in the context of the tokens admission to trading, and does not constitute a public offering of the crypto-asset.

F. The RENDER token provides access to decentralized GPU rendering and compute services on the Render Network. Users redeem RENDER by burning tokens to submit rendering jobs, which are processed by node operators who earn newly minted RENDER tokens as compensation. There is no fixed quantity of services per token, and the amount of compute resources obtained depend on network pricing at the time of job submission, which would be denominated in the FIAT currency of USD and converted to the crypto-asset, RENDER. The RENDER token is freely and instantly transferable, utilising the underlying blockchain network's standard processes.

G. This whitepaper is published solely in connection with the admission to trading of the RENDER token on OKCoin Europe Ltd's trading platform. There has been no offer of the crypto-asset to the public, and the crypto-asset has not been made available in exchange for FIAT currency or other crypto-assets prior to its listing. The crypto-asset will be admitted to trading via OKCoin Europe Ltd, a Malta limited liability company registered in Malta, licensed as a Crypto-Asset Service Provider by the Malta Financial Services Authority, bearing license number OEUR-24352, to provide crypto services under the Markets in Crypto-Assets Act, Chapter 647, Laws of Malta, within the European Economic Area. The trading admission of the RENDER token would not involve any subscription, sale, or fundraising process. The purpose of the whitepaper is to provide key information regarding the characteristics of the crypto-asset, its governance, rights, and associated risks, to enable users and market participants to make informed decisions in the context of the crypto-asset's admission to trading. Access to the crypto-asset on the trading platform may be subject to user verification, platform conditions, or applicable legal restrictions depending on the jurisdiction.

INFORMATION ON RISKS

1. Offer-Related Risks

This whitepaper is submitted by OKCoin Europe LTD solely for the purpose of the assets admission to trading, and no public offer of RENDER tokens is being made by the Issuer or OKCoin Europe LTD.

Risks associated with the admission to trading include;

1. Service-related interruption; Holders may be unable to access the utility due to technical, operation, or regulatory disruptions.

2. Jurisdictional limitations; Render Network services or token utility may not be available in all jurisdictions, hence potentially restricting access.

3. Platform reliance; Access depends on third-party infrastructure including but not limited to wallets and platforms, and service interruptions or failures may affect token utility.

4. Limited liability; OKCoin Europe LTD assumes no responsibility for the Issuers Project continuation, and token ownership does not confer contractual rights or guarantees.

5. Unexpected Risks: Beyond the risks outlined in this whitepaper, there may be additional risks that are currently unforeseen. It is imperative to note that certain risks may emerge from unforeseen events, changes, or interactions among factors that are difficult to predict. These unexpected risks may significantly and negatively impact the crypto-asset, the project, or the parties involved.

2. Issuer-Related Risks

1. Operational Risks; There is a risk that the Issuer may face financial or operational difficulties, including insolvency, which could impact the continued development or availability of the services associated with the RENDER token.

2. Counterparty Risks; Counterparty risks may arise where the Issuer relies on third-party service providers or technology partners.

3. Reputational Risks; Adverse media and/or damage or loss of key personnel could negatively affect the ecosystem that the RENDER token is deployed on.

4. Competition Risk; The Issuer may face increased competition or changes in market conditions that may affect its ability to carry out its objectives.

5. Disclosure Risks; The Issuer may not be required to provide financial statements thus may limit RENDER token holders visibility into the financial health status of the Issueror Project.

6. Issuer Risks; The information provided is based solely on publicly available sources and does not constitute any form of guarantee or warranty as to its accuracy or completeness.

3. Crypto-Assets-Related Risks

1. Market Volatility; The RENDER token may be subject to significant volatility and could lose value rapidly, either due to market conditions or otherwise (Issuer-related/technology/Project implementation risks)

2. Utility Risk; The RENDER tokens utility depends on access to certain services, and any modification or discontinuation of those services could reduce the associated utility of the token.

3. Smart Contract Risk; The RENDER token operates through smart contracts that may contain vulnerabilities, even if audited, and upgrades to the protocol or governance changes may affect functionality.

4. Liquidity Risk; Periods of low/limited liquidity may occur, particularly if the demand for the token or its use case decreases, which may have an adverse effect on the RENDER token price and future use cases.

4. Project Implementation-Related Risks

1. Scalability Issues; There may be a risk that the Project may not be implemented or scaled as intended, given that technical limitations or infrastructure bottlenecks could hinder the expected scalability of the Project, more so should user demand exceed the network or protocol capacity.

2. Governance Risk; The Project may be subject to governance processes that could involve on-chain voting or community proposals. Therefore, any misaligned incentives, low participation, or malicious actors could affect the outcome of governance decisions and ultimately disrupt the Project's roadmap.

3. Centralisation Risk; Similar to governance risks outlined above, centralisation within the governance process, or validator centralisation could lead to a lack of decentralisation within the network, which may carry future risks in terms of trust within the Project, but also with regard to future roadmaps where plans may not reflect the interests of the broader user base.

5. Technology-Related Risks

1. Blockchain Performance Risk; The Solana blockchain, on which the RENDER token has been issued, may experience downtime or congestion resulting in potential delays or prevent token transfer or utility usage.

2. Consensus Failure Risk; A failure in the blockchains consensus mechanism could result in halted transactions, unexpected behaviour, or loss in network integrity.

3. Smart Contract Vulnerabilities; Although the RENDER token uses audited or standard smart contract makeups for example the SPL Token Program, undetected bugs, exploits, or implementation errors could compromise functionality or security.

4. Upgradeability Risk; if the RENDER token or related contracts are upgradeable and have designated "owner" addresses, this introduces a central point of failure, and could be misused by malicious actors.

5. Third-party Infrastructure Dependency; Interaction with the RENDER token or Project may rely on external infrastructure through APIs, wallet services, and off-chain governance voting. Additionally, outages or attacks may interrupt access to token-related services.

6. Interoperability Risk; If the RENDER token interacts with other chains, bridges, or oracles, failures or exploits in those systems could affect the tokens operations.

7. Protocol-level Risk; Upgrades or forks of the protocol itself may affect the RENDER token, which could lead to compatibility issues and/or unexpected token behaviour.

8. Emerging Technology Risk; Advances in computing or undiscovered vulnerabilities in cryptographic algorithms may pose long-term security risks to the blockchain or associated smart contracts

6. Mitigation Measures

1. Blockchain Performance Risk; The Solana blockchain design prioritises throughput and speed by combining Proof-of-History with Proof-of-Stake. The validator set is geographically diverse, and further performance improvements are ongoing.

2. Consensus Failure Risk; Solana's consensus mechanism is supported by stake-weighted voting and finality checkpoints. Validators face slashing if they act in a malicious manner. Updates on Solana uptime can be found here; https://status.solana.com/

3. Smart Contract Vulnerabilities; Smart contracts on Solana are immutable by design, unless explicitly designed to be upgradeable. The ecosystem encourages open source code, independent audits, and community input.

4. Upgradeability Risk; Solana does not enforce upgrade functionalities within smart contracts, but supports their technical implementation. Risks related to upgradeable contracts may be mitigated through standard practices such as multi-signature wallets.

5. Third-party Infrastructure Dependency; Solana supports multiple independent Remote Procedure Call (RPC) providers within the ecosystem, which would enable infrastructure diversification.

6. Interoperability Risk; Mitigations for cross-chain bridging include usage of audited bridges and token locking mechanisms.

7. Protocol-level Risk; Solana maintains a public roadmap and follows a structured governance process, with core updates to the network undergoing extensive testing and community reviews.

8. Emerging Technology Risk; Solana developers monitor potential emerging technology threats, and actively research and develop quantum-resistant solutions. Solana has implemented a quantum-resistant feature through the optional Solana Winternitz Vault as of January 2025.

GENERAL INFORMATION

A. Information of the Offeror or the Person Seeking Admission to Trading

• A.1 Name: N/A

• A.2 Legal Entity Identifier (LEI): N/A

• A.3 Legal Form, if applicable: N/A

• A.4 Registered Office, if applicable: N/A

• A.5 Head Office, if applicable: N/A

• A.6 Date of Registration [YYYY-MM-DD]: N/A

• A.7 Legal Entity Number: N/A

• A.8 Contact Telephone Number: N/A

• A.9 E-Mail Address: N/A

• A.10 Response Time (days): N/A

• A.11 Members of Management Body: N/A

• A.12 Business Activity: N/A

• A.13 Newly Established: N/A

• A.14 Financial Condition for the past Three Years: N/A

• A.15 Financial Condition since Registration: N/A

• A.16 Parent Company, if applicable: N/A

• A.17 Parent Company Business Activity, if applicable: N/A

B. Information of the Issuer

This section shall ONLY be completed if the information is different to that listed in section 1, above.

• B.1 Is the Issuer different from an offeror or person seeking admission to trading?: TRUE

• B.2 Name: Render Network Foundation

• B.3 Legal Entity Identifier (LEI): No information could be identified in regards to this field at the time of drafting this whitepaper.

• B.4 Legal Form, if applicable: Foundation

• B.5 Registered Office, if applicable: No information could be identified in regards to this field at the time of drafting this whitepaper.

• B.5 Head Office, if applicable: No information could be identified in regards to this field at the time of drafting this whitepaper.

• B.6 Date of Registration [YYYY-MM-DD]: No information could be identified in regards to this field at the time of drafting this whitepaper.

• B.7 Legal Entity Number: No information could be identified in regards to this field at the time of drafting this whitepaper.

• B.8 Members of the Management Body:

  • Line ID 1: No information could be identified in regards to this field at the time of drafting this whitepaper.

  • Identity: No information could be identified in regards to this field at the time of drafting this whitepaper.

  • Business Address: No information could be identified in regards to this field at the time of drafting this whitepaper.

  • Function: No information could be identified in regards to this field at the time of drafting this whitepaper.

• B.9 Business Activity: The Render Network Foundation is the governance organization for the Render Network, providing a community led decentralized governance framework and process for shaping the future of the Render Network.

• B.10 Parent Company: No information could be identified in regards to this field at the time of drafting this whitepaper.

• B.11 Parent Company Business Activity: No information could be identified in regards to this field at the time of drafting this whitepaper.

C. Information about OKCoin Europe LTD ("OKX")

This section shall ONLY be completed if OKX draws up the Crypto-Asset White Paper.

• C.1 Name: OKCoin Europe LTD

• C.2 Legal Entity Identifier: 54930069NLWEIGLHXU42

• C.3 Legal Form, if applicable: Limited Liability Company

• C.4 Registered Office, if applicable: Piazzetta Business Plaza, Office Number 4, Floor 2, Triq Ghar il-Lembi, Sliema SLM1562, Malta

• C.5 Head Office, if applicable: See C.4

• C.6 Date of Registration: 2018-09-07

• C.7 Legal Entity Registration Number: C 88193

• C.8 Members of Management Body:

  • Line ID 1: Erald Henri J. Ghoos, Business Address: See C.4, Function: Director

  • Line ID 2: Fang Hong, Business Address: See C.4, Function: Director

  • Line ID 3: Joseph Portelli, Business Address: See C.4, Function: Director

  • Line ID 4: Wei Man Cheung, Business Address: See C.4, Function: Director

• C.9 Business Activity: OKCoin Europe Ltd is the operator of a Trading Platform for Crypto Assets, in accordance with Article 3(1)(18) of Regulation (EU) 2023/1114 (MiCA).

• C.10 Reason for Crypto-Asset White Paper Preparation: This crypto-asset whitepaper has been prepared in accordance with Regulation (EU) 2023/1114 (MiCA) for the purpose of: - The admission to trading of RENDER on regulated platforms, starting with the OKX Exchange. OKCoin Europe LTD as a result of being a licenced CASP endeavours to fulfill the obligations established under MiCA and the respective MFSA guidelines to: - Notify this whitepaper to the MFSA; - Publish the whitepaper publicly; - And ensure its registration in the MiCA register maintained by the European Securities and Markets Authority (ESMA). This whitepaper has been prepared to provide transparent, accurate, and fair information to prospective token holders and regulatory authorities in line with the principles of MiCA.

• C.11 Parent Company: OKC International Holding Company Limited

• C.12 Parent Company Business Activity: The primary business activity of the parent company is holding of investments.

C. Other Information

This section shall ONLY be completed if someone, other those referenced in Section 1 to 3, compile and complete the Crypto-Asset White Paper.

• C.13 Other Persons drawing up the Crypto-Asset White Paper: N/A

• C.14 Reason for Crypto-Asset White Paper Preparation: N/A

INFORMATION ABOUT THE CRYPTO-ASSET

D. Information about the Crypto-Asset Project

• D.1 Project Name: The Render Network

• D.2 Crypto-Assets Name: See F.14

• D.3 Abbreviation: See F.14

• D.4 Crypto-Asset Project Description: The Render Network is a leading decentralized GPU compute platform for applications ranging from 3D rendering to machine learning and generative AI. The network connects node operators looking to monetize their idle GPU compute power with artists and developers looking to scale intensive 3D rendering work and machine learning applications in the cloud. Through a decentralized peer-to-peer network, the Render Network achieves unprecedented levels of scale, speed, and economic efficiency. Facilitated by the Render Network Foundation, the ecosystem empowers artists and developers to build services and applications for the emerging digital economy.

• D.5 Details of all natural or legal persons involved in the implementation of the Crypto-Asset Project:

  • Line ID 1: Jules Urbach, Business Address: Los Angeles, California, USA, Function: CEO

  • Line ID 2: Trevor Harries-Jones, Business Address: San Francisco, California, USA, Function: Director

  • Line ID 3: Tristan Relly, Business Address: North America / Cayman Islands, Function: Head of Ops

  • Line ID 4: Andrew Hyde, Business Address: Boulder, Colorado, United States, Function: Head of Communications

• D.6 Utility Token Classification: TRUE

• D.7 Key Features of Goods/Services for Utility Token Projects, if applicable: The Render Network provides decentralised GPU rendering infrastructure that allows creators to process complex graphics jobs across a distributed network of GPU nodes.

• D.8 Plans for the Token: Founded by OTOY Inc. in 2017, the Render Network launched the RNDR token to power a decentralised GPU rendering platform. Mainnet operations began in 2019, with public access expanding in 2020. Between 2021 and 2023, the project introduced its governance framework, formed the Render Network Foundation, and implemented the Burn-Mint Equilibrium model to align token supply with network demand. The Render roadmap is set by the community through the Render Network Protocol process ("RNP"). Discussions on what to add next take place through Discord and Telegram, and the RNPs current index is available for review here: https://renderfoundation.com/roadmap

• D.9 Resource Allocation, if applicable: As of 2023, approximately 23.3% of the RENDER total supply was loaned to the Render Network Foundation Treasury from OTOY Inc via governance proposal RNP-003.

• D.10 Planned Use of Collected Funds or Crypto-Assets, if applicable: The Render Network Foundation manages a treasury of RENDER tokens, and the planned use of these tokens is defined by governance proposals (e.g., RNP‑003). Crypto-assets within the treasury may be used for: - Core Team Expansion: The Foundation will hire product, engineering, design, and growth team members to facilitate network initiatives and RNP directives. - Grants Programs: The Foundation will earmark some portion of its treasury for bespoke grants and bounties to support ancillary infrastructure and services necessary for network growth. Foundation leadership is responsible for each of the above actions, and must incorporate community input when building and executing against all product and growth roadmaps.

E. Information about the Offer to the Public of the Crypto-Asset or Its Admission to Trading

• E.1 Public Offering or Admission to Trading: ATTR

• E.2 Reasons for Public Offer or Admission to Trade: Facilitating secondary trading for users on the OKX Trading platform in compliance with the MiCA regulatory framework.

• E.3 Fundraising Target, if applicable: N/A

• E.4 Minimum Subscription Goals, if applicable: N/A

• E.5 Maximum Subscription Goals, if applicable: N/A

• E.6 Oversubscription Acceptance: N/A

• E.7 Oversubscription Allocation, if applicable: N/A

• E.8 Issue Price: N/A

• E.9 Official Currency or Any Other Crypto-Assets determining the Issue Price: N/A

• E.10 Subscription Fee: N/A

• E.11 Offer Price Determination Method: N/A

• E.12 Total Number of Offered/Traded Crypto-Assets, if applicable: RENDER token has a total supply of 644,168,762 RENDER.

• E.13 Targeted Holders: ALL

• E.14 Holder Restrictions: N/A

• E.15 Reimbursement Notice: N/A

• E.16 Refund Mechanism: N/A

• E.17 Refund Timeline: N/A

• E.18 Offer Phases: N/A

• E.19 Early Purchase Discount: N/A

• E.20 Time-Limited Offer: N/A

• E.21 Subscription Period, beginning [YYYY-MM-DD]: N/A

• E.22 Subscription Period, end [YYYY-MM-DD]: N/A

• E.23 Safeguarding Arrangement for Offered Funds/Crypto-Assets: N/A

• E.24 Payment Methods for Crypto-Asset Purchase: In line with OKX current payment method offering.

• E.25 Value Transfer Methods for Reimbursement: N/A

• E.26 Right of Withdrawal, if applicable: N/A

• E.27 Transfer of Purchased Crypto-Assets: In line with OKX current Terms of Service.

• E.28 Transfer Time Schedule [YYYY-MM-DD]: N/A

• E.29 Purchaser's Technical Requirements: In line with OKX current Terms of Service.

• E.30 Crypto-Asset Service Provider (CASP) name, if applicable: OKCoin Europe LTD

• E.31 CASP identifier, if applicable: 54930069NLWEIGLHXU42

• E.32 Placement Form: NTAV

• E.33 Trading Platforms Name, if applicable: OKX

• E.34 Trading Platforms Market Identifier Code (MIC): N/A

• E.35 Trading Platforms Access, if applicable: Users may access RENDER through the OKX Trading Platform via the Application Program Interface ("API"), the Application Software ("OKX App"), as well as the official OKX website as follows; www.okx.com.

• E.36 Involved Costs, if applicable: In line with the OKX current Terms of Service.

• E.37 Offer Expenses: N/A

• E.38 Conflicts of Interest: A crypto-asset is listed following a decision rendered independently by the Listing Committee in line with the internal policies of OKCoin Europe. Any potential disclosures that may arise of conflicts of interest are published on the OKX.

• E.39 Applicable Law: Malta

• E.40 Competent Court: Malta

F. Information about the Crypto-Assets

• F.1 Crypto-Asset Type: Other Crypto-Asset.

• F.2 Crypto-Asset Functionality: The RENDER token functions as a medium of exchange and coordination within the Render Network. It is used to pay for GPU rendering tasks, incentivise node operators, and participate in protocol governance through RNPs.

• F.3 Planned Application of Functionalities: All functionalities from the above specified list apply as of the writing of this whitepaper.

• F.4 Type of White Paper: OTHR

• F.5 Type of Submission: NEWT

• F.6 Crypto-Asset Characteristics: The RENDER token is a fungible utility token issued on the Solana blockchain under the SPL standard. It is freely transferable, does not confer ownership or profit rights, and follows a burn-and-mint equilibrium model with variable inflation based on network usage.

• F.7 Commercial Name or Trading Name, if applicable: See F.14

• F.8 Website of the Issuer: https://renderfoundation.com/

• F.9 Starting Date of Offer to the Public or Admission to Trading [YYYY-MM-DD]: 2025-07-02

• F.10 Publication Date [YYYY-MM-DD]: 2025-11-21

• F.11 Any Other Services Provided by the Issuer: N/A

• F.12 Identifier of Operator of the Trading Platform: N/A

• F.13 Language/s of the White Paper: English

• F.14 Digital Token Identifier Code used to uniquely identify the Crypto-Asset or each of the several Crypto-Assets to which the White Paper relates, where available: RQGSSPQ03

• F.15 Functionally Fungible Group Digital Token Identifier, where available: XR0JSKLNZ

• F.16 Voluntary Data Flag: FALSE

• F.17 Personal Data Flag: TRUE

• F.18 LEI Eligibility: N/A

• F.19 Home Member State: Malta

• F.20 Host Member States: Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Italy, Ireland, Latvia, Liechtenstein, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden

G. Information about the Rights and Obligations Attached to the Crypto-Asset

• G.1 Purchaser Rights and Obligations: There are no obligations attached for/of the purchaser. RENDER token holders do have certain rights, wherein holders may use these tokens to access GPU rendering services or participate in protocol governance through the RNPs.

• G.2 Exercise of Rights and Obligations: Since the RENDER token does not grant obligations, there is no conceivable way to exercise such obligations. Purchasers can exercise the rights afforded to them via Render Network dApps or interfaces. For rendering services, tokens are transferred and burned to initiate tasks, while governance participation occurs via Snapshot/Nation based token voting.

• G.3 Conditions for Modifications of Rights and Obligations: As the token does not grant obligations, there are no conditions under which the obligations may be modified. Any rights associated with purchasing of Render tokens can be modified under the community-led Render Network Proposal system. The Render Network Foundation does have the ability to unilaterally modify token rights through token contract ownership, but the foundation's purpose is to only facilitate governance approved changes. While the foundation does have a degree of control over these modifications, there is no evidence to date of the Project team overriding community-backed governance proposals.

• G.4 Future Public Offers, if applicable: N/A

• G.5 Issuer Retained Crypto-Assets, if applicable: According to commercially available data, OTOY Treasury controls 150.13M RENDER tokens (23.3% of the total supply).

• G.6 Utility Token Classification: TRUE

• G.7 Key Features of Goods/Services of Utility Tokens: The Render token grants users access to decentralised GPU rendering services on the Render Network. Users burn RENDER tokens to submit rendering jobs, which are processed by node operators who receive minted Render as compensation. Access is open to all users holding the RENDER token with pricing set in FIAT currency, USD and converted at the time of use.

• G.8 Utility Tokens Redemption, if applicable: RENDER tokens are redeemed by burning them to submit rendering jobs. Users upload rendering tasks through supported interfaces and pay in Render, which is then burned as part of the Network's Burn-and-Mint Equilibrium (BME) model. This redemption process grants access to GPU compute power provided by the decentralized node operators.

• G.9 Non-Trading Request: TRUE

• G.10 Crypto-Assets Purchase or Sale Modalities: N/A

• G.11 Crypto-Assets Transfer Restrictions: In line with OKX current Terms of Service.

• G.12 Supply Adjustment Protocols: FALSE

• G.13 Supply Adjustments Mechanisms: N/A

• G.14 Token Value Protection Schemes: FALSE

• G.15 Token Value Protection Schemes Description: N/A

• G.16 Compensation Schemes: FALSE

• G.17 Compensation Schemes Description, if applicable: N/A

• G.18 Applicable Law: Malta

• G.19 Competent Court: Malta

H. Information about the Underlying Technology

• H.1 Distributed Ledger Technology, if applicable: See F.14

• H.2 Protocols and Technical Standards: The RENDER token is implemented using the SPL token standard on the Solana blockchain. SPL is the authorised standard for fungible and non-fungible tokens on Solana, similar in function to Ethereum's ERC-20 standard. SPL tokens are managed via smart contracts (programs) and utilize Solana's high-throughput, low-latency infrastructure for token transfers and programmatic interactions. Solana's runtime environment uses Rust-based smart contracts and supports token metadata, mint authorities, and secure wallet integration through the Solana Token Program. Legacy versions of the token previously existed on Ethereum and Polygon (ERC‑20), but these have been deprecated following governance approval under RNP‑006. No new RENDER tokens are issued on Ethereum or other blockchains.

• H.3 Technology Used, if relevant: The RENDER token is deployed on the Solana blockchain using the SPL token standard. Solana is a high-performance Layer 1 protocol built in Rust and uses a hybrid Proof-of-History and Proof-of-Stake consensus mechanism. Render's smart contract interactions are handled via the Solana Token Program. Network activity is coordinated through Solana smart contracts, and user wallets interact with the token via Solana-compatible clients.

• H.4 Consensus Mechanism, if applicable: The Solana blockchain uses a hybrid consensus mechanism combining Proof-of-History with Proof-of-Stake. Proof-of-History provides a verifiable, cryptographic time source that sequences transactions before they are validated by a decentralized network of validators using Proof-of-Stake. Validators are selected based on staked SOL tokens and take turns producing blocks, which are finalized rapidly with high throughput and low latency. This mechanism allows Solana to achieve sub-second block times and high scalability while maintaining decentralisation and network security.

• H.5 Incentive Mechanisms and Applicable Fees: On the Solana blockchain, validators are incentivised through a Proof-of-Stake system where they earn rewards in the native token Solana (SOL) for validating transactions and producing blocks. These rewards are distributed proportionally based on the amount of SOL staked. Transaction fees are also paid in SOL, and a portion of these fees is burned, with the rest distributed to validators.

• H.6 Use of Distributed Ledger Technology: FALSE

• H.7 DLT Functionality Description: N/A

• H.8 Audit of the Technology Used: FALSE

• H.9 Audit Outcome, if applicable: N/A

I. Information on the Principal Adverse Impacts on the Climate and Other Environmental-Related Adverse Impacts of the Consensus Mechanism Used to Issue the Crypto-Asset.

• I.1 Name: OKCoin Europe Ltd

• I.2 Relevant legal entity identifier: 54930069NLWEIGLHXU42

• I.3 Name of the crypto-asset: Render Token

• I.4 Consensus Mechanism: Render Token is present on the following networks: Ethereum, Solana. The crypto-asset's Proof-of-Stake (PoS) consensus mechanism, introduced with The Merge in 2022, replaces mining with validator staking. Validators must stake at least 32 ETH every block a validator is randomly chosen to propose the next block. Once proposed the other validators verify the blocks integrity. The network operates on a slot and epoch system, where a new block is proposed every 12 seconds, and finalization occurs after two epochs (~12.8 minutes) using Casper-FFG. The Beacon Chain coordinates validators, while the fork-choice rule (LMD-GHOST) ensures the chain follows the heaviest accumulated validator votes. Validators earn rewards for proposing and verifying blocks, but face slashing for malicious behavior or inactivity. PoS aims to improve energy efficiency, security, and scalability, with future upgrades like Proto-Danksharding enhancing transaction efficiency. Solana uses a unique combination of Proof of History (PoH) and Proof of Stake (PoS) to achieve high throughput, low latency, and robust security. Here's a detailed explanation of how these mechanisms work: Core Concepts 1. Proof of History (PoH): Time-Stamped Transactions: PoH is a cryptographic technique that timestamps transactions, creating a historical record that proves that an event has occurred at a specific moment in time. Verifiable Delay Function: PoH uses a Verifiable Delay Function (VDF) to generate a unique hash that includes the transaction and the time it was processed. This sequence of hashes provides a verifiable order of events, enabling the network to efficiently agree on the sequence of transactions. 2. Proof of Stake (PoS): Validator Selection: Validators are chosen to produce new blocks based on the number of SOL tokens they have staked. The more tokens staked, the higher the chance of being selected to validate transactions and produce new blocks. Delegation: Token holders can delegate their SOL tokens to validators, earning rewards proportional to their stake while enhancing the network's security. Consensus Process 1. Transaction Validation: Transactions are broadcast to the network and collected by validators. Each transaction is validated to ensure it meets the network's criteria, such as having correct signatures and sufficient funds. 2. PoH Sequence Generation: A validator generates a sequence of hashes using PoH, each containing a timestamp and the previous hash. This process creates a historical record of transactions, establishing a cryptographic clock for the network. 3. Block Production: The network uses PoS to select a leader validator based on their stake. The leader is responsible for bundling the validated transactions into a block. The leader validator uses the PoH sequence to order transactions within the block, ensuring that all transactions are processed in the correct order. 4. Consensus and Finalization: Other validators verify the block produced by the leader validator. They check the correctness of the PoH sequence and validate the transactions within the block. Once the block is verified, it is added to the blockchain. Validators sign off on the block, and it is considered finalized. Security and Economic Incentives 1. Incentives for Validators: Block Rewards: Validators earn rewards for producing and validating blocks. These rewards are distributed in SOL tokens and are proportional to the validator's stake and performance. Transaction Fees: Validators also earn transaction fees from the transactions included in the blocks they produce. These fees provide an additional incentive for validators to process transactions efficiently. 2. Security: Staking: Validators must stake SOL tokens to participate in the consensus process. This staking acts as collateral, incentivizing validators to act honestly. If a validator behaves maliciously or fails to perform, they risk losing their staked tokens. Delegated Staking: Token holders can delegate their SOL tokens to validators, enhancing network security and decentralization. Delegators share in the rewards and are incentivized to choose reliable validators. 3. Economic Penalties: Slashing: Validators can be penalized for malicious behavior, such as double-signing or producing invalid blocks. This penalty, known as slashing, results in the loss of a portion of the staked tokens, discouraging dishonest actions.

• I.5 Incentive Mechanisms and Applicable Fees: Render Token is present on the following networks: Ethereum, Solana. The crypto-asset's PoS system secures transactions through validator incentives and economic penalties. Validators stake at least 32 ETH and earn rewards for proposing blocks, attesting to valid ones, and participating in sync committees. Rewards are paid in newly issued ETH and transaction fees. Under EIP-1559, transaction fees consist of a base fee, which is burned to reduce supply, and an optional priority fee (tip) paid to validators. Validators face slashing if they act maliciously and incur penalties for inactivity. This system aims to increase security by aligning incentives while making the crypto-asset's fee structure more predictable and deflationary during high network activity. Solana uses a combination of Proof of History (PoH) and Proof of Stake (PoS) to secure its network and validate transactions. Here's a detailed explanation of the incentive mechanisms and applicable fees: Incentive Mechanisms 4. Validators: Staking Rewards: Validators are chosen based on the number of SOL tokens they have staked. They earn rewards for producing and validating blocks, which are distributed in SOL. The more tokens staked, the higher the chances of being selected to validate transactions and produce new blocks. Transaction Fees: Validators earn a portion of the transaction fees paid by users for the transactions they include in the blocks. This provides an additional financial incentive for validators to process transactions efficiently and maintain the network's integrity. 5. Delegators: Delegated Staking: Token holders who do not wish to run a validator node can delegate their SOL tokens to a validator. In return, delegators share in the rewards earned by the validators. This encourages widespread participation in securing the network and ensures decentralization. 6. Economic Security: Slashing: Validators can be penalized for malicious behavior, such as producing invalid blocks or being frequently offline. This penalty, known as slashing, involves the loss of a portion of their staked tokens. Slashing deters dishonest actions and ensures that validators act in the best interest of the network. Opportunity Cost: By staking SOL tokens, validators and delegators lock up their tokens, which could otherwise be used or sold. This opportunity cost incentivizes participants to act honestly to earn rewards and avoid penalties. Fees Applicable on the Solana Blockchain 7. Transaction Fees: Low and Predictable Fees: Solana is designed to handle a high throughput of transactions, which helps keep fees low and predictable. The average transaction fee on Solana is significantly lower compared to other blockchains like Ethereum. Fee Structure: Fees are paid in SOL and are used to compensate validators for the resources they expend to process transactions. This includes computational power and network bandwidth. 8. Rent Fees: State Storage: Solana charges rent fees for storing data on the blockchain. These fees are designed to discourage inefficient use of state storage and encourage developers to clean up unused state. Rent fees help maintain the efficiency and performance of the network. 9. Smart Contract Fees: Execution Costs: Similar to transaction fees, fees for deploying and interacting with smart contracts on Solana are based on the computational resources required. This ensures that users are charged proportionally for the resources they consume.

• I.6 Beginning of the period to which the disclosure relates: 2024-09-03

• I.7 End of the period to which the disclosure relates: 2025-09-03

• I.8 Energy consumption: 708.03157 (kWh/a)

• I.9 Energy consumption sources and methodologies: To determine the GHG Emissions, the locations of the nodes are to be determined using public information sites, open-source crawlers and crawlers developed in-house. If no information is available on the geographic distribution of the nodes, reference networks are used which are comparable in terms of their incentivization structure and consensus mechanism. This geo-information is merged with public information from Our World in Data, see citation. The intensity is calculated as the marginal emission wrt. one more transaction. Ember (2025); Energy Institute - Statistical Review of World Energy (2024) - with major processing by Our World in Data. "Carbon intensity of electricity generation - Ember and Energy Institute" [dataset]. Ember, "Yearly Electricity Data Europe"; Ember, "Yearly Electricity Data"; Energy Institute, "Statistical Review of World Energy" [original data]. Retrieved from https://ourworldindata.org/grapher/carbon-intensity-electricity Licenced under CC BY 4.0.

GLOSSARY

• Consensus Mechanism: Shall mean the rules and procedures by which an agreement is reached, among the DLT network nodes, that a transaction is validated.

• Crypto-Asset: Shall mean 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.

• Distributed Ledger Technology or DLT: shall mean the technology that enables the operation and use of distributed ledgers.

• Home Member State: Shall mean either (a) where the offeror or person seeking admission to trading of crypto-assets other than asset-referenced tokens or e-money tokens has its registered office in the Union, the Member State where that offeror or person has its registered office; or (b) where the offeror or person seeking admission to trading of crypto-assets other than asset-referenced tokens or e-money tokens has no registered office in the Union but does have one or more branches in the Union, the Member State chosen by that offeror or person from among the Member States where it has branches; or (c) where the offeror or person seeking admission to trading of crypto-assets other than asset-referenced tokens or e-money tokens is established in a third country and has no branch in the Union, either the Member State where the crypto-assets are intended to be offered to the public for the first time or, at the choice of the offeror or person seeking admission to trading, the Member State where the first application for admission to trading of those crypto-assets is made; or (d) in the case of an Issuer of asset-referenced tokens, the Member State where the Issuer of asset-referenced tokens has its registered office; or (e) in the case of an Issuer of e-money tokens, the Member State where the Issuer of e-money tokens is authorised as a credit institution under Directive 2013/36/EU or as an electronic money institution under Directive 2009/110/EC; or (f) in the case of crypto-asset service providers, the Member State where the crypto-asset service provider has its registered office.

• Host Member State: Shall mean the Member State where an Offeror or Person Seeking Admission to Trading has made an offer to the Public of Crypto-Assets or is seeking admission to trading, or where a Crypto-Asset Service Provider provides crypto-asset services, where different from the Home Member State.

• Issuer: Shall mean a natural or legal person, or other undertaking, who issues crypto-assets.

• Management Body: Shall mean the body or bodies of an Issuer, Offeror, Person Seeking Admission to Trading, or of a Crypto-Asset Service Provider, which are appointed in accordance with National Law, which are empowered to set the entity's strategy, objectives and overall direction, and which oversee and monitor management decision-making in the entity and include the persons who effectively direct the business of the entity.

• Offer to the Public: Shall mean 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.

• Offeror: Shall mean a natural or legal person, or other undertaking, or the Issuer, who offers crypto-assets to the public.

• Operator: Shall mean the entity that runs a trading platform for crypto-assets.

• Qualified Investors: Shall mean persons or entities that are listed in Section I, points (1) to (4), of Annex II to Directive 2014/65/EU.

• Retail Investor/Holder: Shall means any natural person who is acting for purposes which are outside that person's trade, business, craft or profession.

• Utility Token: Shall mean a type of crypto-asset that is only intended to provide access to a good or a service supplied by its Issuer.