MiCA Whitepaper
Date of notification: 21-05-2026
iXBRL HTML report
PDF whitepaper
Table of Contents
| General Information | |
|---|---|
| 00: Table of content | true |
| 01: Date of notification | 21-05-2026 |
| 02: Statement in accordance with Article 6(3) of Regulation (EU) 2023/1114 | 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. |
| 03: Compliance statement in accordance with Article 6(6) of Regulation (EU) 2023/1114 | This crypto-asset white paper complies with Title II of Regulation (EU) 2023/1114 of the European Parliament and of the Council and, 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. |
| 04: Statement in accordance with Article 6(5), points (a), (b), (c), of Regulation (EU) 2023/1114 | The crypto-asset referred to in this crypto-asset white paper may lose its value in part or in full, may not always be transferable and may not be liquid. |
| 05: Statement in accordance with Article 6(5), point (d), of Regulation (EU) 2023/1114 | Not applicable |
| 06: Statement in accordance with Article 6(5), points (e) and (f), of Regulation (EU) 2023/1114 | The crypto-asset referred to in this white paper is not covered by the investor compensation schemes under Directive 97/9/EC of the European Parliament and of the Council or the deposit guarantee schemes under Directive 2014/49/EU of the European Parliament and of the Council. |
| SUMMARY | |
| 07: Warning in accordance with Article 6(7), second subparagraph, of Regulation (EU) 2023/1114 | Warning This summary should be read as an introduction to the 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. |
| 08: Characteristics of the crypto-asset | RE is the native governance and coordination token of the Re Protocol, deployed on Ethereum mainnet within a broader multi-EVM architecture spanning Avalanche and Arbitrum. RE does not represent debt, equity, ownership, voting rights, profit-sharing, or any claim on protocol revenue or insurance cash flows. Core utilities include: (i) governance participation covering protocol upgrades, risk parameters, and committee structures; (ii) bonding and staking by sensitive protocol roles such as auditors, reviewers, and proposers, with tokens subject to lockup and potential slashing as accountability mechanisms; and (iii) challenge and oversight deposits within the protocol. RE carries no built-in revenue-sharing or passive yield rights. |
| 09: Further information about utility tokens | Not applicable |
| 10: Key information about the offer to the public or admission to trading | This white paper has been prepared for the purposes of seeking admission to trading on multiple crypto-asset trading platforms. The Issuer seeks to ensure broad accessibility for the RE token by pursuing admission to trading across suitable venues. |
| Part A - Information about the Offeror or the Person Seeking Admission to Trading | |
| A.1: Name | Resilience Core Ltd. |
| A.2: Legal form | British Virgin Islands business company |
| A.3: Registered address | Suite 5 Oleander Building, Port Purcell, Tortola, VG1110, British Virgin Islands |
| A.4: Head office | Suite 5 Oleander Building, Port Purcell, Tortola, VG1110, British Virgin Islands |
| A.5: Registration date | 2026-04-29 |
| A.6: Legal entity identifier | 2549004WYGE5MQ16JH36 |
| A.7: Another identifier required pursuant to applicable national law | 2207588 |
| A.8: Contact telephone number | 1 345-749-9601 |
| A.9: E-mail address | hello@re.xyz |
| A.10: Response time (days) | 002 |
| A.11: Parent company | Resilience Foundation |
| A.12: Members of management body | Resilience Foundation as the Director of Resilience Core Ltd. |
| A.13: Business activity | Resilience Core Ltd is the token issuer entity and is wholly owned by Resilience Foundation. |
| A.14: Parent company business activity | Resilience Foundation is the protocol owner and operator. |
| A.15: Newly established | true |
| A.16: Financial condition for the past three years | Not applicable as the offeror or person seeking admission to trading was established in 2024. |
| A.17: Financial condition since registration | Resilience Foundation, the parent entity of the issuer of the RE token, was established in 2024 to serve as the dedicated protocol-coordination entity for an unaffiliated reinsurance business. The reinsurance business that the RE ecosystem supports has an operating history dating back to 2022. This business's financing track record includes: a 2022 seed round and 2024 venture round and a 2025 strategic round. |
| Part B - Information about the Issuer, If Different from the Offeror or Person Seeking Admission to Trading | |
| B.1: Issuer different from offerror or person seeking admission to trading | false |
| B.2: Name | |
| B.3: Legal form | |
| B.4: Registered address | |
| B.5: Head office | |
| B.6: Registration date | |
| B.7: Legal entity identifier | |
| B.8: Another identifier required pursuant to applicable national law | |
| B.9: Parent company | |
| B.10: Members of management body | |
| B.11: Business activity | |
| B.12: Parent company business activity | |
| Part C - Information about the Operator of the Trading Platform | |
| C.1: Name | |
| C.2: Legal form | |
| C.3: Registered address | |
| C.4: Head office | |
| C.5: Registration date | |
| C.6: Legal entity identifier | |
| C.7: Another identifier required pursuant to applicable national law | |
| C.8: Parent company | |
| C.9: Reason for crypto-asset white paper preparation | |
| C.10: Members of management body | |
| C.11: Operator business activity | |
| C.12: Parent company business activity | |
| C.13: Other persons drawing up the crypto-asset white paper according to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114 | |
| C.14: Reason for drawing the white paper by persons referred to in Article 6(1), second subparagraph, of Regulation (EU) 2023/1114 | |
| Part D - Information about the Crypto-Asset Project | |
| D.1: Crypto-asset project name | RE |
| D.2: Crypto-asset name | RE Protocol |
| D.3: Abbreviation | RE |
| D.4: Crypto-asset project description | Purpose and Goals: Re is an on-chain reinsurance and real‑world protocol that connects stablecoin capital to fully collateralized quota‑share reinsurance programs via licensed and regulated insurance structures. Re is building market infrastructure for an internet-native insurance capital market; Its goal is to become a decentralized, multi‑carrier reinsurance marketplace where anyone can deploy capital into institutional‑grade catastrophic and specialty risk, governed by the RE token. Key Features and Operation: Any lock-up or staking mechanism does not result in any profit or yield in the form of fiat currency or additional tokens and serves as a governance mechanism only. This is a separate feature and not an intrinsic aspect of holding the RE token. |
| D.5: Details of all natural or legal persons involved in implementation of crypto-asset project | 1 Advisor Matthew Taber 2 Development team Anand Dhillon 3 Development team Karn Saroya 4 Development team Cliff White 5 Development team Jonathan Lim 6 Development team James Norris 7 Development team Resilience Inv SPC 8 Development team Cover Re, Inc. |
| D.6: Utility token classification | false |
| D.7: Key features of goods or services for utility token projects | Not applicable as RE is not a utility token as defined under MiCA. |
| D.8: Plans for the token | Achievements Re has launched a fully on-chain reinsurance protocol that connects stablecoin capital to fully collateralized quota-share reinsurance programs via licensed, regulated structures, giving users tokenized positions such as reUSD and reUSDe backed by real-world reinsurance capacity. The RE token has been designed as a fixed-supply (1,000,000,000 RE), non-inflationary governance and integrity token - explicitly not equity, debt, or a claim on protocol revenues - intended to coordinate upgrades, risk parameters, participant standards, and sensitive roles such as auditors and program proposers through staking/bonding and challenge deposits. Forward Roadmap & RE Token Milestones At launch, RE will function as the protocol's governance and coordination token. Holders may use RE to vote on protocol parameters and proposals submitted through the portal. At launch the scope of governance will include: Governance functionality at launch is the start of the process of progressive protocol decentalization, where RE will become the primary means of governance voting and bonded staking for sensitive roles, with lockups and potential slashing accountability tools. Decentralization of governance will be supported by a growing number of reinsurers participating on the platform. |
| D.9: Resource allocation | Total Value Locked Total: $480M Onchain Capital: $87M OffChain Capital: $177M Premium Receivable: $215M Community Direct Depositors: 1227 Token holders: 1912 Technological resources: Other significant investments and operational build-out: |
| D.10: Planned use of collected funds or other tokens | Planned use of funds and crypto-assets focuses on estbalishing a treasury to support the adoption of the Resilience protocol and governance capability of the RE token. |
| Part E - Information about the Offer to the Public of Crypto-Assets or their Admission to Trading | |
| E.1: Public offering or admission to trading | ATTR |
| E.2: Reasons for public offer or admission to trading | Enable EU market access for RE holders. |
| E.3: Fundraising target | Not applicable. This whitepaper is published solely in relation to the admission to trading of the RE token and does not relate to any public offering. |
| E.4: Minimum subscription goals | Not applicable. This whitepaper is published solely in relation to the admission to trading of the RE token and does not relate to any public offering. |
| E.5: Maximum subscription goals | Not applicable. This whitepaper is published solely in relation to the admission to trading of the RE token and does not relate to any public offering. |
| E.6: Oversubscription acceptance | Not applicable. This whitepaper is published solely in relation to the admission to trading of the RE token and does not relate to any public offering. |
| E.7: Oversubscription allocation | Not applicable. This whitepaper is published solely in relation to the admission to trading of the RE token and does not relate to any public offering. |
| E.8: Issue price | Not applicable. This whitepaper is published solely in relation to the admission to trading of the RE token and does not relate to any public offering. |
| E.9: Official currency determining issue price | Not applicable. This whitepaper is published solely in relation to the admission to trading of the RE token and does not relate to any public offering. |
| E.10: Subscription fee | Not applicable. This whitepaper is published solely in relation to the admission to trading of the RE token and does not relate to any public offering. |
| E.11: Offer price determination method | Not applicable. This whitepaper is published solely in relation to the admission to trading of the RE token and does not relate to any public offering. |
| E.12: Total number of offered or traded other tokens | 1,000,000,000 |
| E.13: Targeted holders | All |
| E.14: Holder restrictions | There are no restrictions. |
| E.15: Reimbursement notice | There are no reimbursement rights. |
| E.16: Refund mechanism | There is no refund mechanism. |
| E.17: Refund timeline | There is no refund mechanism. |
| E.18: Offer phases | Not applicable. This whitepaper is published solely in relation to the admission to trading of the RE token and does not relate to any public offering. |
| E.19: Early purchase discount | Not applicable. This whitepaper is published solely in relation to the admission to trading of the RE token and does not relate to any public offering. |
| E.20: Time-limited offer | Not applicable. This whitepaper is published solely in relation to the admission to trading of the RE token and does not relate to any public offering. |
| E.21: Subscription period beginning | Not applicable. This whitepaper is published solely in relation to the admission to trading of the RE token and does not relate to any public offering. |
| E.22: Subscription period end | Not applicable. This whitepaper is published solely in relation to the admission to trading of the RE token and does not relate to any public offering. |
| E.23: Safeguarding arrangements for offered funds or other tokens | Not applicable. This whitepaper is published solely in relation to the admission to trading of the RE token and does not relate to any public offering. |
| E.24: Payment methods for other token purchase | Fiat or other crypto-assets. |
| E.25: Value transfer methods for reimbursement | There are no reimbursement rights. |
| E.26: Right of withdrawal | Not applicable. This whitepaper is published solely in relation to the admission to trading of the RE token and does not relate to any public offering. |
| E.27: Transfer of purchased other tokens | Via crypto-asset trading platforms on which RE is admitted to trading. |
| E.28: Transfer time schedule | There is no relevant time schedule. |
| E.29: Purchaser's technical requirements | There are no technical requirements. |
| E.30: Other token service provider (CASP) name | |
| E.31: CASP identifier | |
| E.32: Placement form | NTAV |
| E.33: Trading platforms name | Resilience Core Ltd. is seeking admission to trading for the RE token across multiple trading platforms, including: |
| E.34: Trading platforms market identifier code (MIC) | PGSL VAVO |
| E.35: Trading platforms access | Online via the platform. |
| E.36: Involved costs | |
| E.37: Offer expenses | Not applicable. This whitepaper is published solely in relation to the admission to trading of the RE token and does not relate to any public offering. |
| E.38: Conflicts of interest | The issuer is not aware of any potential conflict of interest of the persons involved in its admission to trading. |
| E.39: Applicable law | Not applicable. This whitepaper is published solely in relation to the admission to trading of the RE token and does not relate to any public offering. |
| E.40: Competent court | British Virgin Islands (BVI) |
| Part F - Information about the Crypto-Assets | |
| F.1: Other token type | The RE token is a crypto-asset under Regulation (EU) 2023/1114 of the European Parliament and of the Council which is not an e-money token, an asset-referenced token or a utility token, each as defined under such Regulation. Therefore, it falls in the "Other" category. |
| F.2: Other token functionality | Rights (and explicit non-rights) |
| F.3: Planned application of functionalities | 2026-06 (target, exact date TBD): Token generation event (TGE) and initial listing of RE on Ethereum mainnet, with initial circulating supply of 159,600,000 RE (15.96% of total supply) becoming transferable; vesting schedules for team, investors, and remaining ecosystem/community allocations begin from TGE. Governance portal will be live. 2026-06 (from TGE onward): 28% of the 57% ecosystem and community allocation is unlocked and transferable at TGE; the remaining ecosystem/community allocation vests linearly over 48 months from TGE. 2027-05 (12 months after TGE, assuming TGE in May 2026): End of 12‑month cliffs for team and investor allocations; linear vesting over the following 36 months for these buckets begins, progressively adding transferable RE to circulating supply. |
| F.4: Type of crypto-asset white paper | OTHR |
| F.5: Type of submission | NEWT |
| F.6: Other token characteristics | RE is a pre‑launch, Ethereum‑mainnet governance and coordination token for the Re ecosystem, positioned as a functional “integrity” token rather than equity, debt, a redeemable asset‑backed token, or a claim on protocol revenue or insurance cash flows. Its primary technical base is Ethereum mainnet within a broader multi‑EVM architecture where the underlying protocol also spans networks such as Avalanche and Arbitrum. Compliance is framed around gated access to regulated pathways with KYC/KYB, AML/CTF, sanctions screening, jurisdiction‑based eligibility controls, and explicit restrictions on users from the United States and certain sanctioned or high‑risk jurisdictions, supported by providers such as SumSub and Chainalysis. Operationally, RE is intended to govern protocol upgrades, risk parameters, participant admission standards, committee structures, and certain emergency or oversight decisions, and to be bonded or staked by sensitive roles (e.g., auditors, reviewers, proposers) and used for challenge/oversight deposits, with lockups and potential slashing as accountability mechanisms, but without any built‑in revenue‑sharing or passive yield rights. |
| F.7: Commercial name or trading name | Resilience |
| F.8: Website of the issuer | https://re.xyz |
| F.9: Starting date of offer to the public or admission to trading | 19-06-2026 |
| F.10: Publication date | 19-06-2026 |
| F.11: Any other services provided by the issuer | Nothing other than already stated in the white paper. |
| F.12: Language or languages of white paper | English |
| F.13: 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 | WJPPZB1R0 |
| F.14: Functionally fungible group digital token identifier, where available | 9DDKPFN21 |
| F.15: Voluntary data flag | false |
| F.16: Personal data flag | true |
| F.17: LEI eligibility | true |
| F.18: Home member state | Ireland |
| F.19: Host member states | Austria, Belgium, Bulgaria, Croatia, Republic of Cyprus, Czechia, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Italy, Latvia, Liechtenstein, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden. |
| Part G - Information on the Rights and Obligations attached to the Crypto-Assets | |
| G.1: Purchaser rights and obligations | Ownership and Economic Rights RE does not represent equity, debt, or a claim on protocol revenue or insurance cash flows. It is not a redeemable asset-backed token. Holders do not possess ownership, profit-sharing rights, or legal interests in the protocol or its underlying insurance programs. Core Utility and Access RE serves as a coordination and security tool. Its primary functions include: Evolution of Governance The protocol follows a path of progressive decentralization. Governance begins with expert-led council oversight and is intended to evolve toward a DAO-style model where token holders and bonded participants influence service provider selection, admission standards, and emergency actions. Compliance and Obligations While holding RE does not impose capital calls or liabilities, active participation is subject to strict requirements: |
| G.2: Exercise of rights and obligations | RE is a pre-launch token. These procedures are high-level summaries of intended utilities and are subject to change upon the launch of the mainnet and official front-ends. Verification: Create an account via the official gateway and complete the Identity (KYC) or Business (KYB) process through designated providers (e.g., SumSub). Wallet Linking: Connect your on-chain wallet for AML/CTF screening (e.g., Chainalysis). Once approved, your wallet is white-listed for protocol services. Transaction: Follow the interface to interact with tokenized risk products or underwriting programs. All actions are subject to admission standards and risk parameters governed by the protocol. Security Deposits: Bond a required amount of RE through the staking interface. This serves as an accountability mechanism, not a yield-generating activity. Performance: Participants must meet governance-defined standards; failure to do so may result in "slashing" (forfeiture) of the bonded RE. Review Process: Posting a deposit triggers a formal review. Depending on the governance outcome, the deposit is either returned or penalized to ensure the integrity of the challenge system. Voting Process: Access the governance portal with a cleared wallet. Review active proposals and cast votes. The model is intended to evolve from expert-led oversight to a decentralized DAO-style structure. Finality: Exact interfaces, URLs, and contract parameters will be finalized at launch. Always refer to official "Resilience" communications for the most current implementation details. |
| G.3: Conditions for modifications of rights and obligations | Rights and obligations in the Resilience (RE) ecosystem may change only through the protocol’s governance process, under which RE holders (initially via an expert-led council and over time via broader DAO-style governance) can approve upgrades to UUPS-upgradeable smart contracts, adjust risk parameters, modify participant admission standards, redesign committee and service-provider structures, and invoke or refine emergency and oversight functions; any such changes are implemented on-chain subject to controls such as a 48‑hour timelock on upgrades, MPC-controlled operational roles, and defined emergency pause and recovery mechanisms. |
| G.4: Future public offers | There are no future offers planned. |
| G.5: Issuer retained other token | 200,000,000 |
| G.6: Utility token classification | false |
| G.7: Key features of goods or services utility tokens | |
| G.8: Utility tokens redemption | |
| G.9: Non-trading request | true |
| G.10: Other tokens purchase or sale modalities | Not applicable. This white paper is published in relation to the admission to trading of the RE token and does not relate to any public offering. |
| G.11: Other tokens transfer restrictions | Concrete transfer-related restrictions and limitations identified: Jurisdiction-based geo-restrictions: Access to the token is restricted in Iran, North Korea, Syria, Sudan, Cuba, Russia, Belarus, Crimea, Donetsk, and Luhansk regions of Ukraine) and any other jurisdiction where use would be prohibited by law. Compliance controls include KYC/KYB, AML/CTF, and sanctions screening as gatekeepers for eligibility. Lock-ups / vesting (affecting transferability of specific allocations): Staking/bonding-related locking: The design includes Token locking in connection with staking/bonding for certain protocol roles, which can restrict transfer of tokens while they are locked for these roles. Only those RE Tokenholders who have been verified through KYC/KYB can participate in staking and bonding Whitelist/blacklist and transfer fees: No explicit whitelist, blacklist, or transfer-fee mechanism is described in the provided material. |
| G.12: Supply adjustment protocols | false |
| G.13: Supply adjustment mechanisms | There are no supply adjustment protocols. |
| G.14: Token value protection schemes | false |
| G.15: Token value protection schemes description | There is no protection scheme available. |
| G.16: Compensation schemes | false |
| G.17: Compensation schemes description | There are no compensation schemes. |
| G.18: Applicable law | British Virgin Islands (BVI) |
| G.19: Competent court | British Virgin Islands (BVI) |
| Part H - Information on the underlying technology | |
| H.1: Distributed ledger technology (DTL) | Resilience uses Ethereum-style smart contracts to tokenize capital and distribute it across multiple compatible blockchains, so users hold onchain positions (like reUSD) that map to real-world reinsurance exposure. Security relies on audited, upgradeable contracts with a 48‑hour timelock on changes, multi‑party controlled operational keys, emergency pause features, and institutional custody for underlying assets. The system inherits blockchain immutability for onchain records, while upgrades are controlled through governed processes rather than unilateral changes. Transparency comes from publishing collateral balances, reserve and pricing data through Chainlink-based infrastructure and onchain reporting, so users can independently verify how capital moves between deposits, reinsurance treaties, and redemptions. |
| H.2: Protocols and technical standards | Primary deployment of the RE governance token on Ethereum mainnet. Existing Re protocol deployments across multiple EVM environments: Ethereum, Avalanche, and Arbitrum. Planned cross-chain expansion using Stargate on Solana and Plasma. Planned public developer SDK and REST API for integrations. |
| H.3: Technology used | The protocol uses a modular, role-separated architecture with MPC-controlled operational roles, a 48‑hour timelock on upgrades, emergency pause functionality, and recovery‑wallet protections to secure privileged key usage and contract control. Idle assets backing onchain positions are swept into Fireblocks-controlled custody, so reserve capital is held offchain with an institutional custody provider rather than in application-controlled hot wallets. Users interact with Insurance Capital Layer smart contracts by depositing admitted collateral and receiving tokenized positions such as reUSD or reUSDe, with transfers and redemptions occurring on EVM networks where the protocol is deployed. Reserve and pricing data for these positions are published onchain via Chainlink-based infrastructure, which separates price/oracle keys from operational and governance keys. Users interact with the protocol via standard EVM-compatible wallets across the networks where the protocol is deployed; no specific wallet type (e.g., hardware vs. software) is required beyond EVM compatibility. |
| H.4: Consensus mechanism | Resilience’s RE governance token is planned to live primarily on Ethereum mainnet, while the broader Re protocol already runs across multiple EVM networks including Ethereum, Avalanche, and Arbitrum. Consensus model (succinct): Ethereum Proof‑of‑Stake (PoS) L1, plus deployments of the Re protocol on Avalanche PoS and Arbitrum (an L2 optimistic rollup settling to Ethereum PoS). Why this is secure: Why this is efficient: |
| H.5: Incentive mechanisms and applicable fees | Incentive mechanisms and who earns what RE is a fixed‑supply token (1 billion hard cap, no ongoing inflation or emissions schedule). It is designed as a governance, coordination, and security protocol token, not as equity, debt, a claim on protocol revenue/insurance cash flows, or an automatically yield‑bearing asset. Planned incentives are tied to active roles, not passive holding: RE is intended to be staked or bonded by “sensitive” participants such as auditors, reviewers, and program proposers, with lockups and potential slashing used as accountability tools. Challenge and oversight deposits in RE can also be posted to trigger reviews or disputes under governance‑defined rules, so participants are effectively rewarded by being able to take on these roles and participate in governance rather than through automatic emission rewards. There is no described proof‑of‑stake validator set or mining system for base‑layer network security, and no perpetual staking reward schedule or mining incentives for simply holding or locking RE. Token locking otherwise comes from vesting for team and investors and from any staking/bonding requirements tied to protocol roles. Fees and how they are handled The underlying business model generates economics from real‑world reinsurance activity: insurance premiums, structured product fees, and issuance/redemption/management fees attached to onchain capital products like reUSD and reUSDe and the surrounding infrastructure. However, RE holders do not have a claim on these revenues, and there are explicitly no burn programs, buyback programs, or automatic revenue distributions to RE holders. |
| H.6: Use of distributed ledger technology | false |
| H.7: DLT functionality description | |
| H.8: Audit | true |
| H.9: Audit outcome | Resilience (Re) is built on a modular, role-separated smart contract architecture designed for strong auditability and controlled change management. It uses UUPS‑upgradeable contracts on Ethereum mainnet with MPC‑controlled operational roles, a 48‑hour timelock on upgrades, daily pricing and reserve attestations, emergency pause functionality, and recovery‑wallet protections, all aimed at minimizing single points of failure and operational abuse. Key technical risks identified include smart contract vulnerabilities, oracle configuration errors, custody or integration failures, privileged‑access misuse, and failures in upgrade or emergency processes. These are mitigated through third‑party audits, Certora formal verification/review (latest report dated 26 September 2025), prior protocol audits available via the Hacken portal, MPC‑based role separation, upgrade timelocks, reserve attestations, and emergency pause and recovery mechanisms. Re maintains a formal risk register with clearly defined mitigations, supported by recurring external reviews, to maintain security and governance robustness over time. |
| Part I - Information on Risks | |
| I.1: Offer-related risks | Market and liquidity risk: Investors face risk that secondary-market liquidity for RE may be limited, with potentially high volatility around launch and thereafter. Redemption‑timing mismatches, underwriting performance variance, and changes in the composition or liquidity of underlying stablecoin collateral can adversely affect perceived value and tradability of RE. Legal and regulatory risk: The model depends on alignment with MiCA and other applicable regimes, as well as compliant token distribution, AML/CTF and sanctions controls, and the interface between on‑chain capital and licensed insurance structures, all of which may be subject to legal uncertainty or change. Jurisdictional restrictions (for example, prohibitions on access from the U.S. and various sanctioned or high‑risk countries) may tighten over time, limit user participation, or force changes in the offering structure. AML / KYC and access risk: Participation is contingent on KYC/KYB onboarding, AML/CTF and sanctions screening, and jurisdiction‑based eligibility controls, which may result in denial of access, off‑boarding, or frozen participation if risk flags or regulatory changes arise. Reliance on third‑party compliance tooling (such as SumSub and Chainalysis) introduces dependency risk and potential false positives/negatives in risk assessments that can impact holders’ ability to participate. Technical and operational risk: RE and the underlying protocol depend on smart contracts, oracle configurations, custody infrastructure, and integration with external systems, all of which are exposed to vulnerabilities, configuration errors, and operational failures. Privileged‑access misuse, failures in upgrade or emergency processes, and flaws in MPC role separation, timelocks, pause mechanisms, or recovery‑wallet design could result in loss of funds, governance capture, or prolonged downtime. Tokenomics and vesting risk: RE has a fixed hard cap of 1,000,000,000 tokens with no ongoing inflation, and an initially planned circulating supply of 159,600,000 RE (15.96% of total) expected to come primarily from ecosystem and community allocations, which concentrates future unlock risk in non‑circulating allocations. Team (20%) and investor (23%) allocations are subject to a 12‑month cliff and 36‑month linear vesting, so future unlocks could create significant additional supply and selling pressure even though no team or investor tokens are expected to unlock at TGE. RE does not represent equity, debt, revenue share, or a claim on insurance cash flows, so holders bear the risk that market demand for purely governance‑ and utility‑driven features may not support the token’s value. Governance and centralization risk: At launch, governance is expected to rely on expert‑led council structures, with a later transition path toward more decentralized, DAO‑style governance, exposing holders to initial centralization of decision‑making and execution power. RE is intended to control protocol upgrades, risk parameters, participant admission standards, committee design, service‑provider selection, and certain emergency or oversight functions, so concentration of RE holdings or governance participation could allow a small group to influence critical parameters. The planned use of staking/bonding and challenge deposits for sensitive roles introduces additional slashing and dispute‑outcome risk for participants who engage in governance processes. |
| I.2: Issuer-related risks | |
| I.3: Other tokens-related risks | Market and liquidity risks: The project highlights market and product risks including underwriting performance variance, claims severity, redemption‑timing mismatches, changes in stablecoin collateral composition, and volatility when RE launches into live markets. As a pre‑launch token, there is no observable market data or secondary liquidity yet. Legal and regulatory risks: Identified risks include token‑distribution compliance, ongoing MiCA alignment, AML/CTF and sanctions obligations, jurisdictional restrictions, and the complexity of connecting onchain capital to licensed insurance structures. AML and privacy risks: The model relies on gated onboarding with KYC/KYB, AML/CTF checks, sanctions screening, and jurisdiction‑based eligibility controls, implemented via providers such as SumSub and Chainalysis. This reduces pseudonymous access but concentrates reliance on third‑party compliance systems and associated data‑handling/privacy practices. Technical and security risks: Key technical risks include smart contract vulnerabilities, oracle configuration errors, custody or integration failures, misuse of privileged access, and failures in upgrade or emergency processes. Mitigants described are third‑party audits (including Certora review), MPC role separation, a 48‑hour timelock, reserve attestations, emergency pause functionality, and recovery‑wallet design, but these do not eliminate residual risk. Governance risks: RE is positioned as a governance, coordination, and security protocol token that will control protocol upgrades, risk parameters, participant admission, committee structures, and emergency/oversight functions, with plans to use staking/bonding and potential slashing for sensitive roles. Governance begins under expert‑led council oversight with a later transition toward DAO‑style governance, creating risks around concentration of decision‑making, capture of governance processes, and execution of high‑impact decisions on protocol risk and access. Listings and distribution risks: There is a listing and distribution risk around whether exchanges ultimately approve RE, how they interpret MiCA and local rules, and any changes in regulatory or exchange‑policy requirements before or after launch. |
| I.4: Project implementation-related risks | Technical risks: Smart contract vulnerabilities, oracle misconfiguration, upgrade or emergency-process failures, and misuse of privileged or MPC-controlled roles could lead to loss of funds, incorrect pricing, disrupted governance, or prolonged pauses of the protocol. Operational / resource risks: Delays in completing audits, deploying and maintaining UUPS-upgradeable contracts across multiple EVM networks, or managing MPC operations and recovery wallets may slow launch, impair incident response, or create coordination challenges between technical, risk, and compliance teams. Third-party dependency risks: Dependence on external auditors, oracle providers, MPC infrastructure, and reserve attestations introduces risks of service outages, delays, or quality failures that could undermine the integrity of pricing, collateral management, and upgrade safety. Market / liquidity risks: Underwriting performance variance, claims severity, redemption-timing mismatches, and stablecoin collateral composition changes, combined with potential volatility and thin liquidity for a newly launched RE token, could impair secondary-market trading and affect participant incentives and confidence. Legal / compliance risks: Failure to maintain MiCA alignment, implement robust onboarding (KYC/KYB, sanctions screening, jurisdiction restrictions), or correctly structure the interface between onchain capital and licensed insurance entities could result in regulatory action, distribution restrictions, or forced changes to token design. Governance / tokenomics risks: As RE is intended to control protocol upgrades, risk parameters, admission standards, and committee structures, concentration of token holdings, low voter participation, or misaligned staking/bonding and slashing rules could lead to capture of governance, poor risk decisions, or instability in oversight and dispute mechanisms. |
| I.5: Technology-related risks | Smart contracts: Re uses UUPS‑upgradeable smart contracts with MPC‑controlled operational roles, a 48‑hour timelock on upgrades, emergency pause, and recovery‑wallet protections, which concentrates upgrade and pause powers and creates governance/operational key‑risk even with these controls in place. Cross‑chain: The protocol already spans multiple EVM networks and plans further cross‑chain expansion via Stargate on Solana and Plasma, increasing exposure to bridge risks, cross‑chain messaging failures, and inconsistent behavior or liquidity fragmentation across chains. Scalability and infrastructure dependencies: A modular architecture plus multi‑chain deployment and DeFi integrations should support scale but also adds dependence on external infrastructure such as oracles (Chainlink), custodians (Fireblocks), and DeFi venues; congestion, oracle disruption, or custodian downtime could impair minting, redemptions, or on‑chain reporting. Wallet, custody, and privacy: User collateral is swept into Fireblocks‑controlled custody and key roles rely on MPC wallets, centralizing operational and custodial risk in a small number of service providers; extensive on‑chain reporting combined with KYC/monitoring partners such as SumSub and Chainalysis also reduces pseudonymity and may create data‑handling/privacy considerations for users. L2 / underlying chain dependencies: With core governance and issuance centered on Ethereum mainnet but user access distributed across multiple EVM networks (and future Solana/Plasma deployment), the system inherits settlement, outage, and reorg risks from each underlying chain and from any L2 or sidechain operators (for example sequencers), which could temporarily block or delay protocol actions even if contracts function as designed. Audits and ongoing security: Security partners include Chainlink, Fireblocks, Certora, Hacken, The Network Firm, SumSub, and Chainalysis, and the roadmap includes AI‑driven smart‑contract security evaluations, but pre‑launch code changes, future upgrades, and new cross‑chain components mean residual risks of undiscovered vulnerabilities, misconfiguration, or integration bugs remain despite audits and monitoring. |
| I.6: Mitigation measures | Smart contract vulnerabilities Oracle configuration errors Custody or integration failures Privileged‑access misuse Upgrade or emergency‑process failures |
| Part J – Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts | |
| S.1: Name | Resilience Core Ltd. |
| S.2: Relevant legal entity identifier | 2549004WYGE5MQ16JH36 |
| S.3: Name of the crypto-asset | RE |
| S.4: Consensus mechanism | Resilience’s RE governance token is planned to live primarily on Ethereum mainnet, while the broader Re protocol already runs across multiple EVM networks including Ethereum, Avalanche, and Arbitrum. Consensus model (succinct): Ethereum Proof‑of‑Stake (PoS) L1, plus deployments of the Re protocol on Avalanche PoS and Arbitrum (an L2 optimistic rollup settling to Ethereum PoS). Why this is secure: Why this is efficient: |
| S.5: Incentive mechanisms and applicable fees | Incentive mechanisms and who earns what RE is a fixed‑supply token (1 billion hard cap, no ongoing inflation or emissions schedule). It is designed as a governance, coordination, and security protocol token, not as equity, debt, a claim on protocol revenue/insurance cash flows, or an automatically yield‑bearing asset. Planned incentives are tied to active roles, not passive holding: RE is intended to be staked or bonded by “sensitive” participants such as auditors, reviewers, and program proposers, with lockups and potential slashing used as accountability tools. Challenge and oversight deposits in RE can also be posted to trigger reviews or disputes under governance‑defined rules, so participants are effectively rewarded by being able to take on these roles and participate in governance rather than through automatic emission rewards. There is no described proof‑of‑stake validator set or mining system for base‑layer network security, and no perpetual staking reward schedule or mining incentives for simply holding or locking RE. Token locking otherwise comes from vesting for team and investors and from any staking/bonding requirements tied to protocol roles. Fees and how they are handled The underlying business model generates economics from real‑world reinsurance activity: insurance premiums, structured product fees, and issuance/redemption/management fees attached to onchain capital products like reUSD and reUSDe and the surrounding infrastructure. However, RE holders do not have a claim on these revenues, and there are explicitly no burn programs, buyback programs, or automatic revenue distributions to RE holders. |
| S.6: Beginning of period to which disclosed information relates | 2026-04-14 |
| S.7: End of period to which disclosed information relates | 2026-04-27 |
| S.8: Energy consumption | 66.02878 |
| S.9: Energy consumption sources and methodologies | Data provided by CCRI; all indicators are based on a set of assumptions and thus represent estimates; methodology description and overview of input data, external datasets and underlying assumptions available at: https://carbon-ratings.com/dl/whitepaper-mica-methods-re and https://docs.mica.api.carbon-ratings.com. We do not account for any offsetting of energy consumption or other market-based mechanism as of today. |
| S.10: Renewable energy consumption | Not applicable as the annual energy consumption is less than 500,000 kWh. |
| S.11: Energy intensity | Not applicable as the annual energy consumption is less than 500,000 kWh. |
| S.12: Scope 1 DLT GHG emissions - controlled | Not applicable as the annual energy consumption is less than 500,000 kWh. |
| S.13: Scope 2 DLT GHG emissions - purchased | Not applicable as the annual energy consumption is less than 500,000 kWh. |
| S.14: GHG intensity | Not applicable as the annual energy consumption is less than 500,000 kWh. |
| S.15: Key energy sources and methodologies | Not applicable as the annual energy consumption is less than 500,000 kWh. |
| S.16: Key GHG sources and methodologies | Not applicable as the annual energy consumption is less than 500,000 kWh. |
| S.17: Energy mix | |
| S.18: Energy use reduction | |
| S.19: Carbon intensity | |
| S.20: Scope 3 DLT GHG emissions - value chain | |
| S.21: GHG emissions reduction targets or commitments | |
| S.22: Generation of waste electrical and electronic equipment (WEEE) | |
| S.23: Non-recycled WEEE ratio | |
| S.24: Generation of hazardous waste | |
| S.25: Generation of waste (all types) | |
| S.26: Non-recycled waste ratio (all types) | |
| S.27: Waste intensity (all types) | |
| S.28: Waste reduction targets or commitments (all types) | |
| S.29: Impact of the use of equipment on natural resources | |
| S.30: Natural resources use reduction targets or commitments | |
| S.31: Water use | |
| S.32: Non recycled water ratio | |
| S.33: Other energy sources and methodologies | |
| S.34: Other GHG sources and methodologies | |
| S.35: Waste sources and methodologies | |
| S.36: Natural resources sources and methodologies | |