# Portal Welcome to Radiant Capital Use this portal to begin your journey.

	Cover image
What is Radiant?	Group 2.png	Welcome to Radiant Capital
Tokenomics	Radiant Tokenomics.png	RDNT Token
Markets	Deposit.png	Markets
Dashboard	Borrow.png	Dashboard
Manage	Dynamic Liquidity Provisioning.png	Manage Radiant
Guardian Fund	Contracts & Security.png	Radiant Guardian
Radiant v1 Migration - Tutorials	Utility.png	Migrating RDNT v1 to v2
Governance	Governance.png	Governance
Remediation	Group 3.png	Remediation
Recovery Bounty Program	Navigation.png	Recovery Bounty Program
Contracts & Security	Group 4.png	Contracts & Security
Mission & Values	Mission & Values.png	Mission & Values
Frequently Asked Questions	Frequently Asked Questions.png	Frequently Asked Questions
Branding	Branding.png	Branding
Partners & Integrations	Partnership Details.png	Integrations
Terms of Service	Terms of Service.png	Terms of Service
Roadmap - SOON	Roadmap.png	Broken link

# Welcome to Radiant Capital Radiant Capital is a corporate-grade protocol, purpose-built to meet the highest standards of security, reliability, and scalability expected by enterprises and institutions. Every layer of its design reflects a commitment to safeguarding user assets and ensuring consistent performance, from undergoing rigorous third-party audits to implementing robust risk management frameworks that protect against volatility and unforeseen market conditions. Continuous monitoring and system optimization further reinforce the protocol’s resilience, allowing it to adapt and remain dependable even under high-demand or stressed environments. By aligning with enterprise-level expectations, Radiant delivers a trustworthy and future-proof foundation for both institutional participants and the broader DeFi community, enabling large-scale adoption with confidence. ### Lend and Borrow Seamlessly Radiant aims to be the first corporate-grade money market where users can deposit any major asset on any major chain and borrow various supported assets across multiple chains. The Radiant DAO's primary goal is to consolidate the \~$22 billion of fragmented liquidity dispersed across alternative layers (source:[ DefiLlama](https://defillama.com/chains)). Lenders who provide liquidity are interacting and providing utility to the platform. Borrowers can withdraw against collateralized assets to obtain liquidity (working capital) without selling their assets and closing their positions. In addition, lenders can capture the added value from the communities’ engagement through the native token $RDNT.

Radiant’s cross-chain interoperability functions atop[ Layer Zero](https://layerzero.network/), with v1 leveraging Stargate’s stable router interface. For example, lenders may reclaim their collateral and direct which chain to withdraw funds from and what percentage they’d like sent to each chain. Radiant focuses on core offerings resilient to oracle manipulation and leverages the $2M+ already spent in security audits executed by [Layer Zero](https://github.com/LayerZero-Labs/Audits) & [Stargate](https://stargateprotocol.gitbook.io/stargate/audits). In addition, Radiant v2 is audited by [Open Zeppelin](https://blog.openzeppelin.com/radiant), [Peckshield](https://docsend.com/view/4irymmv5uifge3tr), [Zokyo](https://docsend.com/view/vcux2vysnzcehq9b), and [Blocksec](https://blocksec.com/) with an ongoing [ImmuneFi](https://immunefi.com/bounty/radiant/) bug bounty program. *Welcome to an omnichain future.* ### **GuardianLP - A New DeFi Security Framework** Radiant V3 has been under development for over a year as the DAO strives to invent a new but necessary DeFi primitive. Radiant Guardian is a next-generation DeFi security framework from Radiant Capital that protects user deposits while making security funds productive. It introduces **GuardianLP (gLP)**: a liquid, yield-generating LP token backed by the Guardian Fund that auto-reimburses lost deposits via a community-DAO-controlled transparent remediation engine — establishing a new DeFi primitive that blends **real protection, real yield, and real composability**. ## Why Use Radiant? Traditionally, to get a loan, you'd need to go to a bank or other financial institution with lots of liquid cash and provide them with collateral. Radiant removes the intermediaries from asset trading, futures contracts, and savings accounts. A lending protocol must operate on a network with high activity volume and broad institutional adoption to operate at full capacity. There are many L1 options, but Ethereum remains the most utilized. Historically, however, it has been marred by high transaction fees. Sidechains nd layer 2 solutions implemented by the [Arbitrum network](https://arbitrum.io/), [Base](https://www.base.org/), [Binance Chain](https://www.bnbchain.org/en), embody the present and future of Ethereum and EVM scaling. The Radiant DAO utilizes the native utility token, **$RDNT.** By interacting and providing utility to the platform, users can capture the added value from the communities’ engagement through the native utility token $RDNT from borrowers and platform fees (visit the [RDNT Token](/radiant/project-info/rdnt-tokenomics) section for more information). ## Links App: [https://app.radiant.capital](https://radiant.capital/)\ Governance Proposals/Feedback: \ Governance Voting: \ Discord: \ Twitter: \ Telegram: \ YouTube: # Radiant - v1 The First Omnichain Money Market Radiant v1 launched as the protocol’s first iteration toward unifying fragmented liquidity across chains. Deployed exclusively on **Arbitrum**, it introduced the core mechanics of lending and borrowing while laying the groundwork for Radiant’s omnichain vision. ### Core Mechanics * **Lending & Borrowing on Arbitrum**\ Users deposited collateral such as ETH, BTC, or stablecoins into Radiant’s money market on Arbitrum, earning interest while enabling borrowers to access liquidity without selling their assets. * **Cross-Chain Borrowing (via Stargate)**\ Through integration with **Stargate’s stable router interface**, borrowers could direct their withdrawals to other supported chains. This meant that even in its earliest form, Radiant allowed users to take out loans in different chains while collateral remained on Arbitrum. * **Fee Distribution Model**\ Platform fees were split evenly: *50% to lenders* (deposit APY), and *50% to RDNT lockers* through vesting and locked rewards.\ This created a direct link between liquidity providers, active token holders, and the growth of the DAO. * **Vesting & Early Exit Penalty**\ Rewards in RDNT vested linearly over 28 days. Users could: * Wait the full vesting period and claim 100%. * Exit early with a **50% penalty**. * Penalties were redistributed to lockers, creating sustainable yield for long-term participants. * **RDNT Utility in v1**\ Locking RDNT granted access to platform and penalty fees, paid in blue-chip assets (ETH, BTC, stablecoins), while also serving as the protocol’s first governance token. ### Security Foundations * Contracts audited by **PeckShield** and **Solidity Finance**. * A post-launch **bug bounty program** added an additional layer of security. * Early governance relied on the **Radiant DAO**, which introduced time-locked proposals and community-driven changes. ### Lessons from v1 Radiant v1 proved that cross-chain money markets were possible, but also revealed important lessons that shaped the design of v2 and v3: * **Tokenomics Calibration** was required to align RDNT emissions with protocol revenue and long-term growth. * **Cross-Chain Limitations**: v1 enabled borrowers to withdraw liquidity on other chains via Stargate routing, but the RDNT token itself was not yet omnichain. Without OFT functionality, RDNT remained siloed on Arbitrum, which limited true interoperability and native deployments on additional networks. * **Community Transparency**: unclear token allocations and timelock communication at launch highlighted the need for stronger DAO governance. * **Sustainable Liquidity**: long-term participation needed mechanisms that rewarded aligned users, beyond short-term APYs. ### Transition to v2 A major milestone after v1 was the migration of the RDNT token into an **Omnichain Fungible Token (OFT)** via LayerZero, enabling seamless transfers of RDNT across supported chains. This upgrade, combined with the launch of Radiant on additional networks (beginning with BNB Chain), marked the beginning of true omnichain deployment. Radiant v1 was officially **sunset** following the launch of v2 in March 2023 and the ratification of [**RFP-43**](https://snapshot.box/#/s:radiantcapital.eth/proposal/0x726387faef57c08ae9a64dd6cbdbaa1e795d9d5a77ee347497c159409352b64b) on **August 21, 2024**, which formalized the closure of the original protocol. During the transition window, users had sufficient time to vest their RDNT, migrate via the official wizard, and withdraw funds from v1 contracts without penalties. The **migration wizard is no longer funded or supported**. However, resources remain available for users who still hold v1 RDNT or funds in v1 contracts: * [Migrate RDNT v1 to RDNT v2](/radiant/navigation/migrating-rdnt-v1-to-v2) * [Withdraw funds from v1 contracts](/radiant/navigation/withdrawing-funds-from-v1) {% hint style="warning" %} **Important Notice**\ Radiant v1 is permanently deprecated and no longer supported. The DAO provided ample time and announcements before sunsetting v1. The support team does **not actively handle** v1-related issues anymore. Still, whenever possible, the community and contributors may assist on a best-effort basis. Any interaction with legacy contracts is at your own risk — always verify contract addresses before proceeding. {% endhint %} # Radiant - v2 ## **Radiant v2: Evolution Towards DeFi 3.0 and Its Economic Model** Radiant v2 represents the next step in the evolution of the Radiant platform, addressing the shortcomings and limitations observed in the earlier versions of the DeFi ecosystem. DeFi 1.0 was plagued by copycat protocols that lacked real utility and governance tokens with high emissions, which inevitably got farmed to zero. These emission models failed for several key reasons: 1. **Lack of real utility**: Tokens offered little or no actual use case, and “governance-only” tokens were re-priced over time to reflect their governance value. 2. **Low barriers to entry**: Liquidity providers (LPs) could easily deposit tokens, earn yield, sell them off, and move on once yields compressed. This cycle repeated across more than 95% of DeFi protocols.

After the first year of v1, two main concerns emerged from discussions with community members and advisors: 1. How will the next version of Radiant create a better utility exchange between lenders/borrowers and the protocol? 2. In keeping with the Foundation’s core value of “collective benefit,” how should the protocol decide who is eligible for the utility of receiving RDNT emissions? To address these concerns, Radiant v2 features revolutionary changes to core protocol mechanics, emissions, utility, and deeper cross-chain functionality. Radiant v2 focuses on three main pillars: 1. **Preventing Mercenary Farming**: Mechanisms are in place to prevent participants from seeking short-term profits without contributing to the long-term sustainability of the ecosystem. 2. **Providing Real Use Cases**: Radiant v2 enables seamless cross-chain borrowing and lending, providing real utility for users and fostering long-term value. 3. **True Decentralized Governance**: Fully implemented governance through Discourse Discussion Boards and Snapshot voting, empowering the community to actively shape the future of the protocol. Read the [Radiant v2](https://medium.com/@RadiantCapital/cryptos-most-profitable-protocol-a-new-era-for-defi-b374ca82a741) Medium article for a full breakdown of the changes. ### Radiant v2 Economic Model The preceding article provides detailed insights into the v2 enhancements. Now, let’s outline the economic model of Radiant v2, covering its fundamental to advanced functionalities. #### Basic Lending and Borrowing Radiant is a money market where users can deposit and borrow assets across multiple chains. * Depositing assets allows lenders to earn competitive market rates denominated in the deposited asset, which are influenced by borrower fees. * Borrowing entails interest rates aligned with market utilization, reflecting the demand for specific assets. #### Providing Liquidity with dLP Users can enhance liquidity by pairing RDNT with ETH or BNB, depending on the chain, and locking dLP tokens. This action grants access to protocol fees distributed in blue-chip assets like ETH, BTC, and stablecoins For further insights on dLP and fee-sharing, refer to [LIQUIDITY PROVISIONING](https://app.gitbook.com/o/JNKyqnrAqlkBNQ7H0jn6/s/nid2aaGplWMFCWpNUeRM/liquidity-provisioning) #### Unlocking RDNT Emissions Users meeting the criteria of locking dLP equivalent to or exceeding 5% of their total deposits unlock RDNT emissions. For example, a $1,000 deposit requires a minimum $50 worth of locked dLP. Radiant v2’s Economic Model introduces versatile features designed to foster a dynamic ecosystem where participants are generously rewarded. Additional functionalities include looping, dLP zapping, and customizable lock periods. # What's New in v3 Building to institutional-grade standards and braving DeFi's firsts. Radiant v3 is not just an upgrade — it’s a **transformation**. Built on the foundations ratified by the community ([RFP-28](https://snapshot.box/#/s:radiantcapital.eth/proposal/0x349c3a829823d5fb22a2e1a8e3a48c2a844b90a96680d9b262b932c0ee447088), [RFP-48](https://snapshot.box/#/s:radiantcapital.eth/proposal/0xd2159dc33d032b03345ac15b6fa13d95103657e053bd7abf5f994b858a0328ec), [RFP-51](https://snapshot.box/#/s:radiantcapital.eth/proposal/0xfeb2cc5bc3e1e00ec6cbe9a49b46081c37df5928172c2b0da8a7f48194b59924), [RFP-52](https://snapshot.box/#/s:radiantcapital.eth/proposal/0x8b69c2535698b6a93b383dcba4c84e4174e65a7b1535c6b66ccf2ae481d88b86)) and anchored by the launch of the [Guardian Fund](https://medium.com/@RadiantCapital/radiant-guardian-defi-security-reimagined-6fd5c4d96da7), v3 ushers in a **new institutional-grade era** for Radiant Capital. It combines **innovative primitives (isolated RIZ markets, composable GuardianLP), hardened security post-exploit, and true community governance (DeFi’s first elected Community Council)** into a single coordinated protocol stack. *** ### Table of contents 1. [Key features](#id-1.-key-features) 2. [Architecture & primitives](#id-2.-architecture-and-primitives) * [Isolated RIZ Markets (Radiant Innovation Zones)](#isolated-riz-markets-radiant-innovation-zone) * [Guardian Fund & GuardianLP (gLP)](#guardian-fund-and-guardianlp-glp) * [Competitive Dynamic Reserve Factors](#competitive-dynamic-reserve-factors) * [Weighted Emissions Allocation Model](#weighted-emissions-allocation-model) * [Reduced RDNT Inflation](#reduced-rdnt-inflation) * [Dynamic Revenue Distribution](#dynamic-revenue-distribution) 3. [Governance & community controls](#id-3.-governance-and-community-controls) 4. [Smart contract & security notes](#id-4.-smart-contract-and-security-notes) 5. [Parameter table (v3 defaults & meanings)](#id-5.-parameter-table-v3-defaults-and-meanings) 6. [References & further reading](#id-6.-references-and-further-reading) *** ## 1. Key features * **True Community Governance, a first in DeFi** — implemented as an integrated stack of Discourse discussion boards, Snapshot voting, and an annually elected Community Council that executes DAO-level responsibilities. * **Isolated RIZ Markets (Radiant Innovation Zones)** — market-level isolation that lets Radiant list many assets while keeping risk isolated from Core Markets. * **Guardian Fund & GuardianLP (gLP), a first in DeFi** — a community-governed automated remediation fund and a liquid, yield-bearing LP token that represents protection capital and earns protocol revenue. * **Competitive Dynamic Reserve Factors** — per-market reserve factors that can be adaptively tuned to market conditions and competitiveness across chains/markets. * **Reduced RDNT Inflation** — a new economic paradigm that throttles baseline RDNT emissions while introducing weighted, usage-aligned incentives. * **Dynamic Revenue Distribution** — protocol revenue is distributed on a dynamic schedule to stakeholders, security funds, incentives, and the DAO itself. * **Weighted Emissions Allocation Model** — emissions become a configurable, weight-driven allocation to markets (favoring long-term aligned participants and RIZ adoption). ## 2. Architecture & primitives This section explains the primitives and how they interact. ### Isolated RIZ Markets (Radiant Innovation Zone) **What:** RIZ are *isolated market containers* that enable Radiant to list and support many assets while capping systemic risk. Each RIZ has its own collateral rules, interest model, reserve factor cap, and liquidation/health parameters. **Why:** Listing many assets increases utility but also increases correlated risk. Isolation means a single asset can’t create bad debt for other markets or drag the whole protocol into insolvency. **Mechanics:** * Each RIZ implements market-level parameters: `maxLTV`, `liquidationThreshold`, `reserveFactorBounds`, and `marketUtilizationTarget`. * Core markets (e.g., highly-audited assets) get looser parameter bounds and wider collateral limits; experimental RIZ markets have stricter caps and greater guardrails. ### Guardian Fund & GuardianLP (gLP) **What:** The Guardian Fund is a community-DAO-controlled remediation reserve, held in a multi-sig and seeded with assets (including a DAO RDNT allocation). `GuardianLP (gLP)` is a liquid, yield-bearing liquidity token minted by depositing ETH into the Guardian Fund. **Why:** Traditional safety modules hold capital idle. Guardian converts protection capital into composable yield-bearing capital while creating a direct economic alignment between those who provide protection and those who benefit from it. **Key rules & properties:** * **Eligibility:** Users must lock at least **15%** of their lending market deposits as `dLP` to be eligible for automatic remediation (this mirrors the emissions eligibility mechanism but at a higher lock threshold). Lock periods are configurable (e.g., 30/90/180/360 days). * **Automatic Remediation Engine:** If an eligible user suffers a qualifying exploit, the Guardian Fund distributes funds proportionally (capped at 100% of the net deposit loss for each eligible wallet) according to a transparent formula. * **GuardianLP (gLP) economics:** gLP holders receive real yield from a mix of protocol revenue allocation, staking/native yield on reserve assets (e.g., wstETH), RDNT incentive streams, and DAO-managed gLP burns. gLP may be partially slashed if a remediation payout is necessary, this creates a risk/return market for protection providers. * **Initial funding & transitions:** The DAO seeded the fund per the ratified RFPs; future growth is expected to come from user ETH deposits to mint gLP and from revenue flows. **Composability:** gLP is designed to be usable across DeFi: as collateral in select RIZ markets (later), for yield strategies, and for liquidity provision in partner protocols. ### Competitive Dynamic Reserve Factors **What:** Reserve factors are no longer static protocol settings. v3 introduces *competitive dynamic reserve factors* which adapt per market and can be tuned by governance to balance competitiveness, liquidity depth, and safety. **Why:** Static reserve factors create inefficient markets. Dynamic factors allow Radiant to optimize for market conditions and cross-protocol competition. **Mechanics (high level):** * Each Radiant market has a `reserveFactor`. The DAO (governance-specified) can adjust the active `reserveFactor` to utilization, volatility, and an objective function that considers `borrowUtilization`, `spread`, and `liquidityDepth`. ### Weighted Emissions Allocation Model **What:** RDNT emissions are allocated according to a weight-driven model that places more supply-side incentives where they produce long-term value (e.g., strategic partners, RIZ Markets, and markets with higher utility). **Why:** Uniform, time-based emissions encourage mercenary farming. A weighted approach aligns incentives to durable liquidity and responsible market behavior. **Mechanics (example):** * Each market receives a score derived from a configurable formula (factors include: `avg_health_factor`, `usage_score`, and `riz_market`). * RDNT per-epoch emissions are distributed proportionally to market scores subject to global caps and a DAO floor. * A portion of RDNT emissions may be directed to `gLP` or to burn mechanisms depending on DAO policy. **Notes:** The exact weighting function and epoch cadence are governance parameters and were ratified as part of the economic paradigm RFPs. ### Reduced RDNT Inflation **What:** v3 reduces baseline RDNT inflation compared to previous emission schedules. Combined with the weighted emission model, this reduces token supply pressure while targeting incentives where they produce sustainable growth. **Why:** Excessive emissions dilute token value and create contradictory incentives. Lower baseline inflation, plus targeted, weight-driven incentives, allow Radiant to reward users without undermining tokenomics. ### Dynamic Revenue Distribution **What:** Protocol revenue (fees, flash loan fees, liquidation premiums) is dynamically allocated across several buckets: DAO treasury, Guardian Fund (security), incentives (dLP rewards and RDNT allocation), and ecosystem growth. **Why:** Dynamic distribution ensures the protocol can divert more revenue toward security or incentives when needed (for example, funding the Guardian Fund during high-risk periods). **Mechanics (example split):** * Default: `60%` dLP Lockers, `15%` Emissions/Remediation, `15%` DAO OpEx, `10%` Guardian Fund. (Exact percentages are DAO-configurable.) * Revenue routing is on-chain and auditable; the Guardian Fund receives a non-dilutive portion so that protection is maintained without requiring recurring token minting. ## 3. Governance & community controls Radiant v3 formalizes community control while keeping operational agility for urgent actions. Governance operates across three coordinated layers: ### Governance layers * **Discussion Layer**: Open forums (Discourse) for specification, debate, and early-stage design. All new proposals must have a Discussion thread before moving on-chain. Off-chain votes for signaling, community sentiment, and fast-turnaround, low-risk decisions. * **Snapshot Voting**: On-chain Snapshot votes for a transparent, low-cost mechanism for tokenholders to signal community consensus and guide protocol decisions. Snapshot results inform on-chain proposals. * **Community Council**: An annually elected body that holds delegated, narrowly-scoped authorities (e.g., parameterization within pre-approved bands, emergency coordination) and is accountable to the DAO. ### Roles & responsibilities * **Tokenholders**: Ratify major economic changes, approve large treasury movements, and elect the Community Council. * **Stakeholders/Partners**: Stakeholders and partners play the role of aligning capital, expertise, and ecosystem integrations with the protocol’s growth, ensuring Radiant remains secure, liquid, and broadly adopted. * **Community Council**: Execute parameter updates inside pre-authorized bounds, manage listing cadence for routine assets, and coordinate emergency response when needed. ### Emergency powers & checks * Emergency actions (pause markets, quarantine RIZ) require council approval and are time-delayed for larger actions. Any emergency measure is auditable and must be reported to the DAO within a defined window. * All discretionary multisig operations must publish a rationale and will be subject to retrospective DAO review. ## 4. Smart contract & security notes This section is a high-level summary. For code-level details, consult the repository and audits. ### Audits & reviews * v3 contracts receive formal independent audits (list and links maintained in the docs hub). Any critical severity findings must be fixed before deployment. ### Multisig & timelocks * Multisig operations are protected by timelocks. Governance may configure emergency exception paths but those are logged and contestable. ### Best-of-breed hardening * v3 contracts underwent independent audits and are bound by multisig timelocks and emergency safeguards. Together with more stringent SECOPS, Radiant now sets a new security baseline for lending protocols, turning setbacks into resilience. ### On-chain automation & constraints * Critical actions (minting/burning gLP, reserve factor adjustments beyond small deltas, RIZ quarantines) have on-chain timelock and require either DAO votes or Council approvals depending on the parameter. ### Remediation formulas & transparency * Remediation payouts follow deterministic formulas based on locked dLP share, net depositor loss, and fund coverage ratio. All calculations are off-chain components that are reproducible by the community. ## 5. Parameter table (v3 defaults & meanings) | Parameter | Default (example) | Purpose | | ----------------------------- | -------------------------------- | ------------------------------------------------------------------------------ | | Guardian protection threshold | 15% | Minimum dLP locked relative to deposits to qualify for Guardian protection | | Community Council elections | Annual | Elections for governance representatives occur once per year. | | Initial Guardian seed | 50M RDNT DAO-approved allocation | Initial funding of Guardian Fund per governance ratification | | Multisig timelocks | 3 days | Admin multisig transactionsare subject to time delays. | | gLP slashing policy | Pro-rata based on payout | gLP backing may be reduced if the Guardian Fund is below the exploited amount. | *** ## 6. References & further reading * [Radiant Guardian — DeFi Security Reimagined (Medium)](https://medium.com/@RadiantCapital/radiant-guardian-defi-security-reimagined-6fd5c4d96da7) * [Snapshot Proposal: RFP-28](https://snapshot.box/#/s:radiantcapital.eth/proposal/0x349c3a829823d5fb22a2e1a8e3a48c2a844b90a96680d9b262b932c0ee447088) * [Snapshot Proposal: RFP-48](https://snapshot.box/#/s:radiantcapital.eth/proposal/0xd2159dc33d032b03345ac15b6fa13d95103657e053bd7abf5f994b858a0328ec) * [Snapshot Proposal: RFP-51](https://snapshot.box/#/s:radiantcapital.eth/proposal/0xfeb2cc5bc3e1e00ec6cbe9a49b46081c37df5928172c2b0da8a7f48194b59924) * [Snapshot Proposal: RFP-52](https://snapshot.box/#/s:radiantcapital.eth/proposal/0x8b69c2535698b6a93b383dcba4c84e4174e65a7b1535c6b66ccf2ae481d88b86) * [Radiant Governance Forum](https://community.radiant.capital/) * [Radiant Analytics Dashboard](https://dune.com/radiant/analytics) * [Audits & Security Disclosures](https://docs.radiant.capital/radiant/contracts-and-security/audits) # RDNT Token ## Token Information {% tabs %} {% tab title="Arbitrum" %} **RDNT token:** \ [`0x3082CC23568eA640225c2467653dB90e9250AaA0`](https://arbiscan.io/token/0x3082cc23568ea640225c2467653db90e9250aaa0) **RDNT/WETH Balancer LP:**\ [`0x32dF62dc3aEd2cD6224193052Ce665DC18165841`](https://arbiscan.io/token/0x32df62dc3aed2cd6224193052ce665dc18165841) {% endtab %} {% tab title="Base" %} **RDNT token:** \ [`0xd722E55C1d9D9fA0021A5215Cbb904b92B3dC5d4`](https://basescan.org/token/0xd722e55c1d9d9fa0021a5215cbb904b92b3dc5d4) **RDNT/WETH Univ3 dynamic LP:**\ [`0x8A76639FE8e390Ed16eA88f87BEB46d6A5328254`](https://basescan.org/token/0x8a76639fe8e390ed16ea88f87beb46d6a5328254) {% endtab %} {% tab title="BNB Chain" %} **RDNT token:** \ [`0xf7DE7E8A6bd59ED41a4b5fe50278b3B7f31384dF`](https://bscscan.com/token/0xf7DE7E8A6bd59ED41a4b5fe50278b3B7f31384dF) **RDNT/WBNB PancakeSwap LP:**\ [`0x346575fc7f07e6994d76199e41d13dc1575322e1`](https://bscscan.com/token/0x346575fc7f07e6994d76199e41d13dc1575322e1) {% endtab %} {% tab title="Ethereum" %} **RDNT token:** \ [`0x137dDB47Ee24EaA998a535Ab00378d6BFa84F893`](https://etherscan.io/token/0x137ddb47ee24eaa998a535ab00378d6bfa84f893) **RDNT/WETH Balancer LP:**\ [`0xcF7b51ce5755513d4bE016b0e28D6EDEffa1d52a`](https://etherscan.io/token/0xcf7b51ce5755513d4be016b0e28d6edeffa1d52a) {% endtab %} {% endtabs %} RDNT, an OFT-20 token, is Radiant's native utility token.\ \ [Layer Zero](https://layerzero.network/)’ omnichain fungible token (OFT) interoperability solution enables native, cross-chain token transfers. As voted in by [Governance Proposal RFP-4](https://dao.radiant.capital/#/proposal/0x058ea8db46ec92bfec2a36691aba75f671f04e99c6ffa7141768e3760d8bf584), $RDNT emissions incentivize ecosystem participants to provide utility to the platform as [dynamic liquidity providers](/radiant/project-info/manage-radiant/dlp) (dLP). Only users with locked dLP (liquidity tokens) activate eligibility for RDNT emissions on their deposits or borrows. Additionally, dLP’s share in the utility of Platform Fees is captured in blue-chip assets such as Bitcoin, Ethereum, BNB, and stablecoins from borrowers paying loan interest, flash loans, and liquidation fees. Through decentralized discussions, voting, and governance, the [Radiant DAO](/radiant/governance/overview) has and always will dictate the decisions, and, ultimately, the vision of the Radiant ecosystem. ## Liquidity Mining Only users with locked [Dynamic Liquidity](/radiant/project-info/manage-radiant/dlp) (Liquidity Tokens) activate eligibility to receive RDNT emissions within the money market. $RDNT Liquidity mining emissions can be instantly claimed for the total amount, provided they are [zapped](/radiant/project-info/rdnt-tokenomics/liquidity-provisioning/zapping-dlp) into locked dLP tokens by pairing the claimed $RDNT with wstETH/BNB. Alternatively, emissions may be vested for three months. Vesting RDNT may be claimed early for an exit penalty to receive 10-75% of rewards, decaying linearly during the three-month vesting period. Locking dLP tokens is a one to twelve-month process and must be re-locked after maturity to continue receiving platform fees. For a detailed breakdown of how dynamic liquidity provisioning functions, visit the [dLP section.](/radiant/project-info/manage-radiant/dlp) For a detailed breakdown of how Locking & Vesting work, visit the [Manage Radiant](/radiant/project-info/manage-radiant) section. ## Genesis Token Allocation

**RDNT has a total supply of** [**1,500,000,000 tokens.**](https://dao.radiant.capital/#/proposal/0x1045e5e770599ac2ed44b727e4c47e8a0b13589082dcac138f8edde3bd86e249) * 47.1% emitted as incentives for suppliers and borrowers, released over five years * 13.3% to the team, released over five years, with a three-month cliff (10% of the team allocation is locked at the genesis of the protocol and unlocks at the 3-month cliff) * 30.9% allocated to the [Radiant DAO Reserve](/radiant/contracts-and-security/dao-reserve) * 4.7% allocated to core contributors and advisors, released over one and a half years * 4% reserved for the Treasury & LP, ratified in[ RFP-9 governance proposal](https://dao.radiant.capital/#/proposal/0x35eee1016fcb6251a0178f546a9d4446a0aac5e907441713f5daded205e36d2a) ### RDNT Token Unlock Schedule

# Liquidity Provisioning Dynamic Liquidity Provisioning (**dLP**) powers Radiant’s incentive system. By supplying liquidity into the dLP, users unlock protocol fees, remain eligible for emissions, and reinforce the protocol’s stability. From this page, you can learn the fundamentals of dLP and explore our step-by-step guides: {% content-ref url="/pages/C5lfIcUQk6u9ojVTgb9i" %} [What is dLP?](/radiant/project-info/rdnt-tokenomics/liquidity-provisioning/what-is-dlp) {% endcontent-ref %} {% content-ref url="/pages/k6slDBMAenHFSFZyZQVH" %} [dLP Liquidity Options](/radiant/project-info/rdnt-tokenomics/liquidity-provisioning/liquidity-options) {% endcontent-ref %} {% content-ref url="/pages/nZwMSx2sHkpUGpYsu5It" %} [dLP Architecture](/radiant/project-info/rdnt-tokenomics/liquidity-provisioning/dlp-architecture) {% endcontent-ref %} {% content-ref url="/pages/tKo2d0sAASWt9BzKL6Qm" %} [Zapping dLP](/radiant/project-info/rdnt-tokenomics/liquidity-provisioning/zapping-dlp) {% endcontent-ref %} {% content-ref url="/pages/n5qFpZmlfKDHsmvI0kAB" %} [Maintaining Eligibility Status](/radiant/project-info/rdnt-tokenomics/liquidity-provisioning/eligibility) {% endcontent-ref %} # What is dLP? Lock dLP, activate emissions! Dynamic Liquidity Provisioning (dLP) is a novel approach approved by the Radiant DAO designed to counteract mercenary capital and ensure a more equitable value exchange between long-term users and the protocol. Liquidity pools are crucial to many DeFi protocols, allowing users to provide liquidity in the form of paired assets—such as RDNT & ETH or BNB—in exchange for a share of the pool's potential yield. dLP tokens can be locked through the protocol to activate RDNT emissions within the money market, receive a portion of protocol revenue, and gain governance voting power. ## dLP Utility In exchange for users enhancing the utility of Radiant by locking Dynamic Liquidity tokens, there are three primary rewards: 1. Activate $RDNT emissions on deposits & borrows 2. Share in platform fees comprised of blue-chip assets such as Bitcoin, Ethereum and stablecoins 3. Obtain voting power for governance via the Radiant DAO

Below, you can see **natural market rates** highlighted in red and RDNT emissions directly underneath, in blue/purple. Users who simply deposit but don't add value to the protocol will continue to earn natural market rates but will not be eligible for RDNT emissions.

{% hint style="info" %} **To trigger RDNT emissions on both deposits and borrows, you must lock at least 5% of your deposit's USD value in dLP tokens.** {% endhint %} **Example 1:** If you deposit $1M USDC but have zero dLP tokens locked, you'll earn the basic APY but won't qualify for additional RDNT emissions. **Example 2:** Deposit $1,000 USDC and lock $50 in dLP tokens. Now you're eligible for RDNT emissions, thanks to hitting that 5% threshold. **The requirement to lock liquidity tokens in dLP form serves the Radiant money market in multiple ways:** 1. **Long-Term Participation:** Locking dLP tokens effectively commits users to a set period, increasing the likelihood that they'll maintain their deposited collateral. 2. **RDNT Emissions Activation:** This commitment enables RDNT emissions, rewarding those who are invested in the protocol's long-term vision. 3. **Attracting New Users:** The above dynamics make the Radiant money market more appealing to potential liquidity providers, thereby stimulating both growth and development. This strategic cycle not only sustains long-term liquidity but also catalyzes new inflows, making it a win-win for both individual users and the protocol at large. ### Max dLP Locking APR On the [Markets Page](/radiant/project-info/markets), a user can review the Maximum dLP Locking APR, as well as an asset breakdown modal highlighting the APR per asset. #### **Maximum Lock APR** This is calculated as the highest APR achievable when dLP is locked for a one-year period. * **Formula**: `1-month lock APR * 1-year lock multiplier (25x)` #### **1-Month Locking APR** This is the current APR for locking your dLP tokens for a one-month period. * **Formula**: `(Total 1 Month Lockers’ Share of Annualized Protocol Fees) / (Total 1 Month Lockers’ Share of dLP Pool Size)` * **Formula**: `(1 Month Locker Share of Protocol Power) / (Total Protocol Locking Power)` #### **Total Protocol Locking Power** The sum of all lockers’ shares, each adjusted by its respective multiplier. * **Formula**: ``` = (1 Month Lockers' Share of dLP Pool Size * 1 Month Locker Multiplier (1x)) + (3 Month Lockers’ Share of dLP Pool Size * 3 Month Locker Multiplier (4x)) + (6 Month Lockers’ Share of dLP Pool Size * 6 Month Lockers’ Multiplier (10x)) + (12 Month Lockers' Share of dLP Pool Size * 12 Month Locker Multiplier) ``` To learn more about how to lock dLP, please navigate to its section: {% content-ref url="/pages/ypvGcD8llzGIxXxDqzla" %} [How to lock dLP](/radiant/project-info/manage-radiant/dlp/how-to-lock-dlp) {% endcontent-ref %} # dLP Liquidity Options Liquidity pools are essential to many DeFi protocols. They allow users to provide liquidity (in the form of two assets--such as RDNT & ETH) in exchange for a share of the pool's potential yield. dLP tokens can be locked through the protocol to receive protocol revenue, activate RDNT emissions in the money markets if eligible, and provide governance voting power. Radiant currently offers the following liquidity pools (to receive platform fees and activate RDNT emissions if eligible): 1. Arbitrum: Balancer 80/20 composition (80% RDNT & 20% ETH) {% embed url="" %} 2. BNB Chain: Pancakeswap 50/50 (50% RDNT & 50% BNB) {% embed url="" %} 3. Ethereum**:** Balancer 80/20 composition (80% RDNT & 20% ETH) {% embed url="" %} 4. Base: Aerodrome 80/20 composition (80% RDNT & 20% ETH) Base deployment features a new dLP architecture based on Uniswap V3 designed to mimic an 80/20 ratio as used on other RDNT pools. {% hint style="danger" %} Due to this new architecture, the ONLY way to obtain eligible dLP tokens on Base is via zapping through Radiant's front end. **DO NOT** create liquidity directly on Aerodrome, as their returned NFT is not compatible with the RDNT protocol and it **WILL NOT** allow you to earn protocol revenue or RDNT rewards. {% endhint %} {% embed url="" %} Use the ZAP function for Base {% endembed %} You can find more details about dLP architecture in its respective section. {% content-ref url="/pages/nZwMSx2sHkpUGpYsu5It" %} [dLP Architecture](/radiant/project-info/rdnt-tokenomics/liquidity-provisioning/dlp-architecture) {% endcontent-ref %} One may bridge RDNT using the [Layer Zero OFT bridge](/radiant/project-info/rdnt-tokenomics/oft-bridge), providing ecosystem users with maximum flexibility to decide which chain yields will be more lucrative or to split their positions among chains. To learn more about each chain, visit the project pages: {% embed url="" %} {% embed url="" %} {% embed url="" %} {% embed url="" %}
# dLP Architecture ## 80/20 \[Arbitrum + Ethereum] Radiant adopted the 80/20 model after RFP-3 ratification. This model is currently active on Arbitrum, Ethereum, and Base, with some tweaks on the latter, which are addressed below. In this model, users provide liquidity in a proportion of 80% RDNT and 20% ETH. Users can also use the ZAP function to create the LP with one token. You can find more information about the ZAP function in its respective section. {% content-ref url="/pages/tKo2d0sAASWt9BzKL6Qm" %} [Zapping dLP](/radiant/project-info/rdnt-tokenomics/liquidity-provisioning/zapping-dlp) {% endcontent-ref %} For more details about the 80/20 model, visit this [Balancer Medium article.](https://medium.com/balancer-protocol/80-20-balancer-pools-ad7fed816c8d) ## 50/50 \[BNB Chain] For the BNB chain, Radiant uses the 50/50 pool on PancakeSwap. This model pairs 50% of RDNT with 50% of BNB. Users can also use the ZAP function to create the dLP position. ## Dynamic Uniswap v3 \[Base] {% hint style="warning" %} #### Disclaimer The staking token on Base is initially deployed at a 50/50 full range, with plans to shift to an 80/20 range (in alignment with the Arbitrum and Mainnet Balancer configurations), and implement an automated pool manager. \ \ Click [here](https://docs.uniswap.org/concepts/protocol/concentrated-liquidity) to learn more about Univ3 concentrated liquidity. {% endhint %} Radiant is introducing an important update to the dLP architecture on Base, shifting to a Uniswap v3 concentrated liquidity model. In the new system, you can provide liquidity in a more flexible way. You can deposit RDNT or WETH individually(or both). Although this was already possible through the ZAP function in other chains, it works slightly differently in this deployment. When you deposit assets, you will receive your full dLP tokens as a “receipt” of the liquidity you provided. However, your assets don’t go straight into the liquidity pool (as in the other dLP models). Instead, they sit in a liquidity manager contract. This means that assets will be matched and deployed into the liquidity pool in the correct ratio only after a rebalancing process. {% hint style="danger" %} Due to this new architecture, the **only** way to obtain eligible dLP tokens on Base is via zapping through Radiant's front end. \ \ **DO NOT** create liquidity directly on Aerodrome, as their returned NFT is not compatible with the RDNT protocol and it **will not** allow you to earn protocol revenue or RDNT rewards. {% endhint %} At launch, for simplicity, the system will deploy as a 50/50 pool. Over time, it will transition to an 80/20 concentrated position, as the system adjusts the RDNT/WETH composition towards the target ratio. However, some slight variations in the exact ratio may occur due to the nature of Univ3 architecture. To manage the flow of assets, there can be limits on how much of each asset you can deposit. For example, if there is a limit of 10 ETH, you won’t be able to deposit more than that amount. This update improves flexibility and efficiency in providing liquidity. However, it also means that some internal management handles and rebalances assets. Users don’t need to worry about any of this, as it is all taken care of by the smart contract logic. It’s good to be aware that there might be slight differences between the dLP tokens and the actual liquidity available in the pool. # Zapping dLP Automated 1-click liquidity formation ## **What is Zapping?** Say you have ETH and want a position in the Balancer RDNT-ETH pool. Well, it’s a painful process to get into that position. First, you must supply RDNT & ETH in the appropriate proportions, which takes four transactions. Zapping allows you to do it in one click. ## Which assets can be Zapped? We've expanded zapping capabilities to make your experience more convenient. While previously only ETH could be used, now you can also zap into LP using additional assets. | Arbitrum One | BNB Chain | Base | Ethereum | | ------------ | --------- | ---- | -------- | | ETH | BNB | ETH | ETH | | USDC | USDC | USDC | USDC | | USDT | USDT | RDNT | USDT | | RDNT[^1] | RDNT[^2] | | RDNT | ### How It Works When you zap using one of these assets, the system will automatically sell it for ETH behind the scenes. This ETH is then paired with RDNT to create and lock the LP. This feature aims to provide you with greater flexibility in how you engage with Radiant's money market, giving you more ways to earn and lock LP. ## **How to Zap via Radiant UI** First, connect your wallet to [Radiant](https://app.radiant.capital). There are several areas on the platform to zap into dLP, but for the purposes of this tutorial, we will choose to zap from the **Markets page.** You'll need one of our [supported assets](#which-assets-can-be-zapped) in your wallet to zap into LP. If you wish to borrow against your collateral, the Zap wizard supports that, as well. Additionally, ensure you have the native gas token of the supported chain you're using—ETH for Arbitrum and BNB for BNB Chain—to cover transaction fees. {% hint style="warning" %} There is a minimum amount of $5 USD worth of dLP required to initiate a Zap. {% endhint %}

1. Choose your Zap source. Radiant allows you to Zap with supported assets from your **wallet**. You can also **borrow** directly from the money market if you have deposited collateral. Please consider your health factor and risk of liquidation before borrowing. **Zapping will never reduce your health factor below 1.1.** 2. Input your desired amount. To quickly meet the 5% eligibility requirement for RDNT emissions, you can use the **Meet eligibility** button on the zap wizard for an auto-fill option. Of course, you can manually input the amount as well.

3. (Optional) Supplement with RDNT. If you wish to boost the dLP you're forming, you can add RDNT to the mix. The system will automatically calculate and fill in the amount of the primary asset required to create the pair. You can either supply RDNT directly from your wallet or use vesting RDNT without incurring any early-exit penalties. This step is entirely optional but can enhance the value of the dLP you're zapping and locking.

4. (Optional) Adjust Slippage. If you have a specific preference for slippage tolerance, click on the "Slippage" option in the Zap wizard. By default, it's set to 5%. Modify this percentage according to your risk tolerance. If the price changes unfavorably beyond this percentage, your transaction will automatically revert. 5. Select your Zap duration. The longer you lock, the higher the multiplier for your share of platform fees.

## APR Calculations Let's review how the locking APR is calculated for a locking duration of 1 month: **Example: 1 month locking APR:**\ \- Definition: Current locking APR for 1 month \ \- Calculation: (Total 1 Month Lockers’ Share of Annualized Protocol Fees) / (Total 1 Month Lockers’ Share of dLP Pool Size)\ \ **1 Month Locker Share of Protocol Fees:**\ **-**Calculation: (1 Month Locker Share of Protocol Power / Total Protocol Locking Power)\ \ **Total Protocol Locking Power:**\ **-** Calculation: (1 Month Lockers Share of dLP Pool Size \* 1 Month Locker Multiplier (currently 1x)) + (3 Month Lockers’ Share of dLP Pool Size \* 3 Month Locker Multipler (currently 4x)) + (6 month Lockers’ Share of dLP Pool Size \* 6 month Lockers’ Multiplier (currently 10x)) + (12 month Lockers Share of dLP Pool Size \* 12 Month Locker Multipler)) = Total Protocol Locking Power\ \ **Your New Annual Rewards:**\ **-** Definition: User projected annual rewards, in USD terms, based on both RDNT rewards and Protocol fees:\ -Calculation: (Projected user daily RDNT rewards \* 365) + (Projected user daily protocol fees \* 365)

## Confirm Your Zap On this final step, a user can confirm their final zapping details. In the example shown, 21 ETH is being used from their wallet to zap into dLP. Our locking length is also displayed here. ## Transaction Complete Once the transaction is complete, you'll be a part of the liquidity pool and begin receiving platform fees! Reminder, that zapping into dLP will lock your LP tokens for the specified time period (one to twelve months), and can be unlocked after that time period has elapsed. You may view your lock expirations from the **Manage Radiant page.** ### Slippage and Other Risks To manage slippage, click the little icon at the top right. Next, input your slippage tolerance and the maximum percentage you're willing to lose. Once you set your max tolerance for slippage, you're protected up to that amount. When you hit “Confirm” to execute a Zap, you will get an error telling you to reload the page or increase your slippage tolerance. keep in mind that providing liquidity carries some risk, as the value of your LPs may fluctuate as well as impermanent loss. Balancer explains the reduced impermanent loss in their [Medium article](https://medium.com/balancer-protocol/80-20-balancer-pools-ad7fed816c8d), which applies to Radiant's dLP on Arbitrum.
[^1]: [^2]: # Maintaining Eligibility Status {% hint style="info" %} Remember: a minimum 5% ratio between your total deposit value and dLP value must be maintained at all times to remain eligible! {% endhint %} As a risk asset, pricing volatility may swing users in and out of eligibility. Example: * Liam has $5 of dLP on Arbitrum (RDNT/ETH) and $100 of USDC deposits, which means Liam has met the 5% requirement (eligible for emissions) * The price of ETH declines 5%, thus taking the value of dLP down below $5, and Liam is now below the 5% threshold required to earn emissions {% hint style="info" %} The protocol needs to check the eligibility state constantly to determine who is in and who is out. {% endhint %} When you are eligible, banners at the top of each page will indicate "Emissions active."

If you fall out of eligibility, an "emissions inactive" notification is visible at the top of each page and indicates the amount of dLP required to regain eligibility. Click "[zap into dLP](/radiant/project-info/rdnt-tokenomics/liquidity-provisioning/zapping-dlp#how-to-zap-via-radiant-ui)" and follow the prompts to resume receiving $RDNT emissions.

{% hint style="info" %} If a money market participant wishes to increase the likelihood of remaining eligible for RDNT emissions, consider **maintaining a buffer zone above the 5% threshold** to account for volatility. {% endhint %} Example: Roger deposits $1,000 USDC in the money market and needs to lock at least $50 of dLP to qualify for RDNT emissions. Roger decides to lock $60 dLP (10% above the threshold) to maintain eligibility status in the event of volatility. Additionally, users can enable auto-compound & auto-relock from the Manage Radiant page to increase the likelihood of retaining eligibility status.
# RDNT OFT Bridge

$RDNT, an OFT-20 token, is Radiant's native utility token.[ Layer Zero ](https://layerzero.network/)’ omnichain fungible token (OFT) interoperability solution enables native, cross-chain token transfers. With LayerZero’s guarantee of valid delivery, the token is burned on the source chain and minted on the destination chain directly through the token contract. Omnifungible tokens allow for composability across multiple blockchains–no more fragmented liquidity, smart contract or finality risk, or wrapped tokens with considerable custody risk. Use Radiant’s native token bridge to transfer $RDNT to any supported blockchains. $RDNT as an OFT allows the token to exist on more dApps and blockchains than ever. Now, Radiant users can create more complex strategies and high-frequency arbitrage opportunities. ### Why bridge RDNT? 1. Hunt for higher platform fees on other chains 2. Access RDNT emissions in the money market on other chains by activating dLP eligibility 3. Arbitrage ### How to use the OFT Bridge After ensuring your wallet is connected to the Radiant protocol, navigate to the Bridge page. Under "RDNT cross-chain bridge," input the amount of RDNT you would like to bridge, select the destination chain you would like your tokens to be sent, and click "bridge RDNT" to confirm the transaction in your wallet.

The amount of bridge RDNT swapped = gasForTxn + airdroppedNativeOnTargetChain # Markets Seamless lending & borrowing across chains. From this page, users can maximize the potential of their assets—whether by simply depositing to earn interest or leveraging their deposits as collateral to borrow additional liquidity. Explore the full range of features and learn how to navigate this page with our step-by-step guides:

Lending (Deposit)

•[ How to Deposit](/radiant/project-info/markets/deposit/deposit)\ • [1-Click Loop & Lock](/radiant/project-info/markets/deposit/looping)\ •[ rTokens](/radiant/project-info/markets/deposit/rtokens)\ • [Withdraw assets](/radiant/project-info/markets/deposit/deposit-1)

Borrow

• [How to Borrow](/radiant/project-info/markets/borrow/borrow)\ • [Cross-Chain Borrows](/radiant/project-info/markets/borrow/cross-chain-borrows)\ • [Health Factor](/radiant/project-info/markets/borrow/borrow-1)\ •[ Loan Repayment](/radiant/project-info/markets/borrow/borrow-2)\ • [Liquidations](/radiant/project-info/markets/borrow/liquidations)\ •[ Flash Loans](/radiant/project-info/markets/borrow/flash-loans)\ •[ Interest Rate Model](/radiant/project-info/markets/borrow/interest-rate-model)

# Lending (Deposit) Provide liquidity to the market Lending, aka depositing assets on Radiant, can be a great way for users to earn interest, diversify crypto holdings, and manage risk exposure. {% content-ref url="/pages/siwPwrkEcm736ZzM2YUw" %} [How to Deposit](/radiant/project-info/markets/deposit/deposit) {% endcontent-ref %} {% content-ref url="/pages/20fYvh4Q9l0M9Ldnie3M" %} [1-Click Loop & Lock](/radiant/project-info/markets/deposit/looping) {% endcontent-ref %} {% content-ref url="/pages/6tegTfzpPE4PYlubGSn9" %} [rTokens](/radiant/project-info/markets/deposit/rtokens) {% endcontent-ref %} {% content-ref url="/pages/2SyHuqVsKvEFWKMrttWO" %} [Withdraw assets](/radiant/project-info/markets/deposit/deposit-1) {% endcontent-ref %} # How to Deposit Provide liquidity to the market From the **Markets** page, select the asset you wish to deposit.

Important note: Under the Deposit APY column are two numbers. The first is "Base Market Rate", the second is "Radiant Emissions" - which is only activated for those who supply Dynamic Liquidity.

This will initiate the **asset details** screen, then click "Deposit."

Select the desired deposit amount and click continue to submit your transaction. Once the transaction is confirmed, your deposit is successfully registered.

{% hint style="warning" %} Note that if you don’t have dLP locked to meet the eligibility criteria for RDNT emissions, the protocol will prompt you with the option to borrow ETH against your deposit. This will automatically create the dLP position and lock it for the default length. {% endhint %} {% hint style="info" %} The first deposit of an asset will require an additional one-time approval transaction. {% endhint %} ### Collateral After depositing an asset, you can determine whether or not to utilize it as collateral. A collateralized asset will activate your borrowing power but will be made available to be partially liquidated should your balance become insolvent (see [Liquidation](/radiant/project-info/markets/borrow/liquidations)). You can enable collateralization on the asset details page and the Dashboard.

All deposits are enabled as collateral by default. An opt-out option for each asset is available in the "Deposits" section on the **Dashboard** page. Simply toggle the "Collateral" button on the asset you prefer to withhold from use as collateral and confirm the transaction. # 1-Click Loop & Lock Leverage your Collateral Radiant Capital provides a loop & lock function that enables users to increase their collateral value by automating the deposit and borrow cycle multiple times. {% hint style="warning" %} The loop and lock function of Radiant may not execute if the selected leverage would cause your **health factor to drop below 1.11**. If the loop transaction fails to execute, lower your leverage using the sliding scale.\ \ Additionally, the loop & lock feature automatically ensures [dLP eligibility](/radiant/project-info/rdnt-tokenomics/liquidity-provisioning/eligibility). If a user is already eligible, zero ETH will be borrowed. As you can see in the video below, there will be zero ETH borrowed if a user is NOT required to add more dLP.
If a user is ineligible for RDNT emissions, the loop & lock tool will automatically borrow the ETH necessary to zap into a locked dLP position to maintain the minimum 5% dLP requirement for activating RDNT emissions. \ \ Slippage is set by default at 5% but can be customized from the zap section. \ Lastly, the dLP will be locked for your Default Locking Length, which can be updated under the [Manage page.](/radiant/project-info/manage-radiant) {% endhint %} {% embed url="" %} ### Unwind The **Unwind** feature provides a simple, one-click way to exit a loop strategy. Instead of manually reversing each step of the borrow-and-deposit cycle, Unwind bundles the process into a single transaction for convenience. When selected, the tool will automatically repay borrowed assets and withdraw collateral according to the position, mirroring the same mechanics of a manual unwind but without requiring multiple individual actions. Unwind is available within each market, offering an easier and faster way to manage or close leveraged positions alongside the Loop & Lock feature.

# rTokens {% hint style="info" %} rTokens are interest-bearing tokens represented as 'rXXXX' in your wallet (example: rUSDT for USDT). {% endhint %} rTokens are minted and burned upon deposit and withdrawal. The rTokens' value is pegged to the value of the corresponding deposited asset at a 1:1 ratio. All interest collected is distributed to rTokens holders directly by continuously increasing their wallet balance. If you wish to convert rTokens back to the underlying asset, navigate to your deposits on the **Dashboard** and follow the [withdrawal](/radiant/project-info/markets/deposit/deposit-1) prompts. The contract addresses for rTokens can be found [here.](/radiant/contracts-and-security/arbitrum-contracts) # Withdraw assets Remove your assets from the lending pools. To withdraw an asset, navigate to the **Dashboard** and select the asset you wish to withdraw.

This will initiate the **asset details** screen, then click "Withdraw."

Select the desired amount and submit the transaction. Be sure there is enough (unborrowed) liquidity in the protocol in order to withdraw. Should this not be the case, you would need to wait for more liquidity to be provided by depositors, or from borrowers repaying their loans for you to be able to withdraw the initial desired amount. You can withdraw your collateral-enabled assets, as long as: 1. Those funds are not actively being used to borrow against. 2. The withdrawal would not cause a liquidation on your loans. # Borrow Unlock your capital's full potential ## Borrowing vs. Selling **Selling** an asset involves closing the position on that particular token to free up liquid capital. If an individual is "long" on a particular asset, selling it would no longer entitle them to any potential upside on that asset's appreciation. Furthermore, in most countries, selling a position is treated as a taxable event. **Borrowing** enables one to obtain capital without selling the underlying asset or incurring a capital gains sales tax. {% content-ref url="/pages/73Pf0mZjtC6W59zvsRT0" %} [How to Borrow](/radiant/project-info/markets/borrow/borrow) {% endcontent-ref %} {% content-ref url="/pages/lxs9dzUbdpCYhRpH303G" %} [Health Factor](/radiant/project-info/markets/borrow/borrow-1) {% endcontent-ref %} {% content-ref url="/pages/osrk9EewCZz4LvVK47pG" %} [Loan Repayment](/radiant/project-info/markets/borrow/borrow-2) {% endcontent-ref %} {% content-ref url="/pages/4aTmmR9YD1Fg2Sss4Yx6" %} [Liquidations](/radiant/project-info/markets/borrow/liquidations) {% endcontent-ref %} {% content-ref url="/pages/WS0lpRkSKYL4u1UVgZWb" %} [Interest Rate Model](/radiant/project-info/markets/borrow/interest-rate-model) {% endcontent-ref %} # How to Borrow Unlock your capital's full potential Before borrowing, an asset must be [deposited](/radiant/project-info/markets/deposit) to be utilized as collateral. After providing collateral, visit the **Markets** section to view the borrowing availability and yields. Click on the asset you would like to borrow. On the **Reserve Status & Configuration** screen, click borrow. In the image below, for example, there are 32.54 ETH available to borrow (based on collateral deposited) against the supported assets.

Set the desired borrow amount based on your available collateral balance, and continue to confirm the transaction. Note that the more you elect to borrow, the greater the impact on your overall [Health Factor](#health-factor) (more on this below). ## Borrowing Eligibility The maximum amount available to borrow depends on the value of the collateral deposited, as well as the available liquidity for the asset. You won't be able to borrow an asset if there is not enough liquidity or if your [Health Factor](/radiant/project-info/markets/borrow/borrow-1) is too low. The **Loan-to-Value (LTV) ratio** represents the maximum borrowing power of specific collateral. For example, if a collateral has a LTV of 75%, the user can borrow up to 0.75 worth of ETH in the principal currency for every 1 ETH worth of collateral. This information can be found on any asset on the **Markets** page. # Cross-Chain Borrows Radiant Capital provides users with an innovative borrow & bridge function via the Stargate stable router interface. "Bridges built on the Delta (∆) algorithm \[of Layer Zero] conduct native asset transfers through unified pools of liquidity while achieving instant-guaranteed finality, the combination of which enables cross-chain composability." [*(Source: Layer Zero whitepaper)*](https://www.dropbox.com/s/gf3606jedromp61/Delta-Solving.The.Bridging-Trilemma.pdf?dl=0) The flexibility afforded by the ∆ algorithm creates the opportunity to improve many existing applications, such as decentralized lending protocols like Radiant Capital by taking advantage of single-transaction cross-chain swapping of native assets across vast networks of chains. Radiant v3 supports deposits on Arbitrum, BNB Chain, Base, and Ethereum and can be borrowed to any EVM chain supported by Stargate Finance. {% hint style="warning" %} Remember that while bridging, your deposits and borrows occur on the origin chain (Arbitrum/BNB/Ethereum). Therefore, if you wish to repay your loans, you must do so on those chains. {% endhint %} ### How to Borrow & Bridge Before borrowing & bridging, an asset must be deposited as collateral. After collateral has been provided, visit the Markets page and select the asset to be borrowed & bridged. Input the amount to borrow, select the destination chain, and click continue. If this is your first time using Radiant Capital to bridge, you will need to approve the contract to use the selected asset and approve delegation to bridge funds.

# Health Factor Protect your capital from liquidation The Health Factor is the numeric representation of the safety of your deposited assets weighted against any borrowed assets and their underlying value. The higher the Health Factor value is, the safer the state of your funds is against a potential [liquidation](/radiant/project-info/markets/borrow/liquidations). {% hint style="danger" %} If the Health Factor is reduced to 1 or lower, liquidation will be triggered. In a liquidation, up to 50% of the borrowing debt is repaid and that value plus the liquidation fee is taken from the collateral available. After a liquidation, that amount liquidated from your debt is repaid. {% endhint %} The Health Factor depends on the **liquidation threshold** of your collateral against the value of your borrowed funds. You can find the collateral parameters from the **Markets** page by selecting the desired asset to view the **Reserve Status & Configuration.** ## Health Factor Variability The Health Factor will increase or decrease depending on the fluctuation in the underlying token value of your deposits. For example, If you deposit BTC as collateral and use that to borrow USDC, should the value of BTC drop due to market conditions, the underlying value of your collateral will also decrease in accordance. This would negatively impact your Health Factor and increase the risk of liquidation. If you maintain a strong Health Factor, it affords you portfolio flexibility in two ways: 1. Decreased likelihood of liquidation, particularly when fluctuating assets are used as collateral (low-risk strategy) 2. Improves borrowing eligibility in order to leverage more collateral (high-risk strategy) # Loan Repayment There is no fixed time period to repay loans. As long as the position is safe, borrowing is for an undefined period. However, the fees owed on the loan will continue to accrue over time, decreasing the Health Factor (barring subsequent user intervention). This potentially could result in [liquidation](/radiant/project-info/markets/borrow/liquidations). Loans must be paid back with the same asset that was borrowed. For example, if 1 Ethereum is borrowed, 1 ETH must be repaid with fees accrued in order to repay the loan. To repay a loan, visit the **Dashboard**. Under the second column (Borrows), click on the asset you would like to repay. On the **Reserve Status & Configuration** screen, click repay. This will open up the Repay section for that particular asset, in which you can view your borrowed amount, wallet balance, and Health Factor. Select the amount of the loan you wish to repay, and click "Continue" to confirm the transaction.

# Liquidations ### Introduction A liquidation is a process that occurs when a borrower's [**Health Factor**](/radiant/project-info/markets/borrow/borrow-1) is reduced to 1 or lower due to their collateral value not properly covering their loan/debt value. This might happen when the collateralized asset decreases or the borrowed debt increases. ![](https://896179941-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fc8CwAEN8ihh81y90gyG1%2Fuploads%2FlOWUuBuXH2Xg5OxlMb8S%2FScreenshot%202024-07-22%20at%201.07.07%E2%80%AFPM.png?alt=media\&token=ccb0d4cd-607f-48f4-bd76-afdc6854c50d) To reduce the risk of liquidation, you can repay any outstanding loans or deposit additional collateral to increase your Health Factor. ### Liquidators Liquidators are advanced DeFi users that have developed automated systems (ie. bots) to monitor collateralized positions and seek out loans that are eligible for liquidation. These bots then interact with the protocol's L2Pool contract and initiate a `liquidationCall().` This enables Liquidators to pay back part of the debt owed and receive discounted collateral in return (also known as the liquidation bonus). This liquidation mechanism incentivizes third parties to participate in the health of the overall protocol by acting in their own interest (to receive the discounted collateral) and as a result, ensure that borrows are sufficiently collateralized across the protocol. **Liquidation Scenario** * Roger deposits 10 ETH and borrows 5 ETH worth of DAI * If Roger’s Health Factor drops below 1, his loan will be eligible for liquidation * A liquidator can repay up to 50% of a single borrowed amount (in this case, 2.5 ETH worth of DAI) * In return, the liquidator can claim a single collateral, which is ETH, at a 7.5% bonus * The liquidator claims 2.5 + 0.1875 ETH for repaying Roger's bad debt (2.5 ETH worth of DAI) * 0.1875 ETH is claimed by the protocol at a 7.5% bonus (15% total penalty) * After liquidation, Roger has 7.125 ETH (10-2.5-0.1875-0.1875 ETH) of supplied ETH collateral and 2.5 ETH worth of DAI borrowed. ### Liquidation Penalty & Risk Parameters The total liquidation penalty is 15%. Half of the penalty (7.5%) is allocated as a bonus to liquidators, while the other half is earmarked towards the Radiant Growth Fund, enabling the DAO to fund initiatives without having to sell RDNT tokens on the open market. Each asset within Radiant Capital has specific values related to its risk, which influences how they are supplied and borrowed. # Flash Loans Flash loans are a feature designed for developers due to the technical knowledge required to execute one. Flash Loans allow you to borrow any available assets without putting up any collateral as long as the liquidity returns to the protocol within one block transaction. In decentralized finance (DeFi), flash loans facilitate complex financial transactions. For example, a user might take out a flash loan to execute a trade on a decentralized exchange (DEX) or arbitrage between different DeFi protocols. Because flash loans are made available for such a short period, they come with a high level of risk. If the borrower cannot repay the loan within the allotted time frame, they may be required to pay a high penalty. Despite this risk, users execute flash loans because they offer a fast and convenient way to access large amounts of capital. You must build a contract requesting a Flash Loan. The contract will then need to execute the instructed steps and pay back the loan + interest and fees, all within the same transaction. To learn more, reference the flash loan procedure inherited from Aave within their[ documentation](https://docs.aave.com/developers/guides/flash-loans). ## No-Code Flash Loans [Furucombo](https://furucombo.app/) provides users the ability to use flash loans on Radiant. Please read their Medium article on Radiant for more details: # Interest Rate Model Mitigating liquidity risk through the borrow interest rate model ## Interest Rates (APY) & Utilization Radiant's interest rate algorithm is calibrated to manage liquidity risk and optimize utilization. The borrow interest rates are derived from the utilization rate U. U is an indicator of the availability of capital within the pool. The interest rate model manages liquidity risk in the protocol through user incentives to support liquidity: * When capital is available: low-interest rates to encourage borrowing * When capital is scarce: high-interest rates encourage debt repayments and additional supply of capital ## Interest Rate Model Liquidity risk materializes when utilization is high, and this becomes more problematic as U gets closer to 100%. To tailor the model to this constraint, the interest rate curve is split into two parts around an optimal utilization rate $$U\_{optimal}$$. Before $$U\_{optimal}$$the slope is small, after it begins rising sharply.

Since these aspects of the Radiant smart contracts are influenced by Aave, please refer to their documentation for further details of the interest rate model: {% embed url="" %} # RIZ Isolated Markets Radiant Isolated Zone Radiant Isolated Zone (RIZ) is Radiant's isolated lending infrastructure. Each market operates independently, with its own risk parameters, collateral asset, and loan asset. RIZ markets do not share liquidity with Core markets or with each other. Risk is fully contained within each market. ### How RIZ Markets Work Each market is defined by exactly two assets: | Role | Function | | -------------- | ------------------------------------------------------- | | **Collateral** | Deposited to back a borrow. Cannot be borrowed. | | **Loan asset** | Supplied to earn yield, or borrowed against collateral. | Markets are identified in the format **Collateral / Loan** throughout the app. > **Example:** In the GMX / USDC market, GMX is the collateral and USDC is the loan asset. You can deposit GMX to borrow USDC, or deposit USDC to earn supply yield. Each market has its own health factor, liquidation parameters, and interest rate, independent from all other markets. ### RIZ vs Core Markets Radiant runs two parallel lending architectures by design: | Feature | Core Markets | RIZ Markets | | ----------------------- | ------------------ | ---------------------------- | | Infrastructure | Aave-based | Morpho contract architecture | | Liquidity model | Shared pools | Fully isolated | | Cross-collateralization | Yes | No | | Asset scope | Blue-chip assets | Broader asset range | | Risk containment | Shared across pool | Per-market | The two systems are complementary. Core handles shared liquidity for established assets. RIZ handles isolated exposure for a wider range of assets without introducing systemic risk. ### Current Markets RIZ is currently live on Arbitrum. Deployments on Base, BNB Chain, and Ethereum Mainnet are being rolled out progressively. View all available markets in the app under **Isolated**. ### Coming from RIZ v1? RIZ v1 markets are being phased out. Most positions will need to be migrated manually to RIZ v2 or Core. {% content-ref url="/pages/Iuj8wmVUu60qeaFqV7p7" %} [Migrating from RIZ v1](/radiant/project-info/markets/riz-isolated-markets/migrating-from-riz-v1) {% endcontent-ref %} ### Get Started {% content-ref url="/pages/mt6wcwb7Yl6HId4r3JTp" %} [How to Use RIZ v2](/radiant/project-info/markets/riz-isolated-markets/how-to-use-riz-v2) {% endcontent-ref %} # How to Use RIZ v2 Radiant Isolated Zone RIZ v2 is Radiant's isolated lending infrastructure built on Morpho's contract architecture. Each market consists of exactly two assets: one **collateral** and one **loan asset**. These roles are fixed per market and clearly labeled in the UI. ### Navigating to Isolated Markets Access RIZ v2 by clicking **Isolated** in the top navigation bar.

The market list displays all available isolated pairs in the format **Collateral / Loan**, alongside: * **Deposit %** — current APY for supplying the loan asset * **Borrow %** — current APY for borrowing the loan asset * **Available Liquidity** — liquidity available to borrow * **Utilization Rate** — percentage of supplied liquidity currently borrowed Select a market to open its detail page.

### Understanding a Market Each market detail page shows two assets with distinct roles: | Label | Function | | -------------- | ------------------------------------------------------- | | **Collateral** | Deposited to back a borrow. Cannot be borrowed. | | **Loan asset** | Supplied to earn yield, or borrowed against collateral. |

> **Example:** In the syrupUSDC / USDC market: > > * syrupUSDC → Collateral only > * USDC → Loan asset (supply to earn, or borrow against syrupUSDC) Each market also shows its own **Health Factor**, **Your Supplies**, and **Your Borrows,** all scoped to that specific market. Positions in one RIZ market do not affect another. ### Deposit Click the **Deposit** tab inside a market. Use the dropdown to select which asset to deposit: * **Collateral asset** → to back a future borrow * **Loan asset** → to earn supply APY Enter the amount and click **Continue** to submit the transaction.

> If you deposit only the loan asset without collateral, you earn yield but cannot borrow from that market.

### Borrow To borrow, you must first have collateral deposited in the market. Click the **Borrow** tab, enter the amount of the loan asset you want to borrow, and click **Continue**. Your borrowing capacity is determined by the collateral amount and the market's **Max LTV** parameter, visible in the **Reserve Status & Configuration** section at the bottom of the market page. > Borrowing is only possible within the market where your collateral is deposited. Collateral in one RIZ market cannot be used to borrow from another market or from Core. ### Health Factor Each RIZ v2 market has its own isolated health factor.

The health factor reflects: * **Borrowing power used** — percentage of available credit used * **Current LTV** — ratio of debt to collateral value If the health factor drops below 1.0, the position becomes eligible for liquidation. ### Withdraw Click the **Withdraw** tab to remove supplied assets from a market.

> If you have an active borrow, withdrawing collateral will affect your health factor. Repay part or all of your borrow before withdrawing if needed. ### Repay Click the **Repay** tab to reduce or close an active borrow. Repaying in full restores full access to your collateral for withdrawal.

*** ### Reserve Status & Configuration At the bottom of each market page, the **Reserve Status & Configuration** panel shows parameters for each asset in the market. Toggle between **Collateral** and **Loan** asset views to see: | Parameter | Description | | ------------------------- | -------------------------------------------- | | **Max LTV** | Maximum loan-to-value ratio for borrowing | | **Liquidation threshold** | LTV at which liquidation becomes possible | | **Liquidation penalty** | Fee applied to collateral during liquidation | | **Collateral usage** | Whether the asset can be used as collateral | ### Coming from RIZ v1? If you have active positions in RIZ v1 markets, those markets are being phased out. Manual migration is required. {% content-ref url="/pages/Iuj8wmVUu60qeaFqV7p7" %} [Migrating from RIZ v1](/radiant/project-info/markets/riz-isolated-markets/migrating-from-riz-v1) {% endcontent-ref %} # Migrating from RIZ v1 RIZ v1 markets are being phased out as RIZ v2 launches. This page covers what's changing, which markets are affected, and what action you need to take. {% hint style="warning" icon="triangle-exclamation" %} **Migrations are not automatic. User action is required.** {% endhint %} ### Overview Depending on the asset, RIZ v1 markets are moving to one of two destinations: * **Core Markets** — high-performing assets graduate to Radiant's shared liquidity infrastructure * **RIZ v2** — remaining isolated markets migrate to the new Morpho-based architecture Some low-utilization markets will be deprecated without a direct migration path. ### What's Already Happened **rsETH (Arbitrum) and ezETH (Arbitrum)** have already migrated to Core Markets. If you had positions in these markets, you'll need to manually move them to Core. **PTwstETH (Arbitrum)** was sunset prior to the v2 migration. No migration path exists for this market. If you still have funds there, withdraw them now. ### Migration Plan by Chain #### Arbitrum | Asset | Destination | Notes | | -------- | ------------ | -------------------------------------- | | rsETH | Core Markets | ✅ Already live in Core | | ezETH | Core Markets | ✅ Already live in Core | | ZRO | RIZ v2 | Migration pending | | GMX | RIZ v2 | ✅ Already live in RIZ v2 | | gmARB | RIZ v2 | Migration pending | | USDY | RIZ v2 | Migration pending | | RDNT | RIZ v1 + v2 | Stays in v1 AND new v2 market created | | PTwstETH | Deprecated | ⚠️ Withdraw now. No migration planned. | #### Base | Asset | Destination | Notes | | ---------- | ----------- | ----------------- | | AERO | RIZ v2 | Migration pending | | ZRO | RIZ v2 | Migration pending | | MAVIA | RIZ v2 | Migration pending | | wSuperOETH | RIZ v2 | Migration pending | | BRETT | RIZ v2 | Migration pending | #### BNB Chain | Asset | Destination | Notes | | ------- | ----------- | ----------------- | | CAKE | RIZ v2 | Migration pending | | FLOKI | RIZ v2 | Migration pending | | slisBNB | RIZ v2 | Migration pending | ### What You Need to Do Markets do not migrate automatically. When a market is deprecated, you must move your position manually. **Step-by-step:** #### If you have an active borrow: 1. Go to the RIZ v1 market where you have the position

1. **Repay** your outstanding borrow in full (or enough to safely unwind) 2. **Withdraw** your collateral from the v1 market

1. Go to the corresponding Core or RIZ v2 market 2. **Deposit** your collateral into the new market 3. **Re-borrow** if desired, within the new market's parameters #### If you only have a deposit (no borrow): 1. Go to the RIZ v1 market 2. **Withdraw** your supplied assets 3. Go to the corresponding Core or RIZ v2 market 4. **Deposit** into the new market {% hint style="warning" %} **Before withdrawing**, check your health factor if you have an active borrow. Repay first to avoid liquidation risk. {% endhint %} ### Timeline RIZ v1 will remain accessible for **6 months** from the date of RIZ v2's launch (Arbitrum, March 2026). During this period: * Supply and borrow caps will be set to 0 (no new positions can be opened) * Existing positions remain accessible * Repays and withdrawals continue to function normally After the 6-month window, interaction will only be possible directly through the smart contracts. **Target deprecation: \~September 2026** {% hint style="info" %} You have time to plan. Don't wait until the last minute — manage your position when it suits you, not when you're forced to. {% endhint %} ### Special Cases **RDNT (Arbitrum)** RDNT will remain available in both RIZ v1 and a new RIZ v2 market. Users can choose where to position. No forced migration. **PTwstETH (Arbitrum)** This market was already sunset before the RIZ v2 launch. There is no migration path. Withdraw any remaining funds directly from the market or via the smart contract. ### Frequently Asked Questions **Will my position be liquidated if I don't migrate?** No. Existing positions in v1 remain valid during the 6-month window. However, caps will prevent new positions from being opened, and incentives will be reduced or removed. **Will RIZ v1 markets still earn RDNT emissions?** Emissions for most v1 markets on Arbitrum will be disabled once RIZ v2 launches. The RDNT/USDC market is an exception. **Can I migrate to a different asset than the one I held in v1?** You are withdrawing and re-depositing — you choose where to allocate. The migration plan above outlines where each v1 market has a corresponding destination. **When will v2 launch on Base, BNB, and Mainnet?** Deployments are in progress. Follow the announcements as each chain goes live. # RIZ Isolated Markets (deprecated) Radiant Innovation Zone - Isolated Markets ## Introduction Radiant Innovation Zone (RIZ) introduces isolated lending markets, allowing users to engage in borrowing and lending with distinct pairs of assets in separate, isolated pools. This innovative approach enhances risk management and offers increased flexibility compared to traditional shared liquidity pools. Within RIZ, different types of assets can be launched, each with its own parameters. This means there will be isolated pools with varying risk exposures, each independent from the others and the core markets. {% hint style="danger" %} The risk factor is usually associated with higher returns, compensating for the additional risk. Users must understand these risks and conduct thorough analyses before participating. {% endhint %} ### What are Isolated Markets? RIZ Markets are specialized lending pools where users can: * Supply a designated collateral asset. * Borrow the same asset, with the possibility of adding leverage (a process known as looping). * Borrow its counterpart. Each RIZ Market operates independently, enabling more accurate risk assessment and mitigation strategies. Despite this independence, these markets share a common vault system, USDC or WETH, which helps optimize yield and manage liquidity more efficiently. ### Key Features of RIZ Markets **Asset Specificity:** Each market is dedicated to a specific pair of assets, such as a stablecoin and a risky asset (e.g., PEPE, SHIB) or a volatile asset and a correlated risky asset (e.g., WETH and ETH-LRTs). **Oracle Router:** This new contract routes price requests to the correct Oracle. It currently supports Chainlink and Pyth Oracles, and more will be added. **Bad Debt Manager (BDM):** A contract deployed uniquely for each RIZ Market to socialize bad debt generated by significant events methodically. This mechanism prevents a rush to withdraw and ensures that users responsible for bad debt cannot participate in asset withdrawals, acting as a safeguard against bad debt accumulation. # How to Use RIZ You can easily navigate to the RIZ markets by switching from the Core section to the RIZ section. Once there, you'll see the available isolated markets.

## Deposit After choosing the RIZ market in which the user wants to participate, the asset details screen will initiate. Click "Deposit".

You will then be given a dropdown menu to choose one of the two assets from the pair you want to deposit.

After selecting the asset, enter the desired deposit amount and proceed by clicking "Continue" to submit your transaction. Once the transaction is confirmed, your deposit will be successfully registered. ## Borrow Once you have provided collateral in one of the two assets in a RIZ Market, you can take out a loan against it. Since each market is isolated, you will have two borrowing options: the same asset you deposited or the asset paired with your collateral. For instance, in a ZRO/USDC pool, you can deposit either ZRO or USDC and borrow either asset. The borrowing power is confined to the specific market where the collateral is deposited. This means that if you deposit collateral in the ZRO/USDC market, you can only borrow assets from that market and not from any other market, such as rsETH/WETH. ### **Health Factor** If you are unfamiliar with the concept of health factor, please refer to the respective section for a detailed explanation. {% content-ref url="/pages/lxs9dzUbdpCYhRpH303G" %} [Health Factor](/radiant/project-info/markets/borrow/borrow-1) {% endcontent-ref %} In the context of RIZ, the health factor is also isolated for each market. Therefore, each isolated market will have its own distinct health factor. You can consult the health factor directly from the RIZ market details page within the selected market:

Or from the dashboard page:

After depositing and borrowing, you can also withdraw your deposits or repay your loans. The processes for these actions are the same as in the core markets. For further details, refer to: {% content-ref url="/pages/2SyHuqVsKvEFWKMrttWO" %} [Withdraw assets](/radiant/project-info/markets/deposit/deposit-1) {% endcontent-ref %} {% content-ref url="/pages/osrk9EewCZz4LvVK47pG" %} [Loan Repayment](/radiant/project-info/markets/borrow/borrow-2) {% endcontent-ref %} # Dashboard On the Dashboard page, users can:\ 1\. Review a breakdown of their total rewards\ 2\. Review their health factor\ 3\. Review the composition of their deposits and borrows\ 4\. Deposit, withdrawal, borrow and repay assets {% content-ref url="/pages/oLnZETDt7LbYHttEkbSx" %} [Rewards Box](/radiant/project-info/dashboard/rewards-box) {% endcontent-ref %} {% content-ref url="/pages/SinJ7SKVSzmlsxzoS6ef" %} [Lending Box](/radiant/project-info/dashboard/lending-box) {% endcontent-ref %} {% content-ref url="/pages/w2ksbkUh1eLRYYL0t6hP" %} [Deposits and Borrows](/radiant/project-info/dashboard/deposits-and-borrows) {% endcontent-ref %} # Rewards Box This section shows a breakdown of a user's rewards for providing utility to the protocol.

### Daily RDNT Rewards * Definition: User projected amount of RDNT rewards based on current share of all dLP eligible lenders and borrowers ### Daily Protocol Rewards * Definition: User projected amount of daily rewards from protocol fees. ### Total Annual Rewards * Definition: User projected annual rewards, in USD terms, based on both RDNT rewards and Protocol fees: * Calculation: *(Projected user daily RDNT rewards \* 365) + (Projected user daily protocol fees \* 365)* # Lending Box {% embed url="" %} It is here where a user can review the breakdown of their deposited assets, borrowed assets, health factor and borrowing power. The Borrowing Power meter displays what percentage of a user's total borrowing capacity has been met. In the example above, 40.56% of the user's borrowing power has been utilized. # Deposits and Borrows In this section, users can see their deposits and borrows. They can also enable or disable deposits to be used as collateral. ### Core Markets overview

### RIZ Isolated Markets overview From the dashboard, users can also review their positions in RIZ markets. This section displays: * **Deposit Amount:** The total amount deposited in each RIZ market. * **Borrows:** The total amount borrowed against the deposited collateral. * **Health Factor:** A measure of the health of the user's position, reflecting the safety margin before liquidation. * **Borrow APY:** The borrowed assets' annual percentage yield (APY). * **LTV (Loan-to-Value):** The ratio of the borrowed amount to the value of the collateral. This comprehensive overview helps users monitor their positions and manage their risk effectively.

# Manage Radiant Platform Fee Management dashboard The **Manage Radiant** dashboard is where users can oversee the key components of their participation in the protocol: * **Dynamic Liquidity (dLP)** — View and manage your locked dLP positions, including lock duration, auto-relock settings, and redeemable balances. * **Platform Revenue** — Claim protocol fees distributed in blue-chip assets such as ETH, BTC, and stablecoins. * **Vesting RDNT** — Track RDNT rewards that are subject to vesting, exit early (with penalty), or withdraw tokens once the vesting period has been completed. {% content-ref url="/pages/KrQcjdLztCsW4X1dRhoL" %} [Dynamic Liquidity (dLP)](/radiant/project-info/manage-radiant/dlp) {% endcontent-ref %} {% content-ref url="/pages/aBmRI6Iuo9mu7F1jrfgq" %} [Platform Revenue](/radiant/project-info/manage-radiant/platform-revenue) {% endcontent-ref %} {% content-ref url="/pages/1RGBQfW1ZaIfZFcn0Xfs" %} [Vesting RDNT](/radiant/project-info/manage-radiant/vesting-rdnt) {% endcontent-ref %} # Dynamic Liquidity (dLP) Lock dLP, activate emissions! Dynamic Liquidity (dLP) is the mechanism that aligns long-term participants with the protocol by requiring users to lock liquidity in order to activate RDNT emissions and share in platform revenue. For a full explanation of what dLP is, its purpose, and rewards, see [What is dLP?](/radiant/project-info/rdnt-tokenomics/liquidity-provisioning/what-is-dlp). This section focuses on how to **interact with dLP from the Manage Radiant dashboard**, covering three main areas: {% content-ref url="/pages/ypvGcD8llzGIxXxDqzla" %} [How to lock dLP](/radiant/project-info/manage-radiant/dlp/how-to-lock-dlp) {% endcontent-ref %} {% content-ref url="/pages/rcOyIcTS5sdik0c1qb2Z" %} [dLP Overview](/radiant/project-info/manage-radiant/dlp/dlp-overview) {% endcontent-ref %} {% content-ref url="/pages/WIB8OEpW3ZmqUD6vDw1S" %} [dLP Stats](/radiant/project-info/manage-radiant/dlp/dlp-stats) {% endcontent-ref %} # How to lock dLP **Locked RDNT dLPs** share 60% of protocol revenue (Rest: 15% to OpEx, 15% to Remediation, 10% to the Guardian Fund). Locked dLP cannot be withdrawn prematurely. ### **Locked dLP (Radiant Liquidity)** Borrowers and lenders that lock dynamic liquidity tokens (dLP) are interacting and providing utility to the platform and thus can capture the added value from the communities’ engagement through the native token $RDNT. Borrowers and lenders that do not meet the 5% locked Radiant liquidity threshold would earn the base market rates but not RDNT emissions. By locking dLP (Radiant liquidity), ecosystem participants also receive [platform revenue](/radiant/project-info/manage-radiant/platform-revenue) from borrowing interest, flash loans, and liquidations that are claimable fees on the Manage Radiant page. By locking 15% dLP you become eligible for Radiant Guardian. ### **How to lock dLP** Before locking the dLP, you can use the [zap feature](/radiant/project-info/rdnt-tokenomics/liquidity-provisioning/zapping-dlp) to create the position with just a few clicks, saving time. To create dLP on Arbitrum, BNB, and Ethereum, you can also visit each respective host dLP protocol and create the LP token from there. You can find more information about this in the [dLP Liquidity Options.](/radiant/project-info/rdnt-tokenomics/liquidity-provisioning/liquidity-options) {% hint style="danger" %} Please take note that Base has a new dLP architecture based on Uniswap V3, designed to mimic an 80/20 ratio as used on other RDNT pools. Due to this, the only way to activate dLP on Base is through zapping via Radiant's front end. Do NOT create liquidity on Aerodrome, as you will not be able to earn protocol revenue or RDNT rewards. {% endhint %} To manually lock dLP, navigate to the **Manage Radiant** page. Under the "dLP overview" section, select the amount of dLP tokens to lock, and the lock length of one, three, six, or twelve months. Each length has a corresponding multiplier, based on a one-month lock (Locking for 12 months earns 25X platform revenue vs. one month!).

#### **Additional Notes** * Locked dLP is subject to a binding variable lock time (1 month to 1 year), which cannot be unlocked early. * If you do not select a default lock length, the lock duration will default to 1 month. * Each lock period has a different multiplier, ranging from 1x to 25x, depending on the lock duration chosen. * Fees generated from locked dLP can be claimed anytime with no penalty. * You will continue to receive fees during the entire lock period. * Platform fees are distributed linearly over a 7-day period. * If you choose to leave your locked RDNT in the protocol after the expiration date, you will be kicked from the locking pool by disqualification bounty hunters and forfeit the corresponding 7 days of streamed platform fees to the remaining dLP lockers in the pool. * To prevent disqualification, enable the [auto-relock](/radiant/project-info/manage-radiant/dlp/dlp-overview#pdf-page-i8jtiornpbdp1k07yqvv-auto-relock) function from the **Manage Radiant** page. # dLP Overview This section allows users to manage various actions related to their dLP positions. ### **Lock your dLP** Users can manually lock their dLP. For a detailed explanation, please click [here.](/radiant/project-info/manage-radiant/dlp/how-to-lock-dlp) ### **Default Lock Length** Users can select their desired default lock length, which will apply to all future auto-compounds unless changed. Longer lock periods receive a greater share of platform fees, with multipliers ranging from 1x to 25x, depending on the chosen duration.

**For calculations related to the APR calculations, go** [**here**](/radiant/project-info/rdnt-tokenomics/liquidity-provisioning/what-is-dlp#maximum-lock-apr)**.** ### **Auto Relock** Radiant platform banners will notify users when their lock expires. Expired locks will not receive platform fees and may affect RDNT emission eligibility within the money market.

To relock dLP, select "Relock dLP" from the redeemable locks section. The default lock length is set to one month (1x multiplier) unless an alternative default lock length has been set from the Manage page (as explained above). The "Auto-Relock" function is enabled by default to prevent users from losing platform fees and maintain eligibility for RDNT emissions. * To disable auto-relock, toggle the switch to the left and confirm the transaction in your wallet. * To enable auto-relock, toggle the switch to the right and confirm the transaction in your wallet. Auto-relocks will lock all expired dLP for the default lock length upon expiration.

### **Redeemable Locks** If auto-relock is not enabled, expired locks will appear in this section.

Users have two options: * **Relock:** Locks the dLP again for the default lock length already set. * **Withdraw:** Sends the dLP to the user’s wallet. Users must go to each [underlying protocol ](https://open.gitbook.com/~space/nid2aaGplWMFCWpNUeRM/~gitbook/pdf?back=false#pdf-page-hBk1P9T142vskswM2Twd)to remove their position to remove liquidity. # dLP Stats From the Manage Radiant page, view relevant statistics related to dLP.

**Your Locked dLP:** The fluctuating value of dLP caused by volatility on the underlying tokens- RDNT & ETH or RDNT & BNB. {% hint style="info" %} dLP USD Value = (TWAP(RDNT, 1 hr) \* rdntInLp) + (ethPrice \* ethInLp) / LP Supply {% endhint %} **dLP Locked (global):** The total value of all dLP locked on the selected blockchain. **Daily platform fees (global)**: The total platform fees vary daily based on the amount of borrowing interest, liquidations, and flash loan fees the protocol generates over a rolling 24hr period. Daily platform fees are distributed linearly over seven days. **Your share:** The percentage of global daily platform fees that is your share, based on your locked dLP in relation to the size of globally locked dLP. *Calculation: (User share of dLP \* user avg. dLP Multiplier) / (Total Protocol dLP \* Global Protocol avg. multiplier)* The average multiplier is based on the lock length selected each time you perform a lock/relock or zap/auto-compound into dLP. *Calculation:* *For example, User 1:* *- Total: 2 dLP locked / 13x Avg. Multiplier* *- 1 dLP Locked for 1 year (25x multiplier)* *- 1 dLP Locked for 1 month (1x multiplier)* **Total Annual Platform Fees:** Amount of projected protocol fees received by a user over 365 days, based on an extrapolated 24h sample of Global Protocol Fees *Calculation: (User Daily Protocol Fees \* 365)* **Your Current Lock APR: -** Definition: User Specific Lock APR depending on Avg. Multiplier *Calculation: (Global 1 month Locking APR \* User Avg Multiplier)* # Platform Revenue dLP rewards Locked dLPs are distributed claimable platform revenue viewable from the [**Manage Radiant**](/radiant/project-info/manage-radiant) page. After selecting "Claim All" and confirming the transaction, the claimed fees are now represented as rTokens in your wallet.

Convert them back into their underlying asset or continue to provide utility to the money market as a [lender](/radiant/project-info/markets/deposit). If you wish to convert them back to the underlying asset, navigate to your deposits on the **Dashboard** and follow the [withdrawal prompts](/radiant/project-info/markets/deposit/deposit-1). Borrowers repay loans using their deposited collateral. As they provide this utility to the Radiant ecosystem, their engagement with the protocol is dispersed to dLPs. Once claimed, these become your share of their deposited tokens, i.e., **rTokens**. {% hint style="info" %} rTokens are interest-bearing tokens represented as 'rXXXX' in your wallet (example: rUSDC for USDC). {% endhint %} # Auto-compound Automatically compound platform revenue into dLP Platform fees can be auto-compounded into dLP to increase the likelihood of [maintaining eligibility status.](/radiant/project-info/rdnt-tokenomics/liquidity-provisioning/eligibility) Auto-compounding occurs daily and can significantly increase dLP positions over time as [each future compound increases based on the previous compound](https://www.investopedia.com/terms/c/compounding.asp). #### How to Auto-compound Auto-compound is set ON by default after [RFP-28](https://snapshot.org/#/radiantcapital.eth/proposal/0x349c3a829823d5fb22a2e1a8e3a48c2a844b90a96680d9b262b932c0ee447088) ratification.

Setting your [default lock length](/radiant/project-info/manage-radiant/dlp/dlp-overview#pdf-page-i8jtiornpbdp1k07yqvv-default-lock-length) from the Manage Radiant page is important since it will apply to all future auto-compounds unless changed. If users want to turn off auto-compound, they can do it by toggling the button and confirming the transaction. Compound once instead of automatically by choosing the default lock length, then select "compound" and confirm the transaction in your wallet.

Additional notes * Auto-compounds occur every 24 hours, on average. * Auto-compounds require a minimum amount of platform revenue to execute, depending on gas costs per chain. * Compounded platform revenue is zapped into dLP. * 3% of the compounded amount is used to fund the bounty contract to award bounty hunters for decentralizing actions for the protocol. * Auto-compounds are staggered and do not occur globally simultaneously via the bounty system to prevent gamification. # Vesting RDNT {% hint style="success" %} Please note that this option is available only to users who meet the dLP eligibility criteria. {% endhint %} ## Overview For users participating in Radiant's money markets, vesting RDNT offers a unique opportunity to capitalize on the collective market engagement. By depositing assets and achieving dLP eligibility, users not only earn an APY% yield on their assets but also gain additional yields through RDNT emissions. The vesting of RDNT is governed by a structured approach. It includes a linearly decreasing penalty for early withdrawal, starting at 90% and reducing to 25% over a 90-day period. This incentivizes users to commit to the full vesting duration, ensuring they can fully benefit from the RDNT earned, mirroring their contribution to the platform's overall utility and success.

## Initiating RDNT Vesting To successfully vest RDNT and attain its full value, a 90-day maturation period is required. 1. **Starting the Vesting Process**: Access the 'Manage Radiant' page. Locate the 'Vesting Overview' panel. 2. **Eligibility Check**: If you haven't met the dLP eligibility, the 'Start vesting' button will be inactive. 3. **Activation**: Eligible users can click 'Start vesting'. Follow this by confirming the transaction in your wallet.

Post-activation, the 'Vesting Overview' panel offers various management functions to track and manage your vesting process. ### **Zap Vesting RDNT into dLP** Once RDNT is currently vesting, zap into locked dLP with no exit penalty to begin receiving platform revenue and attain eligibility for RDNT emissions from lending and borrowing. Under "currently vesting," select "Zap into dLP." The Zap with vesting Radiant modal will appear:

Note that the RDNT and ETH/BNB input fields will auto-populate. Zapping with vesting RDNT can only be executed for the full vesting amount. Therefore the ETH/BNB calculation (borrowed from the money market or paired from your wallet) is automatic based on the ratio required to form the liquidity token. After clicking continue, select the lock duration and corresponding multiplier, then click continue. Confirm the zapping information is accurate, and then click "Zap into dLP" to confirm the necessary transactions in your wallet. ### **Early Exit** Exit early for a penalty to receive RDNT immediately. Vests can be exited collectively for the penalty displayed under the "exit early" button below.

Alternatively, exit vests individually with their corresponding penalty amount by clicking the right arrow below on each vest you would like to exit. ### **Vest to Maturity** Vesting RDNT that has completed the 90-day maturation can be withdrawn for the full amount from the vested panel on the Manage Radiant page.

### **Additional Notes** * Exiting a vest early will incur a 25-90% penalty based on a linear schedule of elapsed time. * The penalty paid is returned at a ratio of 90% to the Radiant DAO Reserve to increase emissions runway, and 10% is allocated to the **Radiant Starfleet Treasury,** ratified in [RFP-11](https://dao.radiant.capital/#/proposal/0xd3e5c5fac34f40232b31477a841897e40893351bab0e5d92ee2bcd1b5c243ff6). * Initiating an "Exit Early" transaction from the "Currently vesting" panel will exit **all** separate vesting periods, with applicable penalties applied. * Alternatively, you may "exit early" from individual vests by using the menu on the vesting panel. * Initiating a "zap into dLP" transaction will zap **all** separate vesting periods. # Disqualification Bounties Radiant is introducing a function for users that meet the 5% dLP [eligibility threshold](/radiant/project-info/rdnt-tokenomics/liquidity-provisioning/eligibility) to disqualify ineligible users for a bounty, akin to running a liquidation bot, either directly through the UI or with searcher bots. A “bounty” is placed on the account equal to a *base bounty* that eligible dLPs can claim. Vigilant bounty hunters can monitor available disqualification bounties on the **Manage Radiant** page and disqualify ineligible users by selecting "claim" and confirming the transaction.

This disqualification system prevents expired dLP accounts from receiving ineligibly earned platform fees and prevents ineligible users from receiving $RDNT emissions that fall below the 5% dLP threshold. Additionally, bounty hunters receive a base bounty for relocking dLP for users that have enabled "auto-relock," and for performing [auto-compounds](broken://pages/UgozxREl5jTRdbbqFWTU) on behalf of users that have enabled this automation. This has the added benefit of further decentralizing actions taken on the protocol, allowing users to point and click to remove ineligible participants while benefiting the protocol (and themselves). To minimize the chance of disqualification, [maintain your eligibility status](/radiant/project-info/rdnt-tokenomics/liquidity-provisioning/eligibility) by increasing your dLP threshold above 5%. Expired locked dLP disqualifications can be prevented by toggling the “[auto-relock](broken://pages/KSTu8inie2hlxxoTzcN4)” function on the **Manage page** to continue receiving platform fees without interruption.

#### Additional Notes * Bounty hunters must maintain the 5% dLP threshold status and have deposited assets to claim bounties * Claimed bounties are paid in [Vesting RDNT](broken://pages/wVqGCF2wPTYjCt5gUFz6) * The base bounty is dynamic, depending on searcher bot demand and the price of $RDNT * Bounties are prioritized so that only one bounty per account is available at a time, although up to three bounty types exist: 1. Bounty priority is placed on expired lock treatment (remove expired locks from the pool or re-lock dLPs with auto-relock enabled) to prevent the account from continuing to receive ineligibly earned platform revenue. **The bounty for removing an expired lock is the base bounty** 2. The next bounty priority is preventing accounts from continuing to receive ineligibly earned RDNT emissions that fall below the 5% eligibility threshold. **The bounty for emissions ineligibility equals the base bounty** 3. The last bounty priority is for [auto-compounding](broken://pages/UgozxREl5jTRdbbqFWTU). When an auto-compound event is triggered, the protocol outsources the execution of the transaction to bounty hunters. AutoCompound bounties are funded by the fee paid by the user that will be compounded. This amount starts small and increases over time as they accrue more pending rewards that will be compounded * Self-disqualification: performing an on-chain action within the Dapp (deposit/claim/lock) will trigger a disqualification if the above parameters are detected.
# Riz Vault The RIZ Vault is designed to provide a centralized access point for depositing and withdrawing common assets across various RIZ Markets, aiming to achieve the best possible yield for those assets. ## **Key Features:** 1. **Universal Access Point**: The RIZ Vault allows users to deposit and withdraw assets like USDC or WETH across different RIZ Markets. 2. **ERC4626 Compliance**: The RIZ Vault adheres to the ERC4626 standard, ensuring compatibility with other DeFi applications. 3. **Yield Optimization**: The Radiant DAO manages the RIZ Vault's strategy and distributions off-chain to optimize yield for deposited assets. ## **Functionality:** * **Shared Liquidity Pools**: Although each RIZ Market operates as an independent liquidity pool, it shares its corresponding vaults (USDC/WETH or USDT), allowing for more efficient asset management and yield distribution. * **Simplified Participation**: The RIZ Vault simplifies user participation by offering a higher yield in exchange for a higher risk, compared to depositing assets in the core markets, which offer lower yields with less risk. ## **User Options:** 1. **Deposit into the Vault**: Users can choose to deposit their assets into the RIZ Vault, which allows them to receive the total yield available in the vault. Internally, the deposited assets are distributed across various liquidity pools based on predefined percentages, which the Radiant DAO can adjust. 2. **Direct Pool Deposits**: Alternatively, users can deposit assets directly into specific liquidity pools without using the vault. This option is ideal for users who want to target specific pools and receive the interest rate specific to those pools. For instance, a user who prefers rsETH over ezETH can deposit directly into the rsETH pool and earn the interest rate for that particular pool. {% hint style="warning" %} **Risk Considerations:** The risk associated with the RIZ Vault is an average exposure to all the assets that utilize the vault. This means that while users benefit from potentially higher yields, they also assume a proportionate share of the risks across all the participating liquidity pools. This balanced approach allows for a diversified risk-reward profile within the RIZ Markets. {% endhint %} # How to use the RIZ Vault Navigating to the RIZ Vault section allows you to deposit or withdraw liquidity from the available vaults.

## Deposit To deposit, select the vault into which you want to deposit liquidity from the drop-down list.

Enter the desired amount and confirm the transaction from your wallet.

Once the deposit is made, your balance will be updated in the "Your Overview" section, reflecting the amounts contributed to each vault.

In the "Distributions" section, users can check out how the deposited assets are distributed across different markets. The Radiant DAO manages these calculations off-chain to optimize yield.

## Withdraw To withdraw, navigate to the Manage Liquidity section and select the "Withdraw" tab.

Choose the asset you wish to withdraw and enter the desired amount.

Confirm the transaction in your wallet to complete the withdrawal process. # Radiant Guardian A DeFi first in combining real protection, real yield, and real composability {% hint style="info" %} For further information on the Guardian Fund: {% endhint %} {% hint style="info" %} The Guardian Fund draws conceptual inspiration from the **Aave Safety Module**, while introducing a vault-based and composable implementation tailored to Radiant. {% endhint %} Radiant Guardian represents a new security primitive in DeFi, the industry’s **first protocol-native, non-idle, decentralized, auto-remediating, and DeFi composable, institutional-grade reserve fund**. Ratified through community governance via [**RFP-52**](https://snapshot.box/#/s:radiantcapital.eth/proposal/0x8b69c2535698b6a93b383dcba4c84e4174e65a7b1535c6b66ccf2ae481d88b86), Guardian transforms the way capital protection and remediation are structured in decentralized finance. ### What is Radiant Guardian Guardian is a built-in economic safety net inside Radiant Capital that can be enabled by locking dLP. It is a fund + token mechanism that: * **Protects users’ deposits** if something bad (an exploit) happens. * **Makes that protection fund productive** rather than just sitting idle. * **Shares risk and reward** between people who want protection and people who supply capital to the protection fund. *** ### Key parts | Piece | What it is | What it does / why it exists | | -------------------------------- | ------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Guardian Fund** | The reserve pool where protection capital is stored (ETH, wstETH, RDNT, etc.) | It holds assets that can be used to remediate users when there is a qualifying exploit. It’s governed transparently by DAO rules. | | **dLP (DynamicLP)** | Liquidity provider tokens for RDNT/ETH or RDNT/BNB that users must lock. | If you lock a certain amount (≥15% of your deposited amount) in dLP, you become eligible for Guardian protection. | | **gLP (GuardianLP)** | An LP token you receive by putting ETH (or equivalent) into the Guardian Fund. | It represents a share of the protection fund. gLP earns yield (from protocol revenue, staking, etc.), but also takes on the slashing risk: if there’s remediation to users after an exploit, gLP holders may get “slashed” (lose some of their stake) to cover those losses. | | **Automatic Remediation Engine** | The logic / algorithm that triggers remediation. | If an exploit that’s “covered” occurs, users who locked enough dLP are automatically remediated from the Guardian Fund (proportionally). gLP holders share the cost. | *** ### How it works — step by step 1. **User wants protection**\ Alice deposits money (say ETH) into Radiant’s lending markets. To be eligible for Guardian’s protection, she also locks dLP tokens equivalent to ≥15% of her deposit. 2. **Capital supply for protection**\ Bob (a more risk-tolerant user) puts ETH into the Guardian Fund and receives gLP tokens. That ETH goes into the fund and is used in safe strategies to earn yield. 3. **Normal operation / earning yield**\ The assets in the Guardian Fund (via gLP capital) are not idle: they are used in conservative, low-risk strategies and also get a share of Radiant’s revenue (10%) to generate returns. Meanwhile, gLP is a token that can be used across DeFi. 4. **If a qualifying exploit happens**\ Suppose there is a hack or bad contract bug, and some users lose funds. * The Guardian *remediation engine* kicks in. * Alice, who had locked enough dLP, gets remediated from the Guardian Fund. The distribution s proportionate to her loss (capped at 100%). * To pay that, some portion of the Guardian Fund is used. As gLP holders had contributed capital, they share in that cost: i.e. their holdings are “slashed” (reduced) to cover part of those remediation. 5. **Balancing rewards and risk** * gLP holders are rewarded (yield, revenue shares) in “good times.” * But they take on risk: if an exploit happens, their funds can be partially used. * Users needing protection must lock dLP to qualify. Radiant Guardian effectively creates a **decentralized risk marketplace** where risk is transparently priced and rewarded. gLP holders act as the market’s underwriters, they supply capital to the Guardian Fund, earn yield for assuming risk, and may incur losses if a covered exploit occurs. This dynamic setup aligns incentives: users seeking protection contribute by locking dLP, while those willing to bear risk are compensated through gLP rewards. The result is an on-chain system that **accurately prices, shares, and rewards risk** across the Radiant ecosystem. *** ### Examples #### Example A: Small user + small exploit * **Alice** deposits **100 USDC** into Radiant’s markets. * She locks **15 USDC worth of dLP** (15% of 100) to be eligible for Radiant Guardian. * **Bob** deposits **10 USDC** into the Guardian Fund and mints gLP; this helps grow the fund with yield. * Later, a bug causes **Alice to lose 5 USDC in Radiant**. * The remediation engine automatically pays her **5 USDC** from the Guardian Fund. * That 5 USDC comes from the capital held by gLP holders like Bob, Bob’s gLP is reduced by some amount to cover this payout. #### Example B: Big exploit, partial coverage * **Charlie** deposits **200 ETH**, locks 30 ETH in dLP. * There is **100 ETH** in the Guardian Fund total (DAO depsoits + user deposits). * The Guardian Fund doesn't have enough capital to fully cover Charlies’ losses. * The system pays Charlie proportionally (50% of their loss) **100 ETH**. * In other words, Guardian doesn’t guarantee **full** coverage beyond what the fund can afford. * gLP holders take the hit: part of their capital is used (slashed) to pay the partial remediation. #### Example C: Good times, yields * There is no exploit. The Guardian Fund is growing via yield strategies, plus Radiant gives 10% of protocol revenue to the fund. * Bob, holding gLP, receives returns. His gLP is stable or growing. * Alice keeps her deposit safe (no exploit), because there was no need for remediation. *** ### Why Radiant Guardian is different * **Traditional safety funds**: many protocols set aside capital (reserves) but those funds sit idle (not doing anything) until disaster strikes. Radiant Guardian makes those funds **active**, earning yield. * **User-first protection**: instead of just protecting the protocol, this system aims to protect **individual users’ deposits**. * **Incentive alignment**: those who supply to the protection fund (gLP holders) are rewarded for risk, and those who want protection (depositors) must also show commitment (via dLP locking). * **DeFi Composability**: gLP is a standard DeFi token, meaning it can be used across DeFi (as collateral, liquidity, etc.), it doesn’t just sit in the fund unused. ## **GuardianLP (gLP)** Core Design Guardian introduces a yield-bearing token, the **GuardianLP (gLP),** as the backbone of Radiant’s economic security framework. Unlike traditional reserve pools that remain idle until triggered, Guardian actively deploys its reserves into low-risk strategies to generate sustainable yield while maintaining instant liquidity for emergency exploit-related remediation ([source](https://medium.com/@RadiantCapital/radiant-guardian-defi-security-reimagined-47a1c6980c48)). **Key properties**: * **Non-Idle Capital** — By holding gLP, the reserves earn yield instead of sitting dormant (10% from protocol revenue + native yield of base asset/s + RDNT emissions) * **Auto-Remediation** — user remediation is automatically triggered based on community-governed policies and algorithms. * **DeFi Composable** — ERC-20 compatible, gLP integrates with DeFi ecosystems as collateral, liquidity, and settlement layers, starting with Radiant's own Isolated RIZ (Radiant Innovation Zone) Markets. * **Institutional-Grade** — built with transparency, on-chain auditability, and governance-aligned parameters

## Governance Alignment Guardian’s parameters — such as protection scope, capital deployment strategies, and remediation mechanics — are controlled by the DAO, ensuring **community-aligned security guarantees**. This design turns risk management from a passive promise into an **active, protocol-native treasury function** ([source](https://medium.com/@RadiantCapital/radiant-guardian-defi-security-reimagined-47a1c6980c48)). ## Strategic Significance * **First in DeFi:** Guardian is the first decentralized framework to blend coverage with capital efficiency. * **Resilience:** Protects users while reinforcing Radiant’s long-term protocol sustainability. * **Institutional On-Ramp:** By aligning real yield and automatic user protection, Guardian opens the door for institutional participants seeking **real protection**, **real yield**, and **real composability**. ## Contracts `GLPVault: 0xc0E823Efcef47aeB0CA4b1362C6c8Db582d04078`\ `GLPStrategy: 0xB0fF86c7eBe95DcBf106178A82B57dd0A1a053d7`\ `OracleRouter: 0x8e9554649863108F6f87eCf959D2F69618827118`\ `RDNT/WETH Inverse Oracle: 0x04bFea605e8615aE42cB8d8FffAD78f113686681` ## References * [Radiant Guardian: DeFi Security Reimagined (Medium)](https://medium.com/@RadiantCapital/radiant-guardian-defi-security-reimagined-47a1c6980c48) * [RFP-52: Establishing the Radiant Guardian Fund (Snapshot)](https://snapshot.box/#/s:radiantcapital.eth/proposal/0x8b69c2535698b6a93b383dcba4c84e4174e65a7b1535c6b66ccf2ae481d88b86) # GuardianLP (gLP) {% hint style="info" %} **GuardianLP** (**gLP**) is only available on Arbitrum but protects depositors on all chains. {% endhint %} {% hint style="info" %} The Guardian Fund draws conceptual inspiration from the **Aave Safety Module**, while introducing a vault-based and composable implementation tailored to Radiant. {% endhint %} **GuardianLP** (**gLP**) is the ERC-4626 vault share token that represents ownership of assets held in the **Radiant Guardian Fund**. gLP tokenizes capital deposited into the Guardian multisig and enables productive, composable, and slashable security capital for the Radiant protocol. gLP holders provide the capital that backs user remediation in the event of covered exploits, and are compensated through yield generated at the Guardian Fund level. *** ### Overview * **Token Type:** ERC-4626 * **Role:** Represents proportional ownership of assets held in the Guardian multisig * **Issued By:** Guardian Vault contract * **Redeemable For:** Underlying assets (e.g. ETH) at the current gLP price * **Risk Profile:** Yield-bearing, subject to slashing during remediation events *** ### Architecture Guardian consists of two core components: #### 1. Guardian Multisig * A multisignature wallet controlled by DAO signers. * Holds the actual assets backing the Guardian Fund (e.g. ETH, RDNT, wstETH). * Assets in the multisig are the source of both **yield accrual** and **remediation payouts**. #### 2. Guardian Vault (Wrapper Contract) * A smart contract that sits **around** the multisig. * Handles all user interactions (deposits, withdrawals). * Tracks the **total USD value** of assets held in the multisig. * Mints and burns gLP shares to reflect ownership. Users never interact with the multisig directly, all interactions flow through the Vault. *** ### How gLP Works #### Deposits (Minting gLP) 1. User deposits ETH into the **Guardian Vault**. 2. The Vault forwards ETH to the **Guardian multisig**. 3. The Vault mints **gLP** to the user, proportional to the deposited value. *** #### Withdrawals (Burning gLP) 1. User redeems gLP through the **Guardian Vault**. 2. The Vault calculates the user’s share based on the current gLP price. 3. Assets are withdrawn from the multisig. 4. ETH is sent to the user. 5. The Vault burns the redeemed gLP. Users receive their **principal plus any accrued yield**, minus any slashing that may have occurred. *** ### gLP Pricing gLP has an intrinsic, on-chain price derived directly from the Guardian Fund: ``` gLP Price = Total Value of Assets in Multisig / Total gLP Supply ``` * If assets in the multisig increase while gLP supply stays constant → **gLP price increases** * If assets decrease (e.g. remediation payouts) → **gLP price decreases** Because pricing is native to the vault, **no external oracle or price feed is required**. *** ### Yield Accrual gLP is yield-bearing by design. Yield is generated by **adding new assets to the Guardian multisig**, such as: * A percentage (10%) of Radiant protocol revenue * RDNT emissions or incentives * Other approved inflows No new gLP is minted when yield is added. Instead, yield is **baked into the gLP price**, meaning: * gLP appreciates over time * Yield is realized automatically upon redemption *** ### Slashing & Risk gLP is **explicitly subject to slashing**. In the event of a covered exploit or remediation event: * Assets are transferred **out of the Guardian multisig** to affected users * The total asset value of the fund decreases * The **price of gLP declines proportionally** This means: * gLP holders absorb losses * Risk is socialized among Guardian Fund capital providers * Users with Guardian protection can be remediated gLP holders are compensated for this risk through yield. *** ### DeFi Composability gLP is fully composable across DeFi: * **ERC-20 compliant** → compatible with wallets, DEXs, and protocols * **Vault-native pricing** → no external oracle required * Can be used as: * Collateral in isolated markets * A building block for structured products * A yield-bearing, risk-aware asset in DeFi strategies *** ### Summary gLP is the tokenized backbone of the Radiant Guardian system: * Represents ownership of Guardian Fund assets * Earns yield through protocol-level inflows * Is slashable to enable trust-minimized remediation * Is composable, transparent, and DAO-aligned By holding gLP, users actively provide economic security to the Radiant protocol in exchange for yield. # Scope of Coverage The Guardian Fund is designed to provide protocol-native remediation for a defined set of adverse events that may impact users of Radiant Capital. This page outlines the categories of events that may be eligible for coverage, the scope of protection, and important limitations. The Guardian Fund is intended to mitigate **protocol-level risks**, not individual user errors or market-driven losses. Coverage applies to **Core Markets, RIZ Isolated Markets, Vaults, Strategies**, however explicitly excludes RIZ isolated markets in some categories. Covered events generally fall into the categories below. *** ### Smart Contract Exploits and Hacks #### Description Smart contract exploits refer to unintended vulnerabilities or logic flaws in Radiant protocol smart contracts that result in loss of user funds. Examples include: * Re-entrancy vulnerabilities * Incorrect accounting or rounding errors * Permission or access control failures * Faulty upgrade or initialization logic * Exploits arising from unexpected contract interactions #### Coverage Intent If a verified exploit of Radiant Core contracts results in user fund loss, the Guardian Fund may be used to remediate affected users. #### Exclusions * Exploits in third-party protocols integrated by Radiant * Exploits in dependencies widely used across the industry * User-deployed vaults or custom strategies * Known risks disclosed prior to the event *** ### Severe Oracle Failures or Manipulation #### Description Oracle failures occur when price feeds used by the protocol provide incorrect, delayed, or manipulated data that materially impacts protocol operations. Examples include: * Manipulation of on-chain price sources * Incorrect asset pricing due to feed configuration errors * Cross-market price desynchronization #### Coverage Intent If an oracle failure directly causes incorrect liquidations, bad debt, or user losses, the Guardian Fund may be used for remediation. #### Exclusions * Normal price volatility * Extreme oracle latency or downtime * Temporary oracle deviations that self-correct without loss * Oracle issues in RIZ isolated markets, other than Chainlink or Pyth *** ### Custodian Risks and Operational Failures #### Description Custodian risks relate to failures or compromises involving protocol-controlled infrastructure or privileged actors. Examples include: * Compromise of Radiant contributor wallets * Key mismanagement or signer compromise * Failures in DAO-controlled operational systems * Multisig execution errors #### Coverage Intent If such failures result in direct loss of user funds, the Guardian Fund may be used to remediate affected users. #### Exclusions * Losses caused by individual user wallet compromise * Losses caused by incorrect approvals * Social engineering or phishing targeting users *** ### Liquidation Failures (Core Markets Only) #### Description Liquidation failures occur when the protocol’s liquidation mechanisms fail to operate as intended during periods of market stress. Examples include: * Insufficient liquidator participation * Network congestion preventing timely liquidations * Incorrect liquidation parameters * Liquidation logic failures #### Coverage Intent If liquidation failures in Core Markets result in systemic losses or unfair user impact, the Guardian Fund may be used to remediate affected positions. #### Exclusions * Liquidation failures in RIZ isolated markets * Losses due to extreme but expected market volatility (such as delistings) *** ### Bad Debt (Core Markets Only) #### Description Bad debt arises when borrower positions cannot be liquidated profitably, resulting in a shortfall that impacts lenders or the protocol. Examples include: * Rapid price collapses exceeding liquidation thresholds * Failed or partial liquidations #### Coverage Intent The Guardian Fund may be used to cover protocol-level bad debt in Core Markets to protect lenders and maintain market solvency. #### Exclusions * Bad debt in RIZ isolated markets *** ### Covered vs Not Covered | Category | Covered | Not Covered | | ----------------------------------- | ------- | -------------------- | | Smart contract exploits | ✅ | — | | Oracle manipulation | ✅ | — | | Custodian / signer compromise | ✅ | — | | Liquidation failures | ✅ | RIZ isolated markets | | Bad debt | ✅ | RIZ isolated markets | | User error or misuse | — | ❌ | | Market volatility / price movements | — | ❌ | | Third-party protocol failures | — | ❌ | | Dependencies | — | ❌ | | Impermanent loss | — | ❌ | | MEV or gas-related losses | — | ❌ | *** ### Severity Thresholds & Partial Coverage The Guardian Fund is designed to respond to **material protocol-level incidents** rather than minor or transient issues. #### Severity Thresholds Coverage eligibility generally depends on factors such as: * The magnitude of user losses * Whether the event results in protocol insolvency or systemic risk * The number of affected users * Whether normal protocol mechanisms can self-correct the issue Minor incidents that do not threaten protocol solvency or materially impact users may not trigger Guardian Fund remediation. #### Partial Coverage In some cases, remediation may be **partial rather than full**, depending on: * Available assets in the Guardian Fund * The scale of losses relative to fund capacity * Governance-approved payout limits * Risk parameters in effect at the time of the event Partial remediation distributes available capital in the Guardian Fund proportionally among eligible users. Any remediation event results in a corresponding reduction in Guardian Fund assets and gLP value. **Numerical Examples** **Example 1: Full Coverage** * Total Guardian Fund assets: $1M * Eligible user losses: $200k * Outcome: Users are fully remediated. Guardian Fund assets decrease to $800k. gLP price declines proportionally via slashing. **Example 2: Partial Coverage** * Total Guardian Fund assets: $1M * Eligible user losses: $2M * Outcome: 50% of losses are remediated pro-rata. Guardian Fund assets are fully depleted. gLP holders fully absorb the loss via slashing. *** #### Hard vs Soft Triggers Covered events may trigger remediation through either **hard (automatic)** or **soft (governance-reviewed)** processes. **Hard Triggers (Automatic)** Hard triggers are predefined, objective conditions that may automatically initiate remediation logic, such as: * Verified smart contract exploit in Radiant Core contracts * Deterministic oracle failure with measurable loss impact * Critical liquidation mechanism failure Hard triggers are designed to minimize response time and reduce governance overhead during emergencies. **Soft Triggers (Governance-Reviewed)** Soft triggers require explicit review and approval by the Radiant DAO governance framework. Examples include: * Custodian or signer compromise * Cross-chain infrastructure failures * Ambiguous or multi-causal loss events Soft triggers allow for contextual assessment, forensic analysis, and tailored remediation decisions. *** ### Events Explicitly Not Covered The Guardian Fund does **not** provide coverage for: * User error (incorrect transactions, leverage misuse) * Market risk or asset price volatility * Impermanent loss * Some losses in RIZ isolated markets * Third-party protocol failures unrelated to Radiant * Third-party dependencies widely used by the industry * Gas fee losses or MEV-related effects *** ### Remediation Process (High-Level) 1. Event detection and incident analysis 2. Scope and impact assessment 3. Automated or DAO-approved remediation decision 4. Distribution of assets from the Guardian Fund 5. Corresponding gLP slashing Remediation amounts are partial and subject to Guardian Fund capacity. *** ### Important Notes * Coverage is **best-effort**, not guaranteed. * The Guardian Fund does not constitute insurance. * All coverage decisions are ultimately governed by Radiant DAO processes # Connecting to Radiant ## Add the Arbitrum One Network to MetaMask Arbitrum is an EVM-compatible chain, meaning it can easily work with MetaMask, as well as most browser-based wallets. Click on the network drop-down menu, and select "Add Network" from the bottom. Add in the following details: RPC: Chain ID: `42161` Symbol: `ETH` Explorer: ![](https://content.gitbook.com/content/c8CwAEN8ihh81y90gyG1/blobs/dUCQEGtBK8nt1ICa05kE/image.png)

Alternative Shortcut:

Visit [Chainlist](https://chainlist.org/chain/42161), connect your wallet to the site, and click the "Add Chain" button.

## Add the BNB Chain Network to Metamask The Base chain is an EVM-compatible chain meaning it can easily run with MetaMask. The first step of this tutorial is to set up a different Base network on Metamask. Open Metamask, click on the Network you're currently on, then click on Add Network. Input the details below: RPC: [https://bsc-dataseed.binance.org/](< https://bsc-dataseed.binance.org/>) Chain ID: `56` Symbol: `BNB` Explorer:

Alternative Shortcut:

Visit [Chainlist](https://chainlist.org/chain/56), connect your wallet to the site, and click the "Add Chain" button.

## Add the Ethereum Network to Metamask Ethereum is already included as the default network in MetaMask, so you don’t need to add it manually. When you first install MetaMask, you’ll see Ethereum Mainnet as the pre-selected network at the top of the wallet. If you ever switch away, you can return to it by opening the network drop-down and selecting **Ethereum Mainnet**. RPC: Chain ID: `1` Symbol: `ETH` Explorer:

Alternative Shortcut:

Visit [Chainlist](https://chainlist.wtf/), connect your wallet to the site, and click the "Add Chain" button.

## Add the Base Network to Metamask The Base chain is an EVM-compatible chain meaning it can easily run with MetaMask. The first step of this tutorial is to set up a different Base network on Metamask. Open Metamask, click on the Network you're currently on, then click on Add Network. Input the details below: RPC: Chain ID: `8453` Symbol: `ETH` Explorer:

Alternative Shortcut:

Visit [Chainlist](https://chainlist.org/chain/8453), connect your wallet to the site and click the "Add Chain" button.

## Bridging to/from Arbitrum/BNB The Radiant DAO recommends [Stargate Finance](https://stargate.finance/) due to its deep liquidity reserves and user interface. However, [Multichain](https://app.multichain.org/#/router), [Celer Bridge](https://cbridge.celer.network/#/transfer), and [Synapse Protocol](https://synapseprotocol.com/?inputCurrency=USDC\&outputCurrency=USDC\&outputChain=10) are excellent options. ## Acquiring $RDNT The $RDNT token is widely available across numerous decentralized and centralized exchanges. * [Uniswap](https://app.uniswap.org/#/swap) * [1inch](https://app.1inch.io/) * [Sushi](https://app.sushi.com/swap?chainId=42161) * [DefiLlama](https://swap.defillama.com/) Centralized exchanges: * [Kucoin](https://www.kucoin.com/price/RDNT) * [Huobi](https://www.huobi.com/en-us/exchange/rdnt_usdt/) * [Bybit](https://www.bybit.com/en-US/trade/spot/RDNT/USDT) * [MexC](https://www.mexc.com/exchange/RDNT_USDT?_from=search_spot_trade) * [OKX](https://www.okx.com/trade-spot/rdnt-usdt) * [Gate.io](https://www.gate.io/zh/trade/RDNT_USDT) ## Acquiring ETH Because Arbitrum was designed as a Layer 2 to exist on top of the Ethereum Network (and uses ETH for its on-chain native token), almost all of the well-established DEXes support trading over Arbitrum. Some commonly-used options include: * [Uniswap](https://app.uniswap.org/#/swap) * [1inch](https://app.1inch.io/) * [Sushi](https://app.sushi.com/swap?chainId=42161) * [DefiLlama](https://swap.defillama.com/) ## Acquiring BNB Radiant dLPs on Binance Chain require pairing $RDNT with BNB coin. BNB was created as a utility token for discounted trading fees in 2017, but its uses have expanded to numerous applications, including payments for transaction fees. You may acquire BNB via: * [Pancakeswap](https://pancakeswap.finance/) * [Ellipsis](https://ellipsis.finance/) * [1inch](https://app.1inch.io/) * [DefiLlama](https://swap.defillama.com/) # Migrating RDNT v1 to v2 Radiant v1 officially **sunset on October 30, 2024**, following the ratification of [**RFP-43**](https://snapshot.box/#/s:radiantcapital.eth/proposal/0x726387faef57c08ae9a64dd6cbdbaa1e795d9d5a77ee347497c159409352b64b). From that date forward, the v1 frontend became inaccessible. Any interaction with v1 contracts must now be done through **direct smart contract interaction**. The migration wizard created for the transition has been **deprecated and is no longer funded**. As a result, the only available method to migrate v1 RDNT to the current version is via SushiSwap or any other available pool: 1. **Swap v1 RDNT → WETH**: 2. **Swap WETH → v2 RDNT**: #### Relevant Contract Addresses * **v1 RDNT**: `0x0C4681e6C0235179ec3D4F4fc4DF3d14FDD96017` * **v2 RDNT**: `0x3082CC23568eA640225c2467653dB90e9250AaA0` After migrating to v2 RDNT, users should confirm that no funds remain in v1 money markets. Any remaining balances must be withdrawn manually ([Withdraw v1 Funds Guide](/radiant/navigation/withdrawing-funds-from-v1)). # Withdrawing funds from v1 Although Radiant v1 has been sunset, it is still possible to withdraw funds directly from the contracts. This guide explains how to check if you have remaining deposits and how to withdraw them manually. ### Withdrawing deposits #### 1. Check for Remaining Deposits * Visit the [Radiant Migration Page](https://app.radiant.capital/#/migration?step=3). {% hint style="info" %} This page is now view-only and serves for informational purposes only. {% endhint %} * Alternatively, you can use third-party explorers such as [Debank](https://debank.com/) to verify if you still have open positions. {% hint style="warning" %} **Note**: Before withdrawing, ensure that you have **no active borrow positions**. If you do, you must [repay the loan first.](#rapaying-a-loan) {% endhint %} #### 2. Access the v1 Lending Contract You can interact with the contract directly on Arbiscan or via a user-friendly ABI explorer: * [Arbiscan Write Contract](https://arbiscan.io/address/0x2032b9a8e9f7e76768ca9271003d3e43e1616b1f#writeProxyContract#F15) * [ABI Ninja (recommended)](https://abi.ninja/0x2032b9A8e9F7e76768CA9271003d3e43E1616B1F/42161?methods=withdraw) #### 3. Fill in the Required Parameters When calling the **withdraw** function, complete the fields as follows: * **i. Asset Address** – The underlying asset you want to withdraw: * WBTC: `0x2f2a2543B76A4166549F7aaB2e75Bef0aefC5B0f` * WETH: `0x82aF49447D8a07e3bd95BD0d56f35241523fBab1` * USDT: `0xFd086bC7CD5C481DCC9C85ebE478A1C0b69FCbb9` * USDC.e: `0xFF970A61A04b1cA14834A43f5dE4533eBDDB5CC8` * DAI: `0xDA10009cBd5D07dd0CeCc66161FC93D7c9000da1` * **ii. Amount** – The quantity to withdraw (in `uint256`).\ To determine the exact amount: 1. Check your balance via the rToken contract corresponding to your asset. Use the `balanceOf` method (`Read Function #10`) with your wallet address. rToken contract links: * [WBTC rToken](https://arbiscan.io/address/0x4cd44e6fcfa68bf797c65889c74b26b8c2e5d4d3#readProxyContract#F10) * [USDT rToken](https://arbiscan.io/address/0xef47ccc71ec8941b67dc679d1a5f78facfd0ec3c#readProxyContract#F10) * [USDC rToken](https://arbiscan.io/address/0x805ba50001779ced4f59cff63aea527d12b94829#readProxyContract#F10) * [DAI rToken](https://arbiscan.io/address/0x5293c6ca56b8941040b8d18f557dfa82cf520216#readProxyContract#F10) * [WETH rToken](https://arbiscan.io/address/0x15b53d277af860f51c3e6843f8075007026bbb3a#readProxyContract#F10)

Copy the balance value and paste it into the **amount** field in ABI Ninja or Arbiscan. * **iii. To Address** – Your wallet address.

#### 4. Execute the Transaction * Click **Send** to execute the withdrawal. * Sign and confirm the transaction with the same wallet address that originally deposited the funds. {% hint style="warning" %} If you use a different address, the transaction will fail. {% endhint %} Once executed, the withdrawn asset will appear in your wallet. *** ### Rapaying a loan If you have an **active borrow** in v1, you must fully repay it before you can withdraw your collateral.

#### 1. Verify Your Borrow Position * Visit the [Radiant Migration Page](https://app.radiant.capital/#/migration?step=3) to check if you still have borrowed assets. * Example: In the screenshot above, the user borrowed **51.6814 USDC (Bridged)** against supplied collateral. #### 2. Ensure You Hold the Borrowed Asset Make sure your wallet has enough of the borrowed asset to cover your outstanding debt. For example, if you borrowed USDC.e, you must hold the same amount of USDC.e in your wallet before proceeding. #### 3. Access the v1 Lending Contract You can interact directly with the v1 contract on: * [Arbiscan Write Contract](https://arbiscan.io/address/0x2032b9a8e9f7e76768ca9271003d3e43e1616b1f#writeProxyContract#F9) * [ABI Ninja (recommended)](https://abi.ninja/0x2032b9A8e9F7e76768CA9271003d3e43E1616B1F/42161?methods=repay) Look for the **repay** function. #### 4. Fill in the Required Parameters When calling the **repay** function, complete the following fields: * **i. Asset Address** — The asset you borrowed and are repaying: * WBTC: `0x2f2a2543B76A4166549F7aaB2e75Bef0aefC5B0f` * WETH: `0x82aF49447D8a07e3bd95BD0d56f35241523fBab1` * USDT: `0xFd086bC7CD5C481DCC9C85ebE478A1C0b69FCbb9` * USDC.e: `0xFF970A61A04b1cA14834A43f5dE4533eBDDB5CC8` * DAI: `0xDA10009cBd5D07dd0CeCc66161FC93D7c9000da1` * **ii. Amount** — The amount of debt to repay (in `uint256`).\ To check your exact borrow amount, use the **vdToken contract** for your asset and call the `balanceOf` method (`Read Function #10`) with your wallet address: * [vdWBTC](https://arbiscan.io/address/0x0e16bae17c61789d8a96ea6529d788b633c4c8b6#readProxyContract#F5) * [vdUSDT](https://arbiscan.io/address/0x9c3a8644a9ca181b90094be98dc19496f6b38a24#readProxyContract#F5) * [vdUSDC.e](https://arbiscan.io/address/0xf92d501e74bd1e4308e6676c38ab4d84389d7bf3#readProxyContract#F5) * [vdDAI](https://arbiscan.io/address/0x2e9b46867469350e4889c280f74bfa55ca44fcd4#readProxyContract#F5) * [vdWETH](https://arbiscan.io/address/0x4e75d4bc81d9ad1a1abc972a3dd53d581e1ce16b#readProxyContract#F5)

* **iii. Rate Mode** — The interest rate mode of your debt: * `1` = Stable * `2` = Variable *Note: Most positions in Radiant v1 were taken with variable rate (`2`). If you are unsure which mode applies to your borrow, check your debt position via the vdToken contracts or assume `2` as default.* * **iv. onBehalfOf** — Your wallet address.

#### 5. Execute the Transaction * Click **Send** to execute the repayment. * Confirm the transaction from the **same wallet address** that opened the borrow. {% hint style="warning" %} If you use a different address, the transaction will fail. {% endhint %} Once the loan is fully repaid, you will be able to withdraw your collateral using the [withdrawal guide.](#withdrawing-deposits) # Overview This section outlines the structure of a Decentralized Autonomous Organization (**DAO**) to be governed by community members who lock RDNT, a decentralized ERC-20 token that the community intends to serve as the primary token for governing the Radiant Protocol. ### **PURPOSE** Supernova Holdings (the “**Foundation**”) will serve the **Radiant DAO** by fostering a community ethos of dialogue and innovation, and will provide the frameworks necessary for decentralized governance on both a granular and a macro level. To achieve this, it is important to ensure that the processes of proposal submission and voting are restricted to Radiant DAO members. The sole requirement for membership in the DAO is to have any given amount of RDNT tokens held within Radiant’s `multiFeeDistribution` smart contract (hereby referred to as “**locked RDNT**”). A user’s balance of locked RDNT will proportionally represent their voting weight on all proposals. In alignment with the Foundation’s core value of transparency, all preliminary discussions, proposals, votes cast and outcomes will be publicly available to view. ### FOUNDATION & VALUES The Foundation, which will serve the Radiant DAO community and be governed by it, aims to be the executive arm of the protocol by implementing the consensus-driven will of the Radiant DAO. The Radiant DAO community will have the power to submit proposals, vote on proposals, and bring those to fruition. The Foundation adheres to four core values: 1. ***Innovation***: We focus on ways to think big and bold to accelerate innovation across ecosystems. 2. ***Determination***: We’d rather be iterating frequently than never trying. “Better a diamond with a flaw than a pebble without.” 3. ***Collective Benefit***: Solve for the customer–not just their happiness, but also their success. 4. ***Transparency***: “Sunlight is the best disinfectant.” -Louis Brandeis ### COUNCIL The Council plays a supporting and coordinating role for work contributed by the Radiant DAO ecosystem’s decentralized community of users (the “**Community**”). However, it is the Community’s responsibility to develop the RDNT DAO ecosystem and make proposals to guide the long-term strategy of the Foundation and the RDNT DAO. #### COMPOSITION Three (3) persons (“**Council Members**”) appointed by a plurality vote of locked RDNT Tokenholders, pursuant to and evidenced by the RFP Process, and in the first instance, appointed by the directions of the Foundation. #### TERM LIMITS * Inaugural Council will serve for an initial six (6) month term, beginning on **September 17, 2022** (the date at which RFP-1 was ratified). Subsequently, the Council will be chosen annually by a vote of locked RDNT token holders, pursuant to and evidenced by the RFP process. * The new Council will be voted in on **February, 2026**. * All subsequent Councils will serve for a twelve (12) month term. * A Council member may be removed and replaced prior to the term pursuant to a 2/3rds majority vote of locked RDNT token holders. * Any holder of ≥25000 locked RDNT may nominate a candidate to serve on the Council. #### AUTHORITY & RESPONSIBILITIES * Fund transitions by the Foundation from the Treasury, including employment contracts and grants to support Community development. * Sign transactions from the Council Multisig to ensure that an approved RFP receives sufficient signatures (even if the Council member had voted “no” with respect to that RFP). * Attend weekly meetings, vote on RFPs, and attend unofficial Community events hosted by the Foundation and ecosystem members. Council Members may choose the frequency with which they perform these activities at their own discretion, bearing in mind that if they fail to adequately represent the Community due to infrequency of participation, they may be removed as a Council Member by other Members. * Pursuant to RFPs, perform adjustments to economic parameters with respect to RDNT; provided that, in the instance of an Emergency Meeting as described below, the Council may perform adjustments to economic parameters with respect to RDNT pursuant to a majority vote of Council Members. * Coordinate Emergency Meetings on behalf of the Community, RDNT Tokenholders or the Foundation, pursuant to a majority vote of Council Members. This enables Council to rapidly respond to any imminent security threats to the Radiant ecosystem. # Key Terms * ***RFP (Radiant Foundation Proposal)*** - a document proposing a new feature, project, activity, goal, piece of information, or change to any proposal that has already been implemented. * ***RFP Idea*** - the first step in the process of creating an official RFP, which will be presented to the community for gathering informal feedback for a period of seven (7) days. * ***RFP Draft*** - the second step in the process of creating an official RFP, which can only be submitted after the original RFP idea has gathered feedback from the community for seven days in the proper channel. An RFP draft must be submitted directly to a moderator via predetermined RFP templates. * ***RFP Template*** - the preset format for an RFP draft, which will vary slightly depending on the nature of the intended RFP. * ***RFP Author*** - the DAO member responsible for beginning the RDNT Foundation Proposal, starting with presenting the idea to the community via the proper RFP idea process. The RFP Author is responsible for incorporating relevant feedback, submitting the subsequent RFP draft via the proper RFP template to the Intake Administrator, and responding to questions or requests for clarifications from DAO members and moderators. A minimum of 2500 locked RDNT is required to engage as a RFP Author. * ***RFP Categories*** - the predetermined classification system for organizing RFPs by their nature or intent. They are: Core Proposal, Ecosystem Fund Allocation Proposal (a subcategory of Core Proposal), Brand Decision Proposal (a subcategory of Core Proposal), Principles Proposal (a subcategory of Core Proposal), Process Proposal, and Informational Proposal. * ***Core Proposal*** - a proposal that would be considered the main activities of the DAO, with subcategories that can be expanded on over time via proposal submission. * ***Ecosystem Fund Allocation Proposal*** - a proposal about how the Ecosystem Fund should be spent. A subcategory of Core Proposals. * ***Brand Decision Proposal*** - a proposal about to whom the community wants to attach its name. This is different from an Ecosystem Fund Allocation Proposal in that it can have associated costs to implement but is not at its core a proposal about Ecosystem Fund Allocation. A subcategory of Core Proposals. * ***Process Proposal*** - a proposal about making a change to a process or proposing an implementation. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment of the DAO or Foundation. * ***Principles Proposal*** – a proposal for establishing and/or updating the major principles behind the distribution of the RDNT token and fees, including, but not limited to, staking, RDNT tokenomics and budget rules. A subcategory of Core Proposals. * ***Informational Proposal*** - a proposal that provides general guidelines or information to the community but does not propose a new feature. * ***Resubmission Proposal*** - a proposal that was previously submitted but did not pass either due to initial rejection by moderators or the Council, or by not passing a vote. All proposal categories have a special template for resubmission that the Author must link to the original proposal, clearly state why it did not pass, and clearly explain how the resubmission is different. * ***RFP Moderation*** - the act of reviewing an RFP to determine whether or not the RFP draft meets the predetermined and DAO-approved guidelines and therefore is eligible to move to the next step in the process. If an RFP passes RFP moderation, it becomes a Pending RFP. * ***Pending RFP*** - the RFP status after it passes RFP Moderation. * ***Post-Moderation Tagging*** - the process of tagging all Pending RFPs that have successfully made it through the RFP moderation phases. There are two tags given at this stage: 1. “***Approved to Vote***,” which is for any pending RFP where costs, content, and implications are considered to be straightforward and of no risk to the well-being of the DAO. 2. “***Needs Administrative Review***,” which is for any pending RFP with costs, content, or implications that are considered to be complicated or a potential risk to the well-being of the DAO and therefore must be reviewed by the Council of the DAO. * ***Administrative Review*** - the process of evaluating pending RFPs that have been tagged as “Needs Administrative Review” to determine whether they should be halted or sent to vote by the community. * ***Return for Clarification*** - a type of administrative classification that requires the RFP Author to clarify certain information regarding the Pending RFP. This classification would be given in cases such as cost to implement being unclear, proposing to utilize a larger percentage of the Ecosystem Fund than is justified based on the value it would provide to the community, or being in direct conflict with an active RFP. * ***Return for Reconstruction*** - a type of administrative classification that requires the proposer to restart the proposal submission process because the Pending RFP violates DAO-approved requirements, or in cases of violation of the law, reasonable suspicion of fraud or other misleading information, or the pending RFP being at odds with the mission, values, or well-being of the Foundation or DAO. * ***Weekly RFP Release*** - every Thursday at 9PM ET, when all RFPs that are ready to go live are released together in a batch. * ***Weekly Voting Close*** - when all RFPs in a Weekly RFP Release batch close for voting, which happens the following Wednesday at 9PM ET. * ***Live RFP*** - an RFP that has passed all required approval stages and is launched for the community to vote on it. * ***Final RFP*** - an RFP that has completed the voting process. There are two subcategories here: Accepted and Rejected. * ***Accepted Final RFP*** - an RFP that has met quorum requirements and received more than 50% of votes in favor of that RFP. * ***Implementation of Accepted Final RFP*** - the process of implementing an RFP that has been accepted by the community via a vote, based on the predetermined steps laid out in the Draft/Template phases. # Proposal Criteria 1. The total cost of implementation and any financial impact of its effectuation must be clearly defined in order for a proposal to go to vote. 2. If a proposal is ratified which directly impacts Radiant’s smart contracts (i.e., adjustment to emissions rates), it must pass through a 48 hour timelock before implementation. 3. The Radiant team wallet (0x62d3…fc2d) will be ineligible to vote on any Snapshot proposals, with the exception of an “abstain” vote. 4. All submittants must search through archived proposals to ensure they are not re-submitting a duplicate idea. 5. If a suggested proposal directly conflicts with a proposal that is currently up for vote, the second proposal should not go for a vote until a decision is made on the first proposal to avoid concurrent approval of opposing requirements. 6. To avoid concurrent proposals which directly conflict with one another, any idea that directly impacts a proposal that is currently under consideration should not be submitted or voted on until consensus has been reached on the initial proposal. 7. No conflict of interest (COI) proposal can be submitted for a vote until 90 days have passed since the original proposal was approved. 8. The Council will not consider or vote on proposals which advocate hate speech, illegal activity, explicit material, or are out of line with the Foundation’s mission and values. # Proposal Process ### Phase 1: RFP Idea * An RFP Idea is submitted as an idea via Discourse (community.radiant.capital) and must receive confirmation from the DAO Intake Administrator to ensure it complies with DAO-approved guidelines before it appears to the community. * A minimum of 2500 locked RDNT is required to engage as an RFP Author. * Pursuant to approval, DAO Intake Admin will tag the RFP Idea with the appropriate proposal category and make the post viewable to the public. * The person or people submitting the RFP Idea will be referred to as the “Author” or “Authors”. * Multiple members can work together on an RFP Idea, but it should be submitted only once. * The RFP Idea informally gathers upvotes and/or comments via Discourse interface over a seven (7) day period. * A minimum of one (1) locked RDNT is required to engage as an RFP commenter. * At the end of the seven day cycle, the pending RFP Ideas will be categorized as “Approved to Vote” or “Needs Administrative Review”. * Pending RFP Ideas flagged for Administrative Review must be reviewed by the Council and sub-categorized as “Not Planned,” “Return for Clarification,” “Return for Reconstruction,” or “Approved”. ### Phase 2: RFP Draft Once the seven-day feedback cycle has concluded, the RFP Idea will be archived. Pursuant to approval, a moderator will provide the eligible RFP Author with the appropriate template to submit to the DAO Intake Administrator as a formal Snapshot proposal. A proposal typically includes: 1. ***Abstract*** - Two or three sentences that summarize the proposal. 2. ***Motivation*** - A statement on why the Radiant Community should implement the proposal. 3. ***Rationale*** - An explanation of how the proposal aligns with the Radiant Community’s mission and guiding values. 4. ***Key Terms*** (optional) - Definitions of any terms within the proposal that are unique to the proposal, new to the Radiant Community, and/or industry-specific. 5. ***Specifications*** - A detailed breakdown of the platforms and technologies that will be used. 6. ***Steps to Implement*** - The steps to implement the proposal, including associated costs, manpower, any legal documentation (if applicable) and other resources for each step where applicable. 7. ***Timeline*** - Relevant timing details, including but not limited to start date, milestones, and completion dates. 8. **Overall Cost** - The total cost to implement the proposal. The Author will fill out the template based on the original RFP Idea, incorporating any feedback provided by the community that helps the idea better serve the DAO, including, but not limited to, lack of specificity in the proposal. The Author can add additional fields to the template if necessary to fully communicate the intentions, specifics, and implications of the RFP Draft. Proposals that did not make it through the initial Snapshot governance process and are being resubmitted should also include: * Link to original proposal * Reason it was not approved * Changes that have been made and why it should now be approved #### Category Options * Core: Ecosystem Fund Allocation * Core: Ecosystem Fund Allocation (Resubmission) * Core: Brand Decision * Core: Brand Decision (Resubmission) * Core: Principles Core: Principles (Resubmission) * Process * Process (Resubmission) * Informational * Informational (Resubmission) The Intake Administrator may then continue communication with the Author to inform them of any incorrect or missing information that needs to be changed—or clarifications that need to be made—in order for the RFP Draft to comply with the DAO-approved guidelines and move to the next step. If the Author does not respond to a moderator’s request to change, update, or make clarifications on the RFP Draft within seven (7) days, the RFP Draft will be automatically rejected as having failed to comply with the DAO-approved guidelines. When the Intake Administrator confirms that an RFP Draft complies with the DAO-approved guidelines, they assign a number to the RFP for identification purposes throughout the rest of the process. From this point on, the RFP is referred to as “**RFP-#: (Name) - (Category)**”. {% hint style="info" %} *For example, the inaugural RFP set forth to propose this governance structure is titled “**RFP-1: DAO Proposal - Process**”.* {% endhint %} ### Phase 3: RFP Moderation The RFP is reviewed by the Intake Administrator, and will either be approved or not approved based on whether it adheres to the DAO-approved guidelines. If an RFP is approved as complying with DAO-approved guidelines, it becomes a Pending RFP. If an RFP fails to comply with DAO-approved guidelines, it is eligible for resubmission unless in cases of violation of the law or reasonable suspicion of fraud or other misleading information. ### Phase 4: Post-Moderation Tagging Pending RFPs that have passed RFP Moderation will then either be tagged as “Approved to Vote” or “Needs Administrative Review” as each term is defined and described in this Proposal. The “Approved to Vote” tag is given for any pending RFP whose costs, content, and implications are considered to be straightforward and of no risk to the well-being of the DAO. The “Needs Administrative Review” tag is given for any pending RFP whose costs, content, or implications are considered to be complicated or a potential risk to the well-being of the DAO. Any Pending RFP that is tagged as “Needs Administrative Review” must go through Phase 5. ### Phase 5: Administrative Review {% hint style="info" %} *This phase is only for Pending RFPs that have been tagged with “**Needs Administrative Review**.”* {% endhint %} When an RFP is tagged for review, the Council, serving in an administrative capacity, will determine whether further action is required prior to a Pending RFP proceeding to Phase 6. Pending RFPs that the Council determines do not require additional action will be tagged as “Approved to Vote” and proceed to Phase 6. If the Council decides to return a Pending RFP for further clarification or action, they must provide a clear explanation of why and tag it as either “Return for Reconstruction” or “Return for Clarification.” Reasons to tag as “Return for Reconstruction” or “Return for Clarification” may include but are not limited to: * Cost to implement unclear/not able to be calculated (tagged as “Return for Clarification”) * Proposes to use more than 5% of the Ecosystem Fund (tagged as “Return for Clarification”) * Conflicts with another proposal (tagged as “Return for Clarification”) * Proposal is at odds with the mission/values of the DAO (tagged as “Return for Reconstruction”) * Proposal is at odds with the well-being of the DAO (tagged as “Return for Reconstruction”) * Violations of law, or against advice of counsel for the Foundation (tagged as “Return for Reconstruction”) * Reasonable suspicion of fraud or other misleading information (tagged as “Return for Reconstruction”) ### Phase 6: Live RFP Drafts that have passed their respective approval processes will become a Live RFP on Snapshot ([dao.radiant.capital](https://dao.radiant.capital)) during the next Weekly RFP Release, which is when new RFPs are released in batches every **Thursday at 9PM ET**. Administrators are the only ones that can post RFPs to Snapshot because they must ensure that each one has gone through the correct approvals process. All RFPs released to vote will undergo a 24hr delayed “warm-up phase,” in which the RFP is submitted to Snapshot for public view, but is not yet committed to the blockchain or eligible for voting. This affords the Author, Council and/or Admin a supervisory window to correct any errata before the proposal details are rendered immutable. The warm-up phase only provisions for typographical or numerical errors and not for significant changes to the RFP content itself. Once live on Snapshot, Live RFPs are open to voting until Weekly Voting Close, which is when **all Live RFPs from a given batch close for voting at approximately 9PM ET on the Wednesday following their release**. The voting options are “***In favor,***” “***Against***,” and “***Abstain***.” Voting “In favor” means the voter is in favor of implementing the RFP exactly as-is. Voting “Against” means the vote is against implementing the RFP exactly as-is — voters may vote “Against” to encourage the Author to resubmit the RFP after making changes. Voting “Abstain” means the votes are counted towards quorum but are neither “In Favor” or “Against” of implementing the RFP. The quorum requirement for a Live RFP will be 10% of the circulating supply of locked RDNT. Once quorum has been met, a Live RFP may only be passed with greater than 50% of votes cast “In favor”. A Live RFP which has not received greater than 50% of votes cast “In favor” will not be passed. A Live RFP which has met quorum and achieved greater than 50% of votes cast “In favor” will be deemed an Accepted Final RFP. ### Phase 7: Final RFP If by the Vote Close Time the Live RFP has not received any votes or is tied, it will be tagged as “Stalled” and be eligible for Resubmission. In all other cases, after the Vote Close Time, Live RFPs are moved to Final RFPs. There are two subcategories for the Final RFP status: accepted and rejected. Rejected Final RFPs will have the chance to be resubmitted via the appropriate Resubmission Template if the Author contacts a moderator to initiate this process. Accepted Final RFPs will move into implementation. # Specifications ### **DAO Hub** The Foundation website ([radiant.capital](https://app.radiant.capital)), which will provide an interface to educate DAO members on the governance process and provide easy access to the channels described below in order to streamline the DAO’s operation and enhance its utility. ### **Communication Channel (**[**Phase 1**](/radiant/governance/proposal-process#phase-1-rfp-idea)**)** {% hint style="success" %} **Discourse -** [**community.radiant.capital**](https://community.radiant.capital) {% endhint %} Discourse is a forum framework, hosted and configured by the Radiant DAO, to be used as the initial point of discussion for matters of governance. RDNT holders must go through a wallet authentication process to post ideas or give feedback to ideas via comments. RFP Idea posts must be approved by a moderator to ensure they meet all predetermined guidelines and template requirements. All posts and comments will be regularly monitored by both a team of moderators & administrators engaged by the Foundation and by the DAO community members themselves. There will be zero tolerance for hate speech anywhere on this platform. The Author of an idea via a post in [community.radiant.capital](https://community.radiant.capital) cannot edit the original post. If the Author wants to propose changes to the original idea, the Author must do this via the comments. Seven (7) days after it has been posted, an RFP Idea is closed to community feedback and will be automatically locked by Discourse. ### Process for Draft Submission via Template: ([Phase 2](/radiant/governance/proposal-process#phase-2-rfp-draft)) Once an idea is approved in community.radiant.capital after the seven-day community feedback cycle, a moderator will contact the Author to provide the appropriate template. The Author should then submit an official RFP draft to the Intake Administrator using the template. The administrator may then continue communication with the Author to inform them of any incorrect or missing information that needs to be changed—or clarifications that need to be made— for the RFP Draft to move to the next step. If the Author does not respond to the Administrator’s request to change, update, or make clarifications on the RFP Draft within seven (7) days, the RFP Draft will be automatically rejected. ### Live RFPs (Phase 6) {% hint style="success" %} **Snapshot -** [**dao.radiant.capital**](https://dao.radiant.capital) {% endhint %} Snapshot is a framework for on-chain, gasless voting. RDNT holders must go through a wallet authentication process to vote on Snapshot. Council Members are the only ones allowed to launch RFPs on Snapshot as they must ensure each RFP has gone through the correct approval process. #### Snapshot Voting Criteria 1. Only locked RDNT will be eligible to vote. 2. New proposals that meet the required guidelines will be launched in batches every Thursday at 9PM ET. 3. User balance of locked RDNT will be referenced by block height at proposal launch. 4. There will be a 24 hour “warm-up” period in order to allow a final review period for any superficial errors, as well as to encourage maximum voter engagement. 5. The standard voting options for a Live RFP are “***In favor***”, “***Against***”, and “***Abstain***”. 6. Voting “In favor” means the voter is in favor of implementing the RFP exactly as-is. 7. Voting “Against” means the vote is against implementing the RFP exactly as-is – one may vote “Against” to encourage the Author to resubmit the RFP after making changes. Voting to “Abstain” means the vote is neither In Favor nor Against implementing the RFP, but the vote weight still will be counted towards quorum. 8. The voting for each proposal in each weekly batch will be open for voting for five (5) days, closing at approximately 9PM ET on the following Wednesday. 9. A vote must reach greater than 50% of votes cast “In favor” in order to pass. 10. Furthermore, a vote must meet a quorum of 10% of circulating locked RDNT supply, to be determined at current block height when vote is initiated. 11. Proposals that are approved by the holders of the requisite number of locked RDNT are moved to the Foundation for implementation. 12. Only Administrators can post RFPs to Snapshot in order to ensure that each one has gone through the correct approvals process. # Remediation Plan DAO-approved and implemented by the annually-elected Radiant Capital Community Council. {% hint style="info" %} For further information on the Remediation Plan: {% endhint %} Following the October 16, 2024 exploit, the DAO approved a [Community Remediation Plan](https://medium.com/@RadiantCapital/radiant-capital-dao-community-remediation-plan-196c8366b4da#9e3c) to remediate affected users, maintain treasury sustainability, and reinforce protocol security. This framework combines community-approved proposals, governance votes, executed by an annually elected community council. ## Objectives * Deliver a DAO-approved path for user remediation. * Balance treasury and emissions sustainability. * Reinforce security posture with audits, monitoring, and bounties. * Ensure fairness and transparency via governance. ## Key Components ### 1. Eligibility * **Eligible**: Losses from the Radiant **lending market deposits** ([details](https://medium.com/@RadiantCapital/radiant-capital-dao-community-remediation-plan-196c8366b4da#5a3d)). Remediation will be 1:1 with in-kind assets, subject to available funds from protocol fees, future investments, and partner contributions. * **Not Eligible** (for now): **Unlimited allowance** wallet drains. A [separate proposal](https://snapshot.box/#/s:radiantcapital.eth/proposal/0x54d0b26ba2a9f33100bcd4e7918415aa80863189f12a7fbe1c7c25c40866a59e) failed quorum; future votes may revisit. The will of the community will dictate. * **Convenience Class**: The DAO voted to create a [“convenience class”](https://snapshot.box/#/s:radiantcapital.eth/proposal/0x423740456e9aa29a266ea55e40d9e8481efe25e2f783e61c5aab2e7e907e3019), grouping **smaller** amounts (**$10-$1,000** at 30% haircut) into a streamlined process, **addressing 95% (28K)** of the users and 2% of total loss, with **distribution beginning in Q4 2025**. This reduced administrative overhead, prevented backlog, and ensured quicker distribution for smaller accounts — a fairness-driven community decision. ### 2. Remediation Multi-sig * Funded via a combination of: Protocol Revenue, DAO treasury, adjusted emissions, reserves, new investments, and new partner contributions. * Allocated proportionally across Remediation Claim Contracts. ### 3. Distribution Mechanics * [Claim contracts](https://medium.com/@RadiantCapital/radiant-capital-dao-community-remediation-plan-196c8366b4da#ed2f) distribute funds directly on-chain. * Tranche releases are phased over multiple quarters, with the convenience class handled earlier (starting in Q4 2025) for efficiency. ### 4. Governance Oversight * Parameters ratified via Snapshot votes. * Adjustments follow the RFP/RPP governance process. ### 5. Security Hardening * Expanded audits, monitoring, and incident response. * [Recovery Bounty Program](https://medium.com/@RadiantCapital/radiant-capital-recovery-bounty-program-b4d116c691d0) incentivizes ethical fund return. * Protocol upgrades detailed in [Sixty Days of Progress](https://medium.com/@RadiantCapital/sixty-days-of-progress-radiant-daos-path-to-renewal-f7950c452c35#b0ee). ## Timeline The plan phases distributions while preserving sustainability.

## Related Resources * [Community Remediation Plan](https://medium.com/@RadiantCapital/radiant-capital-dao-community-remediation-plan-196c8366b4da) * [Sixty Days of Progress](https://medium.com/@RadiantCapital/sixty-days-of-progress-radiant-daos-path-to-renewal-f7950c452c35) * [Snapshot: Convenience Class Vote](https://snapshot.box/#/s:radiantcapital.eth/proposal/0x423740456e9aa29a266ea55e40d9e8481efe25e2f783e61c5aab2e7e907e3019) * [Recovery Bounty Program](https://medium.com/@RadiantCapital/radiant-capital-recovery-bounty-program-b4d116c691d0) * [RFP-52: Guardian Fund](https://snapshot.box/#/s:radiantcapital.eth/proposal/0x8b69c2535698b6a93b383dcba4c84e4174e65a7b1535c6b66ccf2ae481d88b86) ## Disclaimer The Remediation Plan is community and DAO-approved and administered by the annually elected community council. It does not guarantee full remediation and remains subject to governance votes, treasury constraints, and technical feasibility.
# Remediation Portal Visual Guide for using and understanding the Remediation UI. {% hint style="info" %} **Protocol Revenue Deposits:** Starting in **Q4 2025**, **15% of Radiant’s protocol revenue** will be automatically deposited into claim contracts each quarter, continuing to fund remediation over time. {% endhint %} ### Phase I: View-Only Access **Status:** 🟢Live (as of October 8, 2025)\ **Purpose:** Provide full transparency for affected depositors ahead of the remediation claim process. Phase I introduces a **view-only version** of the Remediation Portal.\ This interface allows users to **check their eligibility and remediation amounts** based on data from the **final balance checker**; no wallet connection required. Simply enter your wallet address in the search bar to view: * **Deposits:** Token balances held at the time of the exploit. * **Loans:** Outstanding borrow positions at the time of the exploit. * **Token Merge:** Consolidation of tokens into the merge assets. * **Liquidation:** Users with impacted loans were liquidated, and their loan amounts were deducted from deposits. All conversions were made using closing-day pricing data from the day balances were recalculated. * **Final Balance:** Net position after all merges, deductions, and liquidations, used to determine eligibility for future distribution. Price references used during each phase (e.g., exploit day, claim contracts, and convenience class) can also be viewed directly in the **“Show Prices”** section of the portal for full transparency. #### How It Works 1. Visit the [Remediation Portal](https://remediation.radiant.capital/). 2. Paste your wallet address in the search field.

3. Review your deposits, loans, and calculated balance data. 4. Compare results with the raw datasets (optional): * [Claim contracts group](https://docs.google.com/spreadsheets/d/1C3Goslj0VIp-aqTkZUwARMYCcxaq-0rc8baVF15QSXs/edit?gid=1220247566#gid=1220247566) * [Convenience class group](https://docs.google.com/spreadsheets/d/1J2IUJaaTA4mNf9dDHOpGvEubYqRJ5fsr68bgeMngnpA/edit?gid=1863701531#gid=1863701531) No wallet connection or transaction signing is required when checking the data only. ### Phase II: Claim Contracts & Convenience Class Phase II provides the foundation to progressively enable users to claim and receive funds directly through the portal. * **Phase II Status:** 🟢Live (as of December 3, 2025) * **Claim Contracts:** Claim contracts are now deployed and integrated into the Remediation Portal. To activate the “Claim Contracts” section within the portal you need to connect your wallet. Eligible users need to connect their wallets to view their share (%) per contract, their token totals, the available claimable tokens, and the tokens claimed thus far.

*The claim contracts distribute WBTC, WETH, USDC, and ARB on Arbitrum Chain, and BTCB, WETH, USDC, and BNB on BNB Chain.* * **Convenience Class Distributions:** Eligible users in the Convenience Class will receive a one-time distribution in **multiple tranches via Merkl airdrops**, the Convenience Class Distributions table shows the Tranches, Balance Ranges, the start of the Distribution Date for a given tranche, and a link to the Merkl Claim page. ### Remediation MultiSig Wallets Funds reserved for the Radiant DAO remediation plan are collected and held in Remediation MultiSig wallets. Distributions will be sent from these wallets.

Chain	Address
Arbitrum	0x1d44720e23a14E7c4EE04Df2207fe93Df7C71dE0
BNB Chain	0x1d44720e23a14E7c4EE04Df2207fe93Df7C71dE0

### Remediation Claim Contracts

Chain	Asset	Contract
Arbitrum	WBTC	0x5D2AE6B946Dcaa232Dd9f7A0319E2cfDaF3306F1
Arbitrum	WETH	0x43A0Ff7f6A9E2Ca173567341fEd248820f4ac275
Arbitrum	ARB	0x9036fB82Ada7ABB108AaE902180a140403679738
Arbitrum	USDC	0xCf941c8654e2523c35442C8a1fcDf58253B36469
BNB Chain	BTCB	0x0dC09097675b305caC01f37989a409c7D319BEBf
BNB Chain	WETH	0x4b23910574A2416F23727Eb7D16f2d6d5DdF611C
BNB Chain	BNB	0x6CaaE6d32E6a2935Fc6c2c222f24F694a0De6342
BNB Chain	USDC	0x693daA70d29427aBab7439020948f2fA0100264c

### Remediation Portal FAQ

Why can’t I see my balance in the claim contracts?

If you are unable to find your balance or percentage share, please note that the claim contracts are deployed on two networks: 4 on Arbitrum and 4 on BNB Chain. Even if your assets were originally on Arbitrum, your claim may be associated with the BNB Chain contracts. To check, use the chain selector in the top-right corner of the portal and switch to BNB Chain. Your share should appear once you are on the correct network.

# Exploited Contract List **Arbitrum rTokens** WBTC: 0x727354712BDFcd8596a3852Fd2065b3C34F4F770 rUSDT: 0xd69D402D1bDB9A2b8c3d88D98b9CEaf9e4Cd72d9 rUSDC.e: 0x48a29E756CC1C097388f3B2f3b570ED270423b3d rDAI: 0x0D914606f3424804FA1BbBE56CCC3416733acEC6 rWETH: 0x0dF5dfd95966753f01cb80E76dc20EA958238C46 wstETH: 0x42C248D137512907048021B30d9dA17f48B5b7B2 rARB: 0x2dADe5b7df9DA3a7e1c9748d169Cd6dFf77e3d01 rUSDC: 0x3a2d44e354f2d88EF6DA7A5A4646fd70182A7F55 rweETH: 0xb11A56DA177c5532D5E29cC8363d145bD0822c81 rgmBTC: 0x876f38f474e48a104c4af4f06ca488099c436c93 rgmETH: 0xd15a6568dc891fd04aa2f64af56c66c2bede59d6 **Arbitrum vdTokens** vdWBTC: 0x3EEaFa33625DF20837eD0Cb83Ae4D1E34788b141 vdUSDT: 0x7C2E0F792ea5B4a4Dbd7fA7f949CF39A5c0ba185 vdUSDC.e: 0x107583ADAA37Dfd1CC0bf577183Bf91351d07413 vdDAI: 0x04A8fAEd05C97290Ab4d793A971AdEe97cD1cBbD vdwETH: 0xab04c0841f39596C9F18A981a2BD32F63AB7a817 vdwstETH: 0x97B81aA985115953Ba31D59781e2D8159A50F488 vdARB: 0x295b97012945bD4a1A79ec7f679e16761a437e5C vdUSDC: 0xD69b772bfFe78165c152Fd2e370b6CaE239E3BDb vdweETH: 0x2D7d510Dc21F5384C9efd30811D0366F8b4269DF *** **BNB Chain rTokens** BTCB: 0x34d4F4459c1b529BEbE1c426F1e584151BE2C1e5 USDT: 0x4Ff2DD7c6435789E0BB56B0553142Ad00878a004 rBUSD: 0x89d763e8532D256a3e3e60c1C218Ac71E71cF664 rUSDC: 0x3bDCEf9e656fD9D03eA98605946b4fbF362C342b rBNB: 0x58b0BB56CFDfc5192989461dD43568bcfB2797Db rETH: 0x455a281D508B4e34d55b31AC2e4579BD9b77cA8E rwBETH: 0x6350e53461c7C95964D699cfa4e84cec993eebb1 **BNB Chain vdTokens** vdBTCB: 0x3c84437794A5515150982A6F69DE5b3e017004a1 vdUSDT: 0x437F3dF56eCeE512E407b6eC368523C911D4A283 vdBUSD: 0x8D3308e14A48f0681CeA94D7C6995Ec73b3973f1 vdUSDC: 0x81FdA3BE7F3Ca6aCDAe20a8d2B4Ce54B78d70ED0 BNB: 0xCbB96324f77a66e276f80B843ECdB3fADC551bfF vdETH: 0xDCB45a8aA72854e06C826B16Fd5038f33E2CB4b0 wBETH: 0xF9956D8dA92cFbC1C5B998afFc86ccE28D42DC61 # zeroShadow Summary Report {% hint style="info" %} The information provided here is for general informational purposes only and should not be considered legal, tax, or financial advice. Please consult with a qualified professional—such as a tax advisor, lawyer, or other relevant expert—before making any decisions based on this information. {% endhint %} {% hint style="info" %} This document provides an informational summary of publicly observable on-chain transactions involving transfers to Tornado Cash related to the October 16, 2024 Radiant Capital exploit. It is provided for informational purposes only and does not constitute legal, tax, or financial advice. {% endhint %} Following community requests, the DAO has obtained an official summary report from **zeroShadow** documenting the historical on-chain movement of funds to Tornado Cash. The report is intended to help affected users maintain documentation that may support personal tax reporting, including positions that rely on demonstrating a potential *“no reasonable prospect of recovery.”* To ensure it can be safely shared, the report: * Contains only publicly verifiable, historical on-chain transactions * Documents transfers of affected funds to Tornado Cash contracts * Does not disclose investigative methods, internal analysis, or sensitive information * Does not compromise ongoing recovery efforts The report can be access through a secure Google Document link: {% hint style="info" %} Links to Google Docs expose personal information. A temporary Google account or a private browser tab may mitigate this exposure. {% endhint %} # Recovery Bounty Program The **Recovery Bounty Program** was introduced as part of the DAO’s remediation process to help trace and recover assets affected by the October 2024 exploit. This initiative allows participants — such as bounty hunters, ethical hackers, and security researchers — to submit information regarding affected funds and potentially claim a reward if their contribution results in a successful recovery. Submissions require details such as: * Incident and chain(s) involved * Tokens and amounts affected * Destination of funds * Related transaction hashes * Participant information and contact details For full details on eligibility, process, and reward structure, please refer to the official [Medium](https://medium.com/@RadiantCapital/radiant-capital-recovery-bounty-program-b4d116c691d0) article. # Technical Reference Technical reference documentation regarding the Radiant Capital DAO sunset announcement. ### Radiant V2 User Sunset Reference This document captures what a user or stakeholder needs to know going forward. #### 1. What stops, what stays **What stops** * Lending pool — `borrow` parameter is set to 1, which effectively disables it operationally. * RDNT no longer flows into the `ChefIncentivesController`. With nothing to distribute, `claim()` and `claimAll()` continue to function but return zero. No on-chain transaction is required to disable emissions — the absence of RDNT in CIC is sufficient. `stopEmissionsFor` and similar levers are not needed. **What stays operational** * Lending pool — `deposit`, `withdraw`, `repay`, and liquidations all function normally. * Reserve factor accrual — protocol fees continue accruing to reserves and are forwarded to MFD via `MiddleFeeDistribution` on user interactions. * `RadiantOFT` cross-chain transfers — bridging continues. * `MultiFeeDistribution` — reward streams already in the contract continue draining over `rewardsDuration`. Existing vesting positions continue to vest over `vestDuration`. Existing dLP locks continue to release on schedule. * `Compounder`, `BountyManager`, `EligibilityDataProvider` — remain callable. Without new RDNT emissions, relock bounties yield nothing and eligibility gating becomes a no-op for reward purposes. * `Leverager`, `LockZap`, `StargateBorrow` — remain callable. * Oracles — Chainlink adapters continue to read live feeds. `AaveOracle.setAssetSources` is an owner-gated lever if a feed is ever delisted. **Tail liabilities (drain naturally)** * RDNT already deposited into MFD's reward stream — drains over `rewardsDuration`. * Outstanding vesting RDNT per locker — drains over `vestDuration`. * Bounty contract balances — remain claimable while `BountyManager` is active. Quantities are dynamic; query on-chain when needed. #### 2. User exits * **Lending pool** — `LendingPool.withdraw(asset, amount, to)`, or redeem aTokens. * **MFD locks** — `withdrawExpiredLocksFor(user)` releases any locks past their unlock date with no penalty. `exit(claimRewards)` claims everything immediately, applying the early-exit penalty burn on locks not yet expired. * **MFD vesting** — vested RDNT becomes claimable through MFD as `vestDuration` elapses per position. * **dLP** — exit the underlying LP directly via Balancer (mainnet / arbitrum), Uniswap (bsc), or Velodrome / UniV3 (base). * **RDNT cross-chain** — `RadiantOFT.sendFrom(...)` continues to move RDNT between deployed chains. #### 3. Instructions for exiting positions via contracts > Your Funds Remain Safe Radiant's smart contracts continue to operate on-chain even if the Radiant website is unavailable. Your deposits, collateral, rewards, and borrowing positions remain under your control and can always be managed directly through the blockchain. If the Radiant app is offline, you can get an overview of your assets via debank.com. This guide explains how to access and close your positions using trusted block explorers such as Etherscan, Arbiscan, BscScan, and BaseScan. > Important: You do not need coding experience to complete these actions. *** **Before you begin** You will need: ✅ The **wallet** that owns the position ✅ A small amount of **gas tokens** (ETH or BNB) ✅ The **address of the token** you will be transacting (they are different for each blockchain) ✅ The appropriate Radiant contract (or use links provided) **Official contract addresses** For reference, all verified Radiant contract addresses are maintained here, under the [CONTRACTS & SECURITY](https://docs.radiant.capital/radiant/contracts-and-security/arbitrum-contracts) section. However, contract links are provided in the ▶️ how-to sections for your convenience. > Caution: Always verify an address on the explorer's Read Contract tab (e.g. owner(), name()) before signing any transaction. Based on your **position type**, **follow** these ▶️ how-to sections below.

▶️ Core markets

**✅ Repaying loans and withdrawing deposits** 1. **Open** the LendingPool contract on [Ethereum](https://etherscan.io/address/0xA950974f64aA33f27F6C5e017eEE93BF7588ED07#writeProxyContract), [Arbitrum](https://arbiscan.io/address/0xE23B4AE3624fB6f7cDEF29bC8EAD912f1Ede6886#writeProxyContract), [BNB Chain](https://bscscan.com/address/0xCcf31D54C3A94f67b8cEFF8DD771DE5846dA032c#writeProxyContract), or [Base](https://basescan.org/address/0x30798cFe2CCa822321ceed7e6085e633aAbC492F#writeProxyContract). *Note: If you open the block explorer and enter the contract address yourself, you’ll also need to select “Contract” and “Write as Proxy” (or “Write Contract” in some cases).* 2. **Connect** **Wallet** 3. Expand the **repay** function and enter required info * asset: Token address you’re repaying * amount: Use the appropriate number of decimals (examples below) * 1 USDC (6) = 1000000 * 1 ETH (18) = 1000000000000000000 * For the **entire/max balance**, enter this as the amount, verbatim: 115792089237316195423570985008687907853269984665640564039457584007913129639935 * rateMode: 2 * onBehalfOf: Your wallet address 4. Expand the **withdraw** function and enter asset, amount, your wallet address to **return** your collateral/deposit back to your wallet. **✅ Withdrawing unlocked dLP (no penalty)** 1. **Open the MultiFeeDistribution contract on** [**Ethereum**](https://etherscan.io/address/0x28E395a54a64284DBA39652921Cd99924f4e3797#writeProxyContract)**,** [**Arbitrum**](https://arbiscan.io/address/0x76ba3eC5f5adBf1C58c91e86502232317EeA72dE#writeProxyContract)**,** [**BNB Chain**](https://bscscan.com/address/0x4FD9F7C5ca0829A656561486baDA018505dfcB5E#writeProxyContract)**, or** [**Base**](https://basescan.org/address/0xD87F8a52a91680c993ece968B281bf92505A3741#writeProxyContract)**.** 2. **Connect Wallet.** 3. **Expand the withdrawExpiredLocksForWithOptions function and enter your wallet address (ignore the other options).** **✅ Withdraw RDNT** **RDNT rewards** vest over 90 days inside the MultiFeeDistribution contract on [Ethereum](https://etherscan.io/address/0x28E395a54a64284DBA39652921Cd99924f4e3797#writeProxyContract), [Arbitrum](https://arbiscan.io/address/0x76ba3eC5f5adBf1C58c91e86502232317EeA72dE#writeProxyContract), [BNB Chain](https://bscscan.com/address/0x4FD9F7C5ca0829A656561486baDA018505dfcB5E#writeProxyContract), or [Base](https://basescan.org/address/0xD87F8a52a91680c993ece968B281bf92505A3741#writeProxyContract). Select from 3 scenarios: * **No penalty**: Enter amount\* in the **withdraw** function for vested RDNT. You can check the eligible amount\* by querying against your wallet address in the **withdrawableBalance** function on the contract’s **Read as Proxy** tab (ensure wallet is connected). * **Exiting** each position **early** (50 % penalty): In the **individualEarlyExit** function, fill out claimRewards (set to **True** to also pull **platform revenue/rewards**) and unlockTime\*. You can check each position’s unlockTime\* from the **earnedBalances** function on the contract’s **Read as Proxy** tab (ensure wallet is connected). * **Exit everything** (50 % penalty on un-vested): Enter **true** for claimRewards in the exit function to claim all dLP locking rewards and RDNT (100% for fully vested; 50% for unvested) **✅ Claiming dLP locking rewards/platform revenue** 1. **Open** the MultiFeeDistribution contract on [Ethereum](https://etherscan.io/address/0x28E395a54a64284DBA39652921Cd99924f4e3797#writeProxyContract), [Arbitrum](https://arbiscan.io/address/0x76ba3eC5f5adBf1C58c91e86502232317EeA72dE#writeProxyContract), [BNB Chain](https://bscscan.com/address/0x4FD9F7C5ca0829A656561486baDA018505dfcB5E#writeProxyContract), or [Base](https://basescan.org/address/0xD87F8a52a91680c993ece968B281bf92505A3741#writeProxyContract). 2. **Connect**** Wallet** 3. Expand the **getAllRewards** function and select **Write**

▶️ RIZ v1 (isolated AAVE-style pools)

**Every RIZ v1 market** has its **own** RizLendingPool contract. The interface is identical to Core Markets - the only thing that changes is the pool address. **✅** Repaying loans and withdrawing deposits 1. **Open** the appropriate RizLendingPool contract from the **table below**. *Note: If you open the block explorer and enter the contract address yourself, you’ll also need to select “Contract” and “Write as Proxy” (or “Write Contract” in some cases)*.


arbiscan.io	bscscan.com	etherscan.io	basescan.io
ZRO/USDC	CAKE/USDT		AERO/USDC
RDNT/USDC	slisBNB/WBNB		ZRO/USDC
rsETH/WETH	~~FLOKI/USDT~~		MAVIA/USDC
ezETH/WETH			wSuperOETH/WETH
PT-wstETH/WETH			~~BRETT/USDC~~
GMX/USDC
gmARB/USDC
~~USDC/USDY~~

2. **Connect**** Wallet** 3. Expand the **repay** function and enter required info * asset: Token address you’re repaying * amount: Use the appropriate number of decimals (examples below) * 1 USDC (6) = 1000000 * 1 ETH (18) = 1000000000000000000 * For the entire/max balance, enter this as the amount, verbatim: 115792089237316195423570985008687907853269984665640564039457584007913129639935 * rateMode: 2 * onBehalfOf: Your wallet address
4. Expand the **withdraw** function and enter asset, amount, your wallet address to **return** your collateral/deposit back to your wallet.

▶️ RIZ v2 (single Mmlti-market contract, Morpho-style)

**RIZ v2** uses **one** RadiantLendingMarket contract **per chain**. Every **market** lives inside it, **identified** by a **MarketParams tuple**. **✅ Repaying loans and withdrawing deposits** 1. **Open** the RadiantLendingMarket contract on [Ethereum](https://etherscan.io/address/0x6365632c91e53B7f96F53722aba1e17Aadf973aA#events), [Arbitrum](https://arbiscan.io/address/0x41e5585496c6e43d9fD548B5F88fC2d90D67aE38#events), [BNB Chain](https://bscscan.com/address/0xcdc0E0A3685311a46FFb67f85Cd1ee717e8E645d#events), or [Base](https://basescan.org/address/0x5D64926bEF21BD772e7d6F89AED16d8c1A93dD66#events). *Note: These contract links will take you to the Event tab, where you can go to **step 3** below to read your position.* 2. **Connect** your **wallet** 3. **Read** your **position** You need three (3) numbers (supplyShares, borrowShares, collateral) before you can exit cleanly. * [ ] **Find** your market's ID - easiest via the explorer's **Events** tab on RadiantLendingMarket: **filter** for a Supply, Borrow, or SupplyCollateral event from your **wallet**; the **first indexed topic** is the position ID. * [ ] Switch from **Event** tab to **Contract** tab, then select **Read Contract** and * [ ] **expand** the **position** row to enter your position: position ID & wallet address * [ ] **Select**** Query** and note all three (3) returned values.
4. **Switch** back to **Write Contract** tab. 1. **repay**: marketParams = tuple 1. **assets** = 0 2. **shares** = your borrowShares 3. **onBehalf** = your wallet address 4. **data** = 0x. (Using **shares** clears your debt to the last wei; using **assets** leaves dust.) 2. **withdrawCollateral**: marketParams = tuple 1. assets = your collateral 2. onBehalf = your wallet address 3. receiver = your wallet address 3. If you also lent into the market, **withdraw**: marketParams = tuple 1. **assets** = 0 2. **shares** = your supplyShares 3. **onBehalf** = your wallet address 4. **receiver** = your wallet address. (Reverts with INSUFFICIENT\_LIQUIDITY if the market is fully utilized - wait for borrowers to repay or withdraw a smaller amount.)

Need help?

* **Reverts** on **repay**? Check (a) the asset is the correct underlying, (b) you used 2 for rateMode (V2 Core / RIZ v1), (c) you approved enough of the underlying token first. * **RIZ v2** **reverts** with **MARKET\_NOT\_CREATED**? A single typo in the MarketParams tuple changes the id and points to a non-existent market - verify all six fields. * **RIZ v1 / V2 vault redeem reverts**? Vault may be in emergency shutdown - call emergencyWithdraw instead. Every action above is permissionless and yours to execute. The Radiant smart contracts are immutable infrastructure - even with the front-end down, your funds are always recoverable directly on-chain.

# Arbitrum Contracts Radiant v2 Contract Addresses Primary Tokens The RDNT token and wETH/RDNT LP contract addresses are as follows: * **rdntToken:** [`0x3082CC23568eA640225c2467653dB90e9250AaA0`](https://arbiscan.io/token/0x3082cc23568ea640225c2467653db90e9250aaa0) * **stakingToken (Balancer 80/20 LP):** [`0x32dF62dc3aEd2cD6224193052Ce665DC18165841`](https://arbiscan.io/token/0x32df62dc3aed2cd6224193052ce665dc18165841) The subsequent contracts are divided into two categories: 1. **Core Contracts:** core protocol contracts that contain the logic for supply, borrow, liquidation, aTokens, pool configuration, oracles, and interest rate strategies 2. **Peripheral Contracts:** rewards, UI data provider, incentive data provider, wallet balance provider, and wETH gateway ## Core Contracts ### Configuration * **PoolAddressProvider:** 0x454a8daf74b24037ee2fa073ce1be9277ed6160a * **PoolAddressesProviderRegistry:** 0x9D36DCe6c66E3c206526f5D7B3308fFF16c1aa5E * **PoolHelper:** 0xfC05ec21b106E0c1e035Ec4718C1394f098FBb57 ### Pool Logic * **lendingPool:** 0xE23B4AE3624fB6f7cDEF29bC8EAD912f1Ede6886 {% tabs %} {% tab title="Core" %} **Tokenization**

rTokens

**rWBTC:** 0xa366742D785C288EcAD8120D5303Db4EB675c9EC **rWETH:** 0xfB6f79Db694Ab6B7bf9Eb71b3e2702191A91dF56 **rUSDC:** 0xb1D71c15D7c00A1b38C7ad182FA49889A70DB4be **rUSDT:** 0x62f9F05F3af1A934f0e02EAd202E3de36a6501E6 **rwstETH:** 0xBe6E57d96674e4873173DA7D48c1efbC55F2fA37 **rweETH:** 0x44e1C41E6CA07198edBdb4d3E41A7dEF2e06CD8F **rrETH:** 0x24957644116967962bF1f507e7aD9498836a0132 **rARB:** 0xC103b64Ae78AbDF2B643AA684440ef4CF3759B0B **rLINK:** 0x1F6cE88620326B146C47cCCD115D23EE48042b9F **rgmBTC-USD:** 0x97A786fA951712AB10c16681A5AcD9FabCEa285E **rgmETH-USD:** 0x7fa17fad637bbE6b58E6CEc266687006e137BCe7 **rGLV \[WBTC-USDC]:** 0x5496524C97c5Dd5F03d3a53179138a2dC1E17D88 **rGLV \[WETH-USDC]:** 0xcBB44D744a12676797033bBd65c6b3D61F02f183

Variable Debt-Bearing Tokens

**vdWBTC:** 0x2cECa734Ae0A437314a73401Db89a2560584b17F **vdwETH:** 0x330243dcBd91AcDD99b73a7C73c8A46e47FE386c **vdUSDC:** 0x7bF39AF1Dd18D6dAfca6B931589eF850F9D0Be25 **vdUSDT:** 0xe0499561642AFf7a149f59Cc599484d9D2dC60DA **vdwstETH:** 0x78587e08e71a65976e98E4eef9f3337a1dFB6eBA **vdweETH:** 0x04f2a8F7fCC86cdDCCA89e1EA98F333Cc072FB95 **vdrETH:** 0x9D4179826950a36a46144AEdB51269cA6c4ae87b **vdARB:** 0x60a60E28fD7E44c60c4087837716374b14C7450D **vdLINK:** 0x469be5f178c3b4BC43F8ac420958d58f8889E5F8 **vdgmBTC-USD:** 0x29ADEE4bDe1F1b8Faf278806e3974F22Fae64f01 **vdgmETH-USD:** 0x2b2B3D665e88d78B47615e7d43B298A39135268F **vdGLV \[WBTC-USDC]:** 0x1b103f61765b72AFD2d6B64876FbE0Db5cF4f416 **vdGLV \[WETH-USDC]:** 0x7f93220B3c307B428DbB7a90aC56BceE3B257B64

* **stableAndVariableTokensHelper:** 0x5Eb35e64f2F63E2e02E0496901A257E387A17F29 * **aTokensAndRatesHelper:** 0x59599097Ed7f03382765BcdB2749f642068c8031 {% endtab %} {% tab title="RIZ" %} **rizLockZap:** 0x1d6284c9233d932ac20d567f4d57c0980b64805b **rizWethGateway:** 0x0aee9aefa6de71ca84b01019b24579901339f617 **rizRegistry:** 0xb89546c5aa3b9d5BD1DEaB4474871455F9cc9841 **rizOracleRouter:** 0xacA72b23081f3786159edbca8e5FD2Ae71171C69 **rizLeverager:** 0x964c5cce247aad3f2abc10df0ea39e378fc6a870 **rizYearnV3VaultFactory:** 0x533597ae474ccc102a5bc5a291b50874f7043b39 **rizVaults:** 0xAd891B468995F5e0a767d5ecED3DDD490f486dD5 0x436705ffEEfDE180Ddc4F1cB09C5d8fFf32BB52f ### **Tokenization**

ZRO/USDC

**rzZRO:** 0x6636f59f7c7548B18eafb870f362d795e16a1F5C **rzVdZRO:** 0x695fDA202E10C4cD4Db7909FCA5a138Ed4A24761 **rzUSDC:** 0x1d4Dd351de6Ce43968Ad172e744DF87f54cFdCA1 **rzVdUSDC:** 0xf6CEc0cd09D7e5F0C7A29d184d394D9205cbdEEa **rizLendingPoolAddressesProvider:** 0xFfd5D4606Fc44F80E58F755d3D2198968e293344 **rizLendingPool:** 0x32F9460386A842E43E3e09fA92Bb77412Aabf42B

RDNT/USDC

**rzRDNT:** 0x90f4DcF7bA3A9979804E9bbd7E4fB28DBEd6a434 **rzVdRDNT:** 0x03bfEB196EE98639823F2cAbadE6b1e132e41d63 **rzUSDC:** 0x57f112D51f4329bdf54Fb200bf29c5a8A096F35D **rzVdUSDC:** 0x09aE0d1Eb239c980cA3fD369E79133586fF8eE28 **rizLendingPoolAddressesProvider:** 0x35DCFeCB7Bcc122766Fc5ed9c5e334377a6402C8 **rizLendingPool:** 0x0C19836CcD6eAcb9E21693e1f27bde10218b6701

rsETH/WETH

**rzrsETH:** 0x1260c7d9612503d517629d01F2b67e32BDD92c60 **rzVdrsETH:** 0x4C3be75431AeA6faCA899cd4E176d707f89357A2 **rzWETH:** 0x42c487738111689331b4BFe59DE42b22f8C00eB6 **rzVdWETH:** 0xdFB736fE0c4a3437203Bd6815A05Bf17A645d631 **rizLendingPoolAddressesProvider:** 0x43C7F97E9A6056C6BA9140DD1e2DDCF5051441Fe **rizLendingPool:** 0xf3007F6d241EbF00140b94D92849B5ACf0D36133

ezETH/WETH

**rzezETH:** 0xf4a3B4aECE09EaC774f679FD7113EF9A60bc6E25 **rzVdWETH:** 0xafEA6c16a870FA08cCd9885A5955681e12Bfb5aD **rzWETH:** 0x3f1b4266FC2093dEE636222a40F4ae9A288b8fbe **rzVdezETH:** 0xB3cCC556c1f4502C1760096192C271BBaa50624E **rizLendingPoolAddressesProvider:** 0x368633123723CDbB711da83Fc6Fe7Ed918a4ad7F **rizLendingPool:** 0x3fEc9583827431F622A4b188b6c57CfFE8655b8e

PT-wstETH/WETH

**rzPT-wstETH**: 0x26545042f0D6284D9D9e45E45D7FD67318a8F1AE **rzVdPT-wstETH:** 0x462d403fdF4B9b0d34C240856c16fda684F7086E **rzWETH:** 0x5886Dd993f098a1f90b46a0523D2918abB8B8F33 **rzVdWETH:** 0x0B0Cf1ebC5d78056E58D7a7FCDDaab9463117088 **rizLendingPoolAddressesProvider:** 0xc4dA16B15c60952dE0a4CD459f42FC634462b689 **rizLendingPool:** 0x6EF47f768aeAe173712Fe6a662666B1DBB08c66F

GMX/USDC

**rzGMX:** 0x2bBEc6CAae9c55DCdBC61F5E5e79D0Bb74840499 **rzVdGMX**: 0xB0740361249d49866D2aA04178f75B098BcA6c89 **rzUSDC**: 0x0135e5b758f707c5D3583A365FB872D4582E6256 **rzVdUSDC**: 0x33c53f967535EFB642DB59B72dB890db40D7c76E **rizLendingPoolAddressesProvider:** 0x58a2d3774aDC5C44f8B5DBa943DefB86dD213a35 **rizLendingPool:** 0x6B712099ab3Eb192F11E4964b35De8BAA7b15299

gmARB/USDC

**rzgmARB:** 0xA1e8BcA313700aDD1f7bC2a70D64461c682e2Cdf **rzVdgmARB:** 0x93616BAF75269F5931EFbaD23de622b7B0833313 **rzUSDC:** 0x5E3f9EC5594CDE166EbE456E90524B5335f3C8A3 **rzVdUSDC:** 0xa7e55539FB9bD15C2c715F7E245F8cFd2a8BB8F5 **rizLendingPoolAddressesProvider:** 0xd2dFe8487feF1361242b295013E29f6cfcA822bA **rizLendingPool:** 0x6B392CeBb1C7f0D93D8CF99a25A21C118b347a16

USDC/USDY

**rzUSDY:** 0xb128F5c6cA0198eF404e017ACbC2ea2a8c08646D **rzVdUSDY:** 0x7ab720c90358569e3F84f8440785035Ae7FaD835 **rzUSDC:** 0xa0EF0A3f9C5e56f69315e874334e94d100dc9FeB **rzVdUSDC:** 0x4262B874C32C55C370AaD76632486362A99F7423 **rizLendingPoolAddressesProvider:** 0xf4664E39dB8f0A5812c5C6753BFd5d19863A104E **rizLendingPool:** 0x16910EC43fe08190aD228910B58656243c675822

{% endtab %} {% endtabs %} ### Miscellaneous * **aaveOracle:** 0xC0cE5De939aaD880b0bdDcf9aB5750a53EDa454b * **oracleRouter:** 0xacA72b23081f3786159edbca8e5FD2Ae71171C69 * **aaveProtocolDataProvider:** 0x596B0cc4c5094507C50b579a662FE7e7b094A2cC * **lendingRateOracle:** 0xec21Dd035aE1712b070AEcBDCa2A82226856B716 * **priceProvider:** 0x76663727c39Dd46Fed5414d6801c4E8890df85cF * **daoTreasury:** 0x750129c21c7846CFE0ce2c966D84c0bcA5658497 * **lockZap:** 0x1d6284c9233d932ac20d567f4d57c0980b64805b * **lpLockerList:** 0xc23ad41516b6892BB304ADA420c84933096188b8 * **bountyManager:** 0x90aBACEC5dEEFf349223EeA076c946C2A630B672 * **compounder:** 0xb2c2c72F57864BAca7BDA6Bcb5965Ab8f58F9610 * **baseAssetWrappedAddress:** 0x82af49447d8a07e3bd95bd0d56f35241523fbab1 * **wrappedBaseDebtToken:** 0xab04c0841f39596C9F18A981a2BD32F63AB7a817

Chainlink Adapter Price Feeds

**RDNT/USD:** [0xF7273Dc8D9734A9970c34737aB7F79ba267fd590](https://arbiscan.io/address/0xF7273Dc8D9734A9970c34737aB7F79ba267fd590#readContract) **WETH(ETH):** [0xaA063e3829B290565D81A38Eb69De2e24f2733f3](https://arbiscan.io/address/0xaA063e3829B290565D81A38Eb69De2e24f2733f3) **WEETH/ETH:** [0xfb79a6dE19de885a1ABb874F3c47fcf0640821A2](https://arbiscan.io/address/0xfb79a6dE19de885a1ABb874F3c47fcf0640821A2) **gmBTC-USD:** [0x52CF59B29d0aCfdC408fFF10787464b4092AaF43](https://arbiscan.io/address/0x52CF59B29d0aCfdC408fFF10787464b4092AaF43) **gmETH-USD:** [0xb17E149f1f68bb7c7B7a416897C4EFC24144434a](https://arbiscan.io/address/0xb17E149f1f68bb7c7B7a416897C4EFC24144434a) **USDC:** [0x79dB438d44547A88C4d90d5b6F19b9b4ce06bff3](https://arbiscan.io/address/0x79dB438d44547A88C4d90d5b6F19b9b4ce06bff3) **USDC.e:** [0x79dB438d44547A88C4d90d5b6F19b9b4ce06bff3](https://arbiscan.io/address/0x79dB438d44547A88C4d90d5b6F19b9b4ce06bff3) **USDT:** [0xdBE63126Fe779027F1275Ef6DA42AB3a69F69129](https://arbiscan.io/address/0xdBE63126Fe779027F1275Ef6DA42AB3a69F69129) **DAI:** [0x6cF2Ab7B96a5274E6473337725244cFFA969722c](https://arbiscan.io/address/0x6cF2Ab7B96a5274E6473337725244cFFA969722c) **wstETH/stETH:** [0x696d363A2c3FF49ca99EE8D11fa5bC79EA86Ffb5](https://arbiscan.io/address/0x696d363A2c3FF49ca99EE8D11fa5bC79EA86Ffb5) **stETH/USD:** [0x3a8009653e9e64De0B2561aD7690D5cFa9CFb18b](https://arbiscan.io/address/0x3a8009653e9e64De0B2561aD7690D5cFa9CFb18b) **WBTC:** [0x8b9E71A8105F540AAd40030E3C812266DD87163C](https://arbiscan.io/address/0x8b9E71A8105F540AAd40030E3C812266DD87163C) **ARB:** [0x78b3a255CA0724bf7994F85cE0f38f8A73bf6fd9](https://arbiscan.io/address/0x78b3a255CA0724bf7994F85cE0f38f8A73bf6fd9) **Generic adapters:** **weETH/USD** - [0xd257BFa496efFd91c0b0fC7250617Bf74A2Ef3c3](https://arbiscan.io/address/0xd257BFa496efFd91c0b0fC7250617Bf74A2Ef3c3) **wstETH/USD** - [0x818a3BB1281eBA6A30dbe752b6BA48981acFB0](https://arbiscan.io/address/0x818a3BB1281eBA6A30dbe752b6BA48981acFB031#readContract)

## Peripheral Contracts ### Rewards * **middleFeeDistribution:** 0xE10997B8d5C6e8b660451f61accF4BBA00bc901f * **multiFeeDistribution:** 0x76ba3eC5f5adBf1C58c91e86502232317EeA72dE * **chefIncentivesController:** 0xebC85d44cefb1293707b11f707bd3CEc34B4D5fA * **revenueManagement:** 0xf48ccab0a329d5469b556668ca00ec87b6fe5b5f ### Misc * **wethGateway:** 0x8a8f65cabb82a857fa22289ad0a5785a5e7dbd22 * **walletBalanceProvider:** 0x6AC30E227468773AF2F70cD0F3A0375520885610 * **uiPoolDataProvider:** 0x56D4b07292343b149E0c60c7C41B7B1eEefdD733 * **eligibilityDataProvider:** 0xd4966DC49a10aa5467D65f4fA4b1449b5d874399 * **leverager:** 0x196bF3A63c50BcA1Eff5A5809B72DFc58F0C2c1a * **migration:** 0x3f1b4DaE9C5cC45fCbadb14bE6B2687f387818f9 ### Stargate * **stargateRouter:** 0x53Bf833A5d6c4ddA888F69c22C88C9f356a41614 * **stargateBorrowV2:** 0x326f4071935308123725f91282af44473659afad ### GuardianLP (gLP) Contracts * **GLPVault:** 0xc0E823Efcef47aeB0CA4b1362C6c8Db582d04078 * **GLPStrategy:** 0xB0fF86c7eBe95DcBf106178A82B57dd0A1a053d7 * **OracleRouter:** 0x8e9554649863108F6f87eCf959D2F69618827118 * **RDNT/WETH Inverse Oracle:** 0x04bFea605e8615aE42cB8d8FffAD78f113686681 ## Radiant Isolated Market (RIZv2) Contracts * **adaptiveCurveIrm:** 0xBF61206266e770b5D54480995eA8130F7B33c703 * **chainlinkOracleV2Factory:** 0x54ac958B628156A3B0c340896C64bf23721Fb778 * **fixedRateIrm:** 0xCd34bFC317089303531b45771C0D3CB797836A3E * **radiantLendingMarket:** 0x41e5585496c6e43d9fD548B5F88fC2d90D67aE38 ## Radiant v1 Contract Addresses ## Primary Tokens The RDNT token and wETH/RDNT LP contract addresses are as follows: * **rdntToken:** `0x0C4681e6C0235179ec3D4F4fc4DF3d14FDD96017` * **stakingToken (Pool2 LP):** `0x24704aFF49645D32655A76Df6d407E02d146dAfC` The subsequent contracts are divided into two categories: 1. **Core Contracts:** core protocol contracts that contain the logic for supply, borrow, liquidation, aTokens, pool configuration, oracles and interest rate strategies 2. **Peripheral Contracts:** rewards, UI data provider, incentive data provider, wallet balance provider and wETH gateway ## Core Contracts ### Configuration * **PoolAddressProvider:** `0xe21B295ED46528eFD5F3EF66E18BC6ad1c87f003` * **PoolAddressesProviderRegistry:** `0x7BB843f889e3a0B307299c3B65e089bFfe9c0bE0` ### Pool Logic * **lendingPool:** `0x2032b9A8e9F7e76768CA9271003d3e43E1616B1F` ### Tokenization

rTokens

**rWBTC:** `0x4cD44E6fCfA68bf797c65889c74B26b8C2e5d4d3` **rUSDT:** `0xEf47CCC71EC8941B67DC679D1a5f78fACfD0ec3C` **rUSDC:** `0x805ba50001779CeD4f59CfF63aea527D12B94829` **rDAI**: `0x5293c6CA56b8941040b8D18f557dFA82cF520216` **rWETH**: `0x15b53d277Af860f51c3E6843F8075007026BBb3a`

Variable Debt-Bearing Tokens

**WBTC:** `0x0e16bAE17C61789d8a96Ea6529d788B633C4c8B6` **USDT:** `0x9C3A8644A9cA181b90094be98dC19496F6b38a24` **USDC:** `0xf92d501e74bd1e4308E6676C38Ab4d84389d7Bf3` **DAI:** `0x2E9B46867469350E4889c280f74Bfa55Ca44fcd4` **WETH:** `0x4e75D4bc81D9AD1a1abc972a3dd53d581e1CE16b`

* **stableAndVariableTokensHelper:** `0x0f9819516EaDFC947E652710E3dbF738D6c1772B` * **aTokensAndRatesHelper:** `0x987553Cfa824b6AFe80191723ABee285E86f273f` ### Miscellaneous * **aaveOracle:** `0xFf785dE8a851048a65CbE92C84d4167eF3Ce9BAC` * **aaveProtocolDataProvider:** `0xa3e42d11d8CC148160CC3ACED757FB44696a9CcA` * **merkleDistributor:** `0xEFAB5C6F57F301f87875b3270bB4659e27a23A82` * **lendingRateOracle:** `0x795aDa2E75BE36b40aD43e35bdD8253890fd3F79` ## Peripheral Contracts ### Rewards * **masterChef:** `0xc963ef7d977ECb0Ab71d835C4cb1Bf737f28d010` * **multiFeeDistribution:** `0xc2054A8C33bfce28De8aF4aF548C48915c455c13` * **chefIncentivesController:** `0x287Ff908B4DB0b29B65B8442B0a5840455f0Db32` ### Misc * **wethGateway:** `0xEBF9746aF2c757A20Db467b007F4Fa6317385E9a` * **walletBalanceProvider:** `0xE36D523Ad4feBAa09B9Bc043999252f96375C621` * **uiPoolDataProvider:** `0xC8e3beDF35F23037A1067f6ED72625CAF72FA5D8` * **quicklock:** `0x75206c2A29B646706C8856dF0E8aCAEa38921BAd` * **leverager:** `0x5682A39078eDcE41a65F1Bd8733bf9Ca2BBE3B1b` * **timelock:** `0x0b6F135db3A621AB9041AC261276D8F38E1dC7a9` ### Stargate * **stargateRouter:** `0x53Bf833A5d6c4ddA888F69c22C88C9f356a41614` * **stargateBorrow:** `0xED60Be096713DE7C98558D4e5206BDB397f1f68f` # Base Contracts Radiant v2 Contract Addresses ## Primary Tokens The RDNT token and RDNT/ETH LP contract addresses are as follows: * **rdntToken:** [`0xd722E55C1d9D9fA0021A5215Cbb904b92B3dC5d4`](https://basescan.org/token/0xd722e55c1d9d9fa0021a5215cbb904b92b3dc5d4) * **stakingToken (Univ3 dynamic 80/20 LP):** [`0x8A76639FE8e390Ed16eA88f87BEB46d6A5328254`](https://basescan.org/token/0x8a76639fe8e390ed16ea88f87beb46d6a5328254) {% hint style="warning" %} **Disclaimer** The staking token on Base is initially deployed at a 50/50 full range, with plans to shift to an 80/20 range (in alignment with the Arbitrum and Mainnet Balancer configurations), and implement an automated pool manager.\ \ Click [here](https://docs.uniswap.org/concepts/protocol/concentrated-liquidity) to learn more about Univ3 concentrated liquidity. {% endhint %} {% hint style="danger" %} The **only** way to obtain eligible dLP tokens on Base is via zapping through Radiant's front end.\ \ **DO NOT** create liquidity directly on Aerodrome, as their returned NFT is not compatible with the RDNT protocol and it **will not** allow you to earn protocol revenue or RDNT rewards. {% endhint %} The subsequent contracts are divided into two categories: 1. **Core Contracts:** core protocol contracts that contain the logic for supply, borrow, liquidation, aTokens, pool configuration, oracles, and interest rate strategies 2. **Peripheral Contracts:** rewards, UI data provider, incentive data provider, wallet balance provider, and wETH gateway ## Core Contracts ### Configuration * **PoolAddressProvider:** 0xe7f252D19AB96254144Fbb0D94ebC0ff7EA0C541 * **PoolAddressesProviderRegistry:** 0x3eAF348Cf1fEC09C0f8d4f52AD3B8D894206b724 * **PoolHelper:** 0x871515966a41b43b7222b118071EaBa4AFB20121 ### Pool Logic * **lendingPool:** 0x30798cFe2CCa822321ceed7e6085e633aAbC492F {% tabs %} {% tab title="Core" %} ### **Tokenization**

rTokens

**rUSDC:** 0xC2dDb87Da8F16f1c3983Fa7112419A1381919b14 **rWETH:** 0x47CeFa4f2170e6CbA87452E9053540e05182A556 **rcbWETH:** 0x20508bA938fEdaE646FCAd48416bC9B6a448786E **rwstETH:** 0x43095e6e52A603FA571DDE18a7A123ec407433fE **rweETH**: 0x223A4066bd6A30477Ead12a7AF52125390C735dA **rcbBTC:** 0x633eBD78E0eBE2ff2e2E169a4010B9Ca4f7bCAa1 **rEURC:** 0xCF2170F09De0DF8454c865d972414F5bE696CF89 **rLBTC:** 0x6F77BE7bBd7c24565a68781030341a7E3DB2946a

Variable Debt-Bearing Tokens

**vdUSDC:** 0x392376C337413ce2e9ad7dD5F3468Ae58F323B00 **vdWETH:** 0x2455485C868C94781AA25f3fe9a5F9A6771D659C **vdcbWETH:** 0xf349787feD9c02bB7D4928FBc2c3d51A38ED7FbB **vdwstETH:** 0xb8EB4737c7dA019F26a297C8020F024BAA0c61D7 **vdweETH:** 0x73a53a1d90FC37bC6EF66e25C819976CC2ad7D22 **vdcbBTC:** 0x40eb2d8E246915d768a218880CC52BC6993Dc2b4 **vdEURC:** 0x7A2D83558c405D7179843C338644a22e7e5bA28A **vdLBTC:** 0xdD8FF03a171e976fb5624e9Ebc1d397cB242c4BE

* **stableAndVariableTokensHelper:** 0x94eC3843260028557cE3Be0AAc7aef6EA1DB1f53 * **aTokensAndRatesHelper:** 0xFe6c435194A395C09Ec95712500105943D5829e7 {% endtab %} {% tab title="RIZ" %} **rizLockZap:** 0x424e6047132889a20f67c5157D11FBc0f45b51E9 **rizWethGateway:** 0xa044B4A72a3257e92419b0E9CAf45D95ee415A97 **rizRegistry:** 0xB6bD1026DE7e5013352a41E58B6Cc53bC571fEE4 **rizOracleRouter:** 0x211DD83F6e49fd63c8Db4dbAeA5358256ACfB350 **rizLeverager:** 0x44dB23CC21b2d3909b0F282FE3b881F54CAF03DD **rizYearnV3VaultFactory:** 0x2eeEdF53e4Ed0a4a3d364FC95B364DF5c56223d1 **rizVaults:** 0x7BB8b0B176199B3313642dDe3421E38E548D6570 **Tokenization**

AERO/USDC

**rzAERO:** 0x3c86F81F7E1C19e91B6Fae6a78e5139b409BE13f **rzVdAERO:** 0x9b87611090468D8C4500E6C93eA675FCe96838E7 **rzUSDC:** 0x1fE5c3d7F4E8CFd6FA2F5caFA4B00e400F13cE77 **rzVdUSDC:** 0x0A81e46aD1c375bc465C7B19063e1dB5E32d0d5f **rizLendingPoolAddressesProvider:** 0x61CBCE4Fc0cD218Dbd187735399CF3ED98139fEb **rizLendingPool:** 0x260000459E0D1C46ADE027e552ADc911E0742b50

wSuperOETHb/WETH

**rzwSuperOETHb:** 0xf82705AF427F969174003828fefD885F84303bac **rzVdwSuperOETHb:** 0x19ae04A5866c9Ddc56f7b6583e7B7561755CbE92 **rzWETH:** 0xF73aA4feCB70657fdafD92C7b93eAB7555BC25C3 **rzVdWETH:** 0x66c94f36a9B1682364102815A04F70632d6F5ec1 **rizLendingPoolAddressesProvider:** 0x88d875952a66a7CA396713744517d053Dc4cEf5b **rizLendingPool:** 0x520411c27a950B731e0D4D5350E0CAEa51b1426F

ZRO/USDC

**rzZRO:** 0x4b246d5e027EcAf2384123C6A873cE49bd07FC5C **rzVdZRO:** 0x5cD3824545e33A8758367Fb295AB3969B977A56f **rzUSDC:** 0x0B831Cf910C9C7A371ab8D984Cdc4e1811a4a2D1 **rzVdUSDC:** 0x26E1f27E11fF5D6a11B2D76677795DdF552c7212 **rizLendingPoolAddressesProvider:** 0x0496F4c03e810b7F640437Bc767f9B2209E454EF **rizLendingPool:** 0x17042A220b138b203f67fDF62fA7aDD8cB16ccAa

MAVIA/USDC

**rzMAVIA:** 0xaec174A7cdD94eD259a4d42029F965E02ab74F0b **rzVdMAVIA:** 0xEA04969ea6903819af6BeaadBA9b63Cc7313E2dD **rzUSDC:** 0x5555b63121C0EFE6CAA46Fdd97949557a9D2F4d1 **rzVdUSDC:** 0x9cE33D94e4B4387640F62eC31f3f3EAbC438d536 **rizLendingPoolAddressesProvider:** 0xfa584191f50C61f7FC160d3fA1419Ec0c936204F **rizLendingPool:** 0xD111c7DA1eBDf4D2fF2d234A61a806b03187CEC9

BRETT/USDC

**rzBRETT:** 0xB1C3d239FD29DEDA95e84841F5B282e81787f86b **rzVdBRETT:** 0xc98678756CB88D272171cFf1232CFD586Ff12121 **rzUSDC:** 0xd9e9fCEb75eeEd494104c51a77D148cFA72EecB5 **rzVdUSDC:** 0xef54AeDDb87eBc7f3fDbb65E332DF97E8CC9F6Fa **rizLendingPoolAddressesProvider:** 0x902A2760A0958288093498A74b416eB1C45eC2FE **rizLendingPool:** 0x02694DE4B5E0AB3bB9e27Fbd16e4a51E0ECE4cAC

{% endtab %} {% endtabs %} ### Miscellaneous * **aaveOracle:** 0xe373749cd9b2D379f7f6Dd595e5164498b922164 * **oracleRouter:** 0x211dd83f6e49fd63c8db4dbaea5358256acfb350 * **aaveProtocolDataProvider:** 0x07d2DC09A1CbDD01e5f6Ca984b060A3Ff31b9EAF * **lendingRateOracle:** 0x64eb9A7b70caC33c20Ae53f5b11834530c6553b4 * **priceProvider:** 0x8096240D997a25f3d11a2354659A16eA3886fcFF * **daoTreasury:** 0x2ab122a2703d02C2f12fb17B6Dd63f7F7c8a89aE * **lockZap:** 0xAD1640540CbF73b458A051eDc8768240F0412142 * **bountyManager:** 0x0fF1A27339B663515f31DA5DD7E8503E058D20b0 * **compounder:** 0xB905F3c95576Baa125c56e477D119DB9f9EABFB7 * **baseAssetWrappedAddress:** 0x4200000000000000000000000000000000000006 * **wrappedBaseDebtToken:** 0x2455485C868C94781AA25f3fe9a5F9A6771D659C * **multicall:** 0xcA11bde05977b3631167028862bE2a173976CA11

Chainlink Adapter Price Feeds

**RDNT/USD:** [0xE5980cB5d68fc31afB4ec372D85d7fBa1A72879d](https://basescan.org/address/0xE5980cB5d68fc31afB4ec372D85d7fBa1A72879d) **WETH:** [0x878120aec3ECB5A438f144d5583C7bE0a2F4cFaf](https://basescan.org/address/0x878120aec3ECB5A438f144d5583C7bE0a2F4cFaf) **weETH:** * **weETH/ETH:** [0xFcbd30fC8d8bd29AdFfcBFBF563d3AA97F34Dc3C](https://basescan.org/address/0xFcbd30fC8d8bd29AdFfcBFBF563d3AA97F34Dc3C) * **weETH generic adaptor:** [0x7703f93b43c5f722bdf3197B37EAf4291a8fA4c4](https://basescan.org/address/0x7703f93b43c5f722bdf3197B37EAf4291a8fA4c4) **USDC:** [0x95F0D37b536b8990df836284E83ecD83BB678548](https://basescan.org/address/0x95F0D37b536b8990df836284E83ecD83BB678548) **cbETH:** [0x897d572589F2ce883a8B4003A7a3e70a87213f5f](https://basescan.org/address/0x897d572589F2ce883a8B4003A7a3e70a87213f5f) **wstETH:** * **wstETH/stETH**: [0xB38F6e3a7916222F4053cB66ad5bf036e1310899](https://basescan.org/address/0xB38F6e3a7916222F4053cB66ad5bf036e1310899) * **wstETH generic adaptor:** [0xbFfc0F6159FFfEa2a8265c03353393e6c6bBfa](https://basescan.org/address/0xbFfc0F6159FFfEa2a8265c03353393e6c6bBfa0a)

## Peripheral Contracts ### Rewards * **middleFeeDistribution:** 0xC49b4D1e6CbbF4cAEf542f297449696d8B47E411 * **multiFeeDistribution:** 0xD87F8a52a91680c993ece968B281bf92505A3741 * **mtwRDNT**: 0xaBc44F1711C94CB72b96bf7dC24b567886359d71 * **merklDistributor**: 0x3ef3d8ba38ebe18db133cec108f4d14ce00dd9ae * **revenueManagement:** 0x4e8db0e4804bccd75e2833ca5aae9028226be2a6 ### Misc * **wethGateway:** 0x18baA31BA51c63B7D4Eb4cB15870DDdc8918900a * **walletBalanceProvider:** 0xd3c1AC5a3AeA3857C4C9e894C7B07eFAC50E1504 * **uiPoolDataProvider:** 0xE3809A8Ba9C5592D9Dfe5b2500cCeDB6b3f9996C * **eligibilityDataProvider:** 0x376B59c8C944fDd414551934eD542e7f4A1ed5A1 * **leverager:** 0x630AC6B80Ac752BbfA70070372Ccfe2B70097D56 ### Stargate * **stargateRouter:** 0x45f1A95A4D3f3836523F5c83673c797f4d4d263B * **stargateBorrowV2:** 0x68a703683916e98133dfdd646e3f249a8169c03c ## Radiant Isolated Market (RIZv2) Contracts * **adaptiveCurveIrm:** 0xcd4b353a836ca04C88E0720599A7aAE738811b3A * **chainlinkOracleV2Factory:** 0xFA59e235d10a69006F80Aa112ED67b185b30747E * **fixedRateIrm:** 0xfB4C972e3E5e7D0140cdf4FFb8a1C61b9d215fe3 * **radiantLendingMarket:** 0x5D64926bEF21BD772e7d6F89AED16d8c1A93dD66 # BNB Chain Contracts Radiant v2 Contract Addresses ## Primary Tokens The RDNT token and RDNT/WBNB LP contract addresses are as follows: * **rdntToken:** [`0xf7DE7E8A6bd59ED41a4b5fe50278b3B7f31384dF`](https://bscscan.com/token/0xf7DE7E8A6bd59ED41a4b5fe50278b3B7f31384dF) * **stakingToken (PancakeSwap 50/50 LP):** [`0x346575fc7f07e6994d76199e41d13dc1575322e1`](https://bscscan.com/token/0x346575fc7f07e6994d76199e41d13dc1575322e1) The subsequent contracts are divided into two categories: 1. **Core Contracts:** core protocol contracts that contain the logic for supply, borrow, liquidation, aTokens, pool configuration, oracles, and interest rate strategies 2. **Peripheral Contracts:** rewards, UI data provider, incentive data provider, wallet balance provider, and wETH gateway ## Core Contracts ### Configuration * **PoolAddressProvider:** 0x64A59e3a3A2D15D03E868618261aF12c3deee27c * **PoolAddressesProviderRegistry:** 0x16Cd518fE9db541feA810b3091fBee6829a9B0Ce * **PoolHelper:** 0x279E503B5cC11c733fA10d90eA10e93739ac47cb ### Pool Logic * **lendingPool:** 0xCcf31D54C3A94f67b8cEFF8DD771DE5846dA032c {% tabs %} {% tab title="Core" %} ### **Tokenization**

rTokens

**rBTCB:** 0xD083Fb8dB6Dbc83386dc20075BEc8D0722b3056B **rUSDT:** 0x9915A7389f8FB33f9b77d84119c06e8BFfB12BE4 **rwstETH:** 0x701810c95AA1521d56C2BE5848A1B15be5954Ec3 **rUSDC:** 0x15cc621cfD1D0527CE6894fc07D97B2C06520D57 **rBNB:** 0x40351090037b9c4f6555071e9B24A82B068F2c05 **rETH:** 0x36594B6C976d05A6fF442B38Cfc3eFe0C01E0359 **rwBETH:** 0xd456F6216cB098b7999c76BE4F58f5121BAd8be8 **rFDUSD:** 0xD319E074c789C978E92f20345Eb739b9A670e4d8

Variable Debt-Bearing Tokens

**vdBTCB:** 0xc589B9AE9E4aA780AF7a6BC2E9DE27a532B2A278 **vdUSDT:** 0xC1e02d3F3C7282Cc2D15fb6a5Cc40130427107b1 **vdwstETH:** 0x5cc83215C1E225105Fe787b6F21A884c75Aecf22 **vdUSDC:** 0x94B6F75cb5c5E01cDFd1396420B499F3a7496300 **vdBNB:** 0xf81c76A058Ed8962b4EAE814cd8339790BD7b4c8 **vdETH:** 0x7473D4Eddd1d78b7df950219003d1B9D74e3980f **vdwBETH:** 0x75CcD694D057086DB838e0cbE91E92223A6b5C55 **vdFDUSD:** 0x054321Fe1549502a702883712B70C48977a923bf

**stableAndVariableTokensHelper:** 0xFF20CDa9c69ADa06Ff0be5407FeC249Cce83074f\ **aTokensAndRatesHelper:** 0x35ac38492EBc88838446fE08084b3648BdFdA78C {% endtab %} {% tab title="RIZ" %} **rizLockZap:** **rizWethGateway:** 0x7a84c8B0751c5B31671737647884118b16eBB83D **rizRegistry:** 0xe534F7933cEcc2d80Da5272460daBCC3DD545831 **rizOracleRouter:** 0x1029A53C7e8e00Bf9272533CD1cbEc395073A165 **rizLeverager:** **rizYearnV3VaultFactory:** 0x3bb2506331ae4cb79c70a7fa1bf86ad5b4f6f973 **rizVaults:** 0x55e367eabbc252af7873397f4e25834845dffa47 **Tokenization**

CAKE/USDT

**rzCAKE:** 0x1F0Fa1433645ae6b8fb856525fC7cDEB610B21d6 **rzVdCAKE:** 0x080995a0f55fFE0Bd72Ed85286ca9b87Ba6e836e **rzUSDT:** 0x9DC7d038574F173130e416345195e9371f2d5F11 **rzVdUSDT:** 0x3D0b0Ac0EA0F1358173e184eA4E281Fe825371E3 **rizLendingPoolAddressesProvider:** 0xbE7C10bf9039Ca3F0A3BfA844A6Ee879bc4C0482 r**izLendingPool:** 0x8E4660b30d09C94Ea77795727c55d69799a9Abd1

FLOKI/USDT

**rzFLOKI:** 0x31d1E9c4fB3d5c30b33a66165ff41Ae892390598 **rzVdFLOKI:** 0x58bf1390a85479bBe357Acbf06a3E3111fe5F109 **rzUSDT:** 0x5da7403F86C8888e1A8c5eC4fc2d15140bFD7A4d **rzVdUSDT:** 0x3EF5d33B8C058B7d5082c09AaEB01333A0Fe8c29 **rizLendingPoolAddressesProvider:** 0xF2e9dD985929Fa37c990F4fae1905023640e36C2 **rizLendingPool:** 0x486a97Dd8341C7590238b583580C78DC9151B8a6

slisBNB/WBNB

**rzslisBNB:** 0xF8003E767508668f359d6157AcC6AcC4Eb205532 **rzVdslisBNB:** 0x339d7E0dBfF2b734bf24f3539558965002B3Ff29 **rzWBNB:** 0xdf155aF169C2e8b38C8f6b54b7E6b6555D4070e6 **rzVdWBNB:** 0x1E0629C3678c8573b282002Bea1dA8Cd402b30c8 **rizLendingPoolAddressesProvider:** 0xe986B0F64D97B0EA31542c2b05216326A00EeAEf **rizLendingPool:** 0xc4a09Dd3DcC7D95e0bD525eff7f2968514dE23b2

{% endtab %} {% endtabs %} ### Miscellaneous * **aaveOracle:** 0x0BB5c1Bc173b207cBf47CDf013617087776F3782 * **oracleRouter:** 0x1029a53c7e8e00bf9272533cd1cbec395073a165 * **aaveProtocolDataProvider:** 0x2f9D57E97C3DFED8676e605BC504a48E0c5917E9 * **lendingRateOracle:** 0x5AA499B2C2716CfcD47c2B992E1097958c64Deb0 * **priceProvider:** 0xfBA3335f443C1351aA7173F23767b6A9c94ac855 * **daoTreasury:** 0x23a06b7644405bE380ACC1be0Ff54eeBeEC69aEd * **lockZap:** * **lpLockerList:** 0x4d94a7a3A1F9eD87863160BE37A488804392Ce3C * **bountyManager:** 0xCBbd19e676D9B66bF139e2728Aa29DE783442ac9 * **compounder:** 0x8fe962Dd1f322780f2Cb0264eA1eDc8a1504C367 * **baseAssetWrappedAddress:** 0xbb4CdB9CBd36B01bD1cBaEBF2De08d9173bc095c * **wrappedBaseDebtToken:** 0xCbB96324f77a66e276f80B843ECdB3fADC551bfF * **multicall:** 0x44EfC05146f64711F1FeFcAe274af82d156b00Dc * **uniV2TwapOracle:** 0xb104e1106E8f8Ee7b55F2970336407e8bddD59Af ## Peripheral Contracts ### Rewards * **middleFeeDistribution:** 0xcebdff400A23E5Ad1CDeB11AfdD0087d5E9dFed8 * **multiFeeDistribution:** 0x4FD9F7C5ca0829A656561486baDA018505dfcB5E * **chefIncentivesController:** 0x7C16aBb090d3FB266E9d17F60174B632f4229933 * **revenueManagement:** 0x5E154d14F78fDAAEB1d6500dE1bDe54D8451BE19 ### Misc * **wethGateway:** 0xD0FC69Dc0e720d5be669E53b7B5015F6FC258Ac9 * **walletBalanceProvider:** 0xa04a72E1D93a327d54262E5D1Ccba99de6b8891B * **uiPoolDataProvider:** 0xFB99b206FDc28894437FBDfd0E709AfeC5E612b6 * **eligibilityDataProvider:** 0x7B45bc162804db31D12c0bcf3009fb161A7fEe6e * **leverager:** 0x7D1568eE8ad6f17e3529a183B7D57F2047bdDe36 ### Stargate * **stargateRouter:** 0x4a364f8c717cAAD9A442737Eb7b8A55cc6cf18D8 * **stargateBorrowV2:** ## Radiant Isolated Market (RIZv2) Contracts * **adaptiveCurveIrm:** 0x172E1f86277C9E7E2ec175c6B3D1d47576c11b3F * **chainlinkOracleV2Factory:** 0x735326b0b71A1645BBeA4B888aB679F7F253816F * **fixedRateIrm:** 0x784333de84F35BBBB996901f8b105496A8495174 * **radiantLendingMarket:** 0xcdc0E0A3685311a46FFb67f85Cd1ee717e8E645d # Ethereum Contracts ## Primary Tokens The RDNT token and wETH/RDNT LP contract addresses for Ethereum are as follows: * **rdntToken:** [`0x137dDB47Ee24EaA998a535Ab00378d6BFa84F893`](https://etherscan.io/token/0x137ddb47ee24eaa998a535ab00378d6bfa84f893) * **stakingToken (Balancer 80/20 LP):** [`0xcF7b51ce5755513d4bE016b0e28D6EDEffa1d52a`](https://etherscan.io/token/0xcf7b51ce5755513d4be016b0e28d6edeffa1d52a) The subsequent contracts on Ethereum are divided into two categories: 1. **Core Contracts:** core protocol contracts that contain the logic for supply, borrow, liquidation, aTokens, pool configuration, oracles, and interest rate strategies 2. **Peripheral Contracts:** rewards, UI data provider, incentive data provider, wallet balance provider, and wETH gateway ## Core Contracts ### Configuration * **PoolAddressProvider:** 0x70e507f1d20AeC229F435cd1EcaC6A7200119B9F * **PoolAddressesProviderRegistry:** 0xe969066F2cCcE3145f62f669F151c6D566068BA2 * **PoolHelper:** 0x57EDfed84F2D3Ce48C8702CcC8330a1358Ca7491 ### Pool Logic * **lendingPool:** 0xA950974f64aA33f27F6C5e017eEE93BF7588ED07 ### Tokenization

rTokens

**rUSDT:** 0x3c19d9F2Df0E25C077A637692DA2337D51daf8B7 **rUSDC:** 0x9E85DF2B42b2aE5e666D7263ED81a744a534BF1f **rWETH:** 0xd10c315293872851184F484E9431dAf4dE6AA992 **rWBTC:** 0xE57538e4075446e42907Ea48ABFa83B864F518e4 **rwstETH:** 0x83B3896EC36cB20cFB430fCFE8Da23D450Dd09B5 **rsDAI:** 0x473693EcDAd05f5002ff5F63880CFA5901FB50E8 **rrETH:** 0x03AB03DA2c5012855c743bc318c19EF3dE5Bc906 **rweETH:** 0x1d25Bd8AbfEb1D6517Cc21BeCA20b5cd2df8247c **rUSDS:** 0x8dD4D313dEd77c399fED700d54cBdea2c24227D6 **rtBTC:** 0x457885E79A6627318721f86d16601FB42f4aD052 **rUSDe:** 0xa6ea758C6e447b7c134Dd2F1c11187EaFf26279b **rUNI:** 0xE2A9e57B7A4A4F85BCa3AA2CDed9Ae98647066C9 **rPYUSD:** 0x24378AA0D97E3bD72bd0A0443306602DE4583456 **rsUSDe:** 0x25dE46b8491c43C88c9E615336210928CA64091C **rLBTC:** 0x37b64FC5BABDf70A027099FC7B75bF77a0b23e34 **rcbETH:** 0xA9F92E32a1c0c0bdc58EaE49585FFB2e3B8A99d2 **rcbBTC:** 0xdD4C49DAC41ED743052E9f7abaC316b76EE42e36 **rLINK:** 0x0B87dF21F2E093f779F846FE388d9688C343D5e7

Variable Debt-Bearing Tokens

**vdUSDT:** 0x2D4fc0D5421C0d37d325180477ba6e16ae3aBAA7 **vdUSDC:** 0x490726291F6434646FEb2eC96d2Cc566b18a122F **vdWETH:** 0xDf1E9234d4F10eF9FED26A7Ae0EF43e5e03bfc31 **vdWBTC:** 0x0184eB8A4d86ff250cB2F7F3146AeCC14ccb73A4 **vdwstETH:** 0xc8CBb48a0EED0e406bb52a5cC939358c0aB644A7 **vdsDAI:** 0xE491C1A4150E9925e8427bea4CDCBD250B730e5C **vdrETH:** 0x6a0e8b4D16d5271492bb151Eb4767f25cFc23f03 **vdweETH:** 0xcDE79c767826849e30AAe7c241c369FCe54dB707 **vdUSDS:** 0x85f97456D05bAFa87e09c75A7e8c8238Cfa9C9c7 **vdtBTC:** 0xB146DAcc41eE3bf5acDa69f232F32Db74f00570e **vdUSDe:** 0x8BeC003E9FEA2fF3B25ED7bcDa3A7280217A8385 **vdUNI:** 0xeC8218D3f2155bCD9DDF1E8d7F228864a2e052d9 **vdPYUSD:** 0xaC1bbb316c84B672a86AaBEc5d4ec53b8D26cE98 **vdsUSDe:** 0xa9f3915ed6d1473AeE84a3666155eA8A84719177 **vdLBTC:** 0x8715d51b9760EE99Cf4c623337EC5d673434cC3f **vdcbETH:** 0xb41bD965FD0954C3bd4EdAE1A9A07816788B657C **vdcbBTC:** 0xBA831825E3bC7CDaFb59cA02eD2b31A1232d3b33 **vdLINK:** 0x660fe1FAB4079D6abc335A117C8Fc4cB2db88375

* **stableAndVariableTokensHelper:** 0x82561c8FC58AD23d56C2502b8eC85497075bEEaF * **aTokensAndRatesHelper:** 0xeda11Af74749238E8A0988A2588C342367299712 ### Miscellaneous * **aaveOracle:** 0xbD60293fBe4B285402510562A64E5fCEE9c4a8F9 * **oracleRouter:** 0xa12059746f0673eb3a83b1192c37f0b07a0faab4 * **aaveProtocolDataProvider:** 0x362f3BB63Cff83bd169aE1793979E9e537993813 * **lendingRateOracle:** 0xb7FA311c6F62Dd73f794e7B4021333E79F3121D1 * **priceProvider:** 0x126bD00B8a0A8b7B230368902d6b0b619dB2784c * **DAO treasury:** 0xCD264F5D45E407770dEc2975337716779e47a8Fb * **lockZap:** 0x135271435886724607C3B21712f8031504f06909 * **bountyManager:** 0x73E40889b17962c27Da5F8f6f2A2E3A00D93C2d0 * **compounder:** 0xf81aE7E80f9fd04884F8f3089c7223cb3c75114b * **baseAssetWrappedAddress:** 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 * **wrappedBaseDebtToken:** 0xDf1E9234d4F10eF9FED26A7Ae0EF43e5e03bfc31 ## Peripheral Contracts ### Rewards * **multiFeeDistribution:** 0x28E395a54a64284DBA39652921Cd99924f4e3797 * **chefIncentivesController:** 0x14b0A611230Dc48E9cc048d3Ae5279847Bf30919 * **revenueManagement:** 0x8e0268c0c8c45691e4c62fdf8f440a47dd8a5e3f ### Miscellaneous * **wethGateway:** 0xf251030DAeA3F09ed7D118F57F4b91F281250527 * **walletBalanceProvider:** 0x6Dd4146aF75c021CDE2F7Cdd7494e55a928dABBD * **uiPoolDataProvider:** 0x83F523B2Af1599F718686D91F47E0dF64fC8312E * **eligibilityDataProvider:** 0x93AC0c301F41FDE042770e891a34B56b434f4BD6 * **leverager:** 0x77F6aBDE8bBf87c51A800C43e7b93A7EBDbA605f ### Stargate * **stargateRouter:** 0x8731d54E9D02c286767d56ac03e8037C07e01e98 * **stargateBorrowV2:** 0x07bac9a0db5233794d3c3d9a6291288c28673712 ## Radiant Isolated Market (RIZv2) Contracts * **adaptiveCurveIrm:** 0x63c5D47ef01abFa18f7Bb74c6B1A40FeCFdACcc1 * **chainlinkOracleV2Factory:** 0x043fff1bda86602652d3e3148D7EE0eF4E5D6D39 * **fixedRateIrm:** 0x533597Ae474cCC102a5BC5a291B50874f7043b39 * **radiantLendingMarket:** 0x6365632c91e53B7f96F53722aba1e17Aadf973aA # Scheme of Contracts Protocol overview prepared by Zokyo ### Zapping

### Lending pool, rTokens, MultiFeeDistribution

### Staking Flow

Locking mechanics & rewards MultiFeeDsitributor.Sol

### Withdraw expired Locks (dLP)

Withdraw expired locks MultiFeeDsitributor.Sol

### Mint earnings

### Withdraw earnings

### ETH zapping flow

### Loop deposits

### Stargate Integration

### Bounty System

### Uniswap Oracle

# DAO Reserve The Radiant DAO Reserve is a multisig wallet that, in accordance with [**RFP-2**](https://dao.radiant.capital/#/proposal/0xbdf3daeda12219b9d19acdbbb6a2b0be3faa741573c1b8ae325b3737e76e9d95), serves as a router for RDNT emissions. The Reserve is responsible for significant emissions allocation changes, as well as for the routing of extant emissions across current and subsequent chain deployments. {% hint style="info" %} **Radiant DAO Reserve Wallet:** 0x750129c21c7846CFE0ce2c966D84c0bcA5658497 {% endhint %} Given the immutability of the Radiant smart contracts, it was not possible for the DAO to simply make adjustments to emissions. RFP-2 was [proposed ](/radiant/governance/proposal-process)(and subsequently ratified by RDNT tokenholders) in order to allow for better granularity with emission rates. The Radiant DAO Reserve is governed by RDNT tokenholders and executed by a Council-directed *2-of-3* multisig.\ \ On March 21, 2023 - Radiant was notified that the DAO would be receiving 3,348,026 $ARB tokens from the Arbitrum DAO allocation. The Radiant DAO has yet to decide how these tokens will be utilized but is humbled and thrilled for the ability to participate in Arbitrum governance. # Security Timelock As a commitment towards the safety of our users and partners, we want to be transparent about the status of our smart contracts. Because Radiant was built on a similar framework to Aave and Geist, many of the core contracts are upgradable by the owner. To mitigate security concerns and foster transparency, all Radiant smart contracts are placed behind a timelock, with a 72-hours delay for any action. {% hint style="info" %} **Timelocks:** **v2-Core:** 0x27fC8f3Be99e9799FA1B720D471647E6662AFf92 **RIZ:** 0x1d12564407D6e8C418f2A76DEbeEe5af72e6355A {% endhint %} # Audits Radiant Capital has undergone multiple successful, top-to-bottom audits with some of the world's best auditing firms, such as Open Zeppelin, Blocksec, Zokyo, & Peckshield. {% content-ref url="/pages/mccXVekK2hbsCKftH5jr" %} [v2 Audits](/radiant/contracts-and-security/audits/v2-audits) {% endcontent-ref %} {% content-ref url="/pages/toDxhgyFcrxYpoJujGnN" %} [v1 Audits](/radiant/contracts-and-security/audits/v1-audits) {% endcontent-ref %} # v3 Audits ## Base - Dynamic Uniswap v3 - dLP The code base for the new dLP architecture has successfully undergone two comprehensive audits. You can find the BlockSec audit report here: {% file src="/files/b8ZcuCKwmlH5MP78sHnd" %} Additionally, the Pashov Audit Group report is available here: {% file src="/files/cNzgrwjlLiisD6BZn808" %} ## RIZ The RIZ codebase has undergone a thorough audit conducted by OpenZeppelin. The report can be found by clicking [here](https://blog.openzeppelin.com/radiant-riz-audit). # v2 Audits While Radiant v2 is primarily composed of the same codebase as Radiant v1 — the Radiant DAO takes safety & security seriously and tripled down on audits. Radiant conducted multiple top-to-bottom v2 audits with [Open Zeppelin](https://blog.openzeppelin.com/radiant), [Peckshield](https://github.com/peckshield/publications/tree/master/audit_reports/PeckShield-Audit-Report-RadiantV2-v1.0.pdf), and [Zokyo](https://github.com/zokyo-sec/audit-reports/blob/main/Radiant/Radiant%20Capital%20audit%20report_06_March.pdf) with zero unresolved critical or high issues. [BlockSec](https://github.com/blocksecteam/audit-reports/blob/main/solidity/blocksec_radiant_v2.0.pdf) was also hired for whitehat hacking with zero unresolved issues.

Founded in 2015, OpenZeppelin is the world leader in securing blockchain applications and smart contracts. Its bedrock open source Contract Libraries are a public good and industry standard for smart contract development.

BlockSec is dedicated to building blockchain security infrastructure. The team is founded by top-notch security researchers and experienced experts from academia and industry. **BlockSec** [**has published multiple blockchain security papers**](https://blocksec.com/#research) **in prestigious conferences, reported several zero-day attacks of DeFi applications,**[ **rescued crypto-currencies worth more than 14 million dollars by blocking multiple attacks**](https://blocksecteam.medium.com/proactive-threat-prevention-a-new-web3-security-paradigm-494722822ad5)**, and** [**secured billions of cryptocurrencies**](https://blocksec.com/audit)**.** BlockSec has collaborated with [MetaMask](https://github.com/MetaMask/eth-phishing-detect/commits?author=blocksecscamreport), [Compound](https://twitter.com/BlockSecTeam/status/1630596296506499074), [Cronos](https://twitter.com/cronos_chain/status/1626114206214025218), [Forta](https://twitter.com/FortaNetwork/status/1616475686381780992), [Tokenlon](https://blocksecteam.medium.com/blocksec-and-tokenlon-reached-strategy-partnership-2d488b6a12e3), [KeyStone](https://keystonewallet.medium.com/new-partnership-announcement-blocksec-keystone-c134e2469bf2), [Goplus](https://blocksecteam.medium.com/blocksec-and-goplus-reached-strategy-partnership-to-explore-the-field-of-web-3-0-security-ffa63fb9590), and more to secure the whole crypto ecosystem.

PeckShield was founded in 2018 by former Qihoo 360 Chief Scientist Xuxian Jiang, and major investors include Gaorong Capital. Team members are based in Hangzhou, Beijing, and San Francisco and consist of seasoned security professionals and senior researchers from world-leading security groups at companies such as Qihoo 360, Microsoft, Intel, Juniper, Alibaba, etc. PeckShield has established strategic and long-term cooperations with key players in all areas of the blockchain ecosystem, such as blockchain infrastructure vendors, exchanges, crypto wallets, mining pools, DApp developers, and DeFi pioneers. They have also attracted widespread attention from the industry since we have, among other things, discovered issues such as Ethereum smart contract BatchOverflow loophole, been included in the Etherscan.io recommended vendor list for smart contract security audit, and ranked Top 3 worldwide in the Ethereum Bounty Program.

Zokyo ("augment" in Japanese) provides blockchain security, design, and development talent to startups and enterprise organizations as needed. As a go-to web3 security, development, and investment partner working with some of the most progressive companies since 2019, they are highly experienced in tackling some of the most challenging problems with an entrepreneurial spirit. With immediate access to in-demand skills ranging from security auditing, cryptography, white-hat hacking, mathematical specifications of network design, UI/UX design, QA, and full-stack engineering. # v1 Audits ![](https://content.gitbook.com/content/c8CwAEN8ihh81y90gyG1/blobs/qxCXYK4MJdk9C0kmidkF/82627446_527231334810619_9086354892120915968_n.png) Radiant V1 has undergone a successful, top-to-bottom audit with [**PeckShield**](https://peckshield.com/), who reported no critical findings. The full report can be found here: {% embed url="" %} ![](https://content.gitbook.com/content/c8CwAEN8ihh81y90gyG1/blobs/SmD1ljw9TsMGIA8489YW/image.png) Radiant Capital has also completed an audit with **Solidity Finance**. The full report can be found here: {% embed url="" %} # Immunefi Web3's leading bug bounty platform, protecting $60 billion in user funds

In collaboration with [@immunefi](https://twitter.com/immunefi), Radiant has posted bug bounties with the scope of impact covering the v2 smart contracts and front end. While BlockSecTeam, Peckshield, and Zokyo have thoroughly audited Radiant v2, the DAO takes the safety & security of the protocol and users with the utmost priority. Bug bounty programs are open invitations to security researchers to discover and responsibly disclose potential vulnerabilities. {% embed url="" %} # Mission & Values The primary vision: unite the fragmented liquidity across multiple money markets and chains under one safe, user-friendly, and capital-efficient omnichain protocol. The mission, consequently, is to leverage the resources in the Radiant DAO to execute that vision. Analysis of all the money markets concluded that Geist Finance showed the most promise in the ability to bootstrap liquidity quickly--they raised \~$10bn TVL in less than two weeks. In addition, their protocol also provided stability and security of the Aave lending pool framework. Leveraging the Geist codebase provides a great foundation for the dev team to implement cross-chain functionality via the [LayerZero communications protocol](https://www.dropbox.com/s/gf3606jedromp61/Delta-Solving.The.Bridging-Trilemma.pdf?dl=0), as popularized by [Stargate](https://stargate.finance/). ### Safety & Governance Despite utilizing existing tech stacks, Radiant Capital took many months of development, audits, and rigorous testing. The team is small but nimble; a powerhouse of varying talents spanning multiple successful DeFi projects. As Radiant is based on Aave & Geist, many of the core contracts are upgradeable by the owner (as noted by the [Solidity Audit](/radiant/contracts-and-security/audits)). We understand that anonymous devs with the power to upgrade contracts may make some users uncomfortable. To mitigate these concerns, ownership of all Radiant smart contracts will be placed behind a timelocked contract with a two-day delay for any action. We will publish the address to this contract [prominently](/radiant/contracts-and-security/arbitrum-contracts), and inform the community before any admin-related actions involving the timelock. We encourage community members to monitor inbound transactions to the time lock. Ultimately, ownership will be passed entirely to the DAO. While we have taken every precaution to ensure the safety of user funds and instill confidence in the protocol, and despite Aave and Geist being operational without issue, this is all new technology and not without risk. **Do not deposit more than you can afford to lose.** The Radiant DAO is excited to usher in what we believe to be the optimal lending and borrowing platform in DeFi. Welcome to an omnichain future. Welcome to Radiant Capital. # Radiant Contributors As Radiant begins rolling out v3 and beyond, we're thrilled to share the team's expansion. The expanded team at Radiant is a fusion of diverse talents and backgrounds, each member bringing unique skills and experiences. As we gear up for the launch of Radiant v3 and beyond, we're not just focused on skating the cutting edge; we're committed to creating a platform that is accessible, secure, and capable of revolutionizing the way people interact with DeFi. ### Engineering

**DCota**, Senior Backend Developer, has a unique blend of experiences from co-founding FujiFinance, contributing to the Xocolatl MXN stablecoin, to his past career as an aerospace engineer. His vision of making lending protocols a standard in banking mirrors Radiant’s goal of making DeFi solutions more mainstream and user-friendly.

**Shak**, Senior Backend Developer, has been at the core of projects like BadgerDAO and Balancer, contributing significantly to the DeFi community’s growth. His enthusiasm for working alongside brilliant minds to build the future of decentralized economies is contagious and aligns perfectly with Radiant’s vision for v3.

**JD**, a Full Stack Developer, brings a diverse skill set from leading the tech department at Coin Bureau Recruitment to winning the SyncTheCity hackathon. JD’s enthusiasm for innovation and building exceptional products alongside talented individuals make him a perfect fit for the challenges and opportunities that v3 presents.

**Niko**, our Senior Product Designer, has an impressive portfolio from designing for large FinTech companies to building design teams from scratch at Series A startups. His passion for learning from the best and making DeFi understandable for the average person resonates with the Radiant DAO ethos.

**Shini**, joining as a Full Stack Developer, brings a unique blend of experience and insight from time spent at Defillama and Vestafinance. With a passion for enabling users to achieve financial independence and access previously inaccessible tools, Shini's vision perfectly complements Radiant's mission. ### *Other Contributors* **Director of Communications & DevOps PM**: (Hiring) **DAO Administrator**: Hung Vu **Social Media Manager**: Eliana **Support**: Konstantin, Owen, Frank ### *Advisors* [Andrew Kang](https://twitter.com/Rewkang) [Adam Cochran](https://twitter.com/adamscochran) [Avi Felman](https://twitter.com/AviFelman) [Ouroborous Capital](https://twitter.com/OuroborosCap8) [Jordi Alexander](https://twitter.com/gametheorizing) [Layer Zero](https://twitter.com/LayerZero_Labs) [Offchain Labs](https://twitter.com/OffchainLabs) [Binance Labs](https://twitter.com/BinanceLabs) # Frequently Asked Questions

What is Radiant Capital?

Radiant aims to be a "one-stop shop" money market, where users can deposit & borrow assets across multiple chains, seamlessly. The Radiant DAO utilizes the native utility token, **$RDNT.** By interacting and providing utility to the platform, users can capture the added value from the communities’ engagement through the native utility token **$RDNT** from borrowers and platform fees

Where are the verified contracts and were they audited?

The verified contracts may be viewed [here.](https://docs.radiant.capital/radiant/contracts-and-security/contracts) \ Radiant Capital is audited by [Blocksec](https://github.com/blocksecteam/audit-reports/blob/main/solidity/blocksec_radiant_v2.0.pdf), [PeckShield](https://docsend.com/view/4irymmv5uifge3tr), and [Zokyo](https://docsend.com/view/vcux2vysnzcehq9b). No critical or major security flaws were found.

Was there a seed round, presale or VC investment?

Funding for Radiant was bootstrapped entirely by the core contributors. All expenses have been paid out-of-pocket: development, multiple audits, marketing, salaries etc. \ There was no private sale, IDO, or VC involvement, which aligns with our ethos of decentralization with no bias.

Why is my health factor declining on borrowed assets?

Borrowed assets accrue interest that is paid from deposited collateral. Over time, this may lower one’s health factor. It is recommended to monitor your health factor and ensure it stays above 1. Deposit more funds or repay loans to increase your health factor and avoid liquidation. For more information, please review the [Health Factor](https://docs.radiant.capital/radiant/project-info/borrow/borrow-1) page.

What is looping & locking and what is the process to unwind a loop?

Looping is an automated process that provides an opportunity to earn a yield on a greater collateral value by repeating the deposit and borrow function with up to 4x leverage. The loop and lock function of Radiant may not execute if the selected leverage would cause your **health factor to drop below 1.11**. If the loop transaction fails to execute, lower your leverage using the sliding scale. \ Additionally, the loop & lock feature automatically ensures [dLP eligibility](/radiant/project-info/rdnt-tokenomics/liquidity-provisioning/eligibility). If a user is already eligible, zero ETH will be borrowed. As you can see in the video below, there will be zero ETH borrowed if a user is NOT required to add more dLP. If a user is ineligible for RDNT emissions, the loop & lock tool will automatically borrow the ETH necessary to zap into a locked dLP position to maintain the minimum 5% dLP requirement for activating RDNT emissions. \ \ Slippage is fixed at 5%. If a user wishes to reduce slippage, it is recommended to manually create dLP by visiting the [Balancer Pool directly.](https://app.balancer.fi/#/arbitrum/pool/0x32df62dc3aed2cd6224193052ce665dc181658410002000000000000000003bd) \ Lastly, the dLP will be locked for your Default Locking Length, which can be updated under the [Manage page.](/radiant/project-info/manage-radiant) Unwinding a loop is a **manual** process that requires the repayment of outstanding loans. This may require a few cycles of withdrawing deposited collateral to repay the loan while ensuring your health factor remains above 1. Alternatively, deposit more collateral, improve your health factor, then begin the manual unwind process.

What is the difference between vesting and locking RDNT?

RDNT emissions from lending and borrowing must undergo a 90-day vesting process. Users must actively initiate the vesting period in the “Manage Radiant” section. Users can claim their vested RDNT early for a 25-90% exit penalty at any point during the vesting process. Remember that you can not partially exit early– all currently vesting RDNT will be withdrawn with their respective exit penalties applied. Locked RDNT liquidity providers receive 60% of protocol fees and cannot be unlocked until the locking period has ended. For a full breakdown, visit the [**Manage Radiant**](https://docs.radiant.capital/radiant/project-info/manage-radiant-page) section of the GitBook.

What is zapping dLP?

Zapping allows you to form a locked RDNT liquidity position in one click using RDNT and ETH/BNB in your wallet, or borrowed from the money market.

How is daily revenue distributed?

Platform fees are distributed linearly over a 7-day period as they are earned. Daily revenue will fluctuate based on platform fees (borrowers paying interest on loans) and flash loan fees.

How is "Max dLP Lock APR" calculated from the Markets page?

**How is the "Maximum Lock APR" calculated?**\ **-** Definition: Maximum APR when dLP is locked for 1 year\ \- Calculation: 1 month lock APR \* 1 year lock multiplier (25x) **Example: 1 month locking APR:**\ \- Definition: Current locking APR for 1 month \ \- Calculation: (Total 1 Month Lockers’ Share of Annualized Protocol Fees) / (Total 1 Month Lockers’ Share of dLP Pool Size)

How is "Your Share" of dLP calculated?

*(User share of dLP \* user avg. dLP Multiplier) / (Total Protocol dLP \* Global Protocol avg. multiplier)*

How is "Average Multiplier" for locked dLP calculated?

The average multiplier is based on your lock length selected each time you perform a lock/relock or zap/auto-compound into dLP. *Calculation: For example, User 1:*\ *- Total: 2 dLP locked / 13x Avg. Multiplier*\ *- 1 dLP Locked for 1 year (25x multiplier)*\ *- 1 dLP Locked for 1 month (1x multiplier)*

How are "Total Annual Platform Fees" calculated?

Amount of projected protocol fees received by a user over the course of 365 days, based on an extrapolated 24h sample of Global Protocol Fees\ \ *Calculation: (User Daily Protocol Fees \* 365)*

How is "Your Current Lock APR" calculated?

Definition: User Specific Lock APR depending on Avg. Multiplier\ \ *Calculation: (Global 1 month Locking APR \* User Avg Multiplier)*

I claimed my revenue but only received rTokens, how do I retrieve my claimable fees? Where did the funds go?

rTokens are interest-bearing tokens represented as 'rXXXX' in your wallet (example: rUSDC for USDC). rTokens represent your deposited collateral within Radiant Capital. To convert them to the underlying asset, they may be withdrawn from the lending dashboard. It is recommended to not attempt to transfer or trade rTokens.

What is the difference between APY & APR?

For a more detailed explanation of the difference between APY and APR, [watch this video.](https://www.youtube.com/watch?v=rNDjgnDJd9A) For further details on the calculation of APY, please refer to Aave's documentation:

Why does the website occasionally not display certain data?

Like many companies, the Radiant DAO relies on Cloudflare to supply front-end data to the website. Unfortunately, Cloudflare has been subject to intermittent outages in recent weeks with its IPFS connectivity. This may cause the website to partially load, or not display certain data correctly at times. This has no effect on the actual protocol, funds, or smart contracts themselves. We recommend that anyone who has display issues periodically ctrl+F5 refresh the page cache and force a reload.

# Integrations

Radiant Capital is treading the frontier of Decentralized lending innovation by creating DeFi's first omnichain money market. Bridges built on the Delta algorithm of Layer Zero conduct native asset transfers through unified pools of liquidity while achieving instant-guaranteed finality, the combination of which enables cross-chain composability." [(Source: Layer Zero whitepaper)](https://www.dropbox.com/s/gf3606jedromp61/Delta-Solving.The.Bridging-Trilemma.pdf?dl=0) The flexibility afforded by the Delta algorithm creates the opportunity to improve many existing applications, such as decentralized lending protocols like Radiant Capital by taking advantage of single-transaction cross-chain swapping of native assets across vast networks of chains. Layer Zero has played an integral role in peer-reviewing Radiant smart contracts to ensure the highest level of security and interoperability. Therefore, in addition to Radiant's own audits, the protocol leverages Stargate's stable router interface, which has never been exploited. Stargate & Layer Zero combined have spent over $1 Million on audits to ensure bridge security. [Bryan Pellegrino](https://twitter.com/PrimordialAA), CEO of LZ, has [tweeted](https://twitter.com/PrimordialAA/status/1551377354475245569) about Radiant Capital.

Radiant Capital has a working relationship with the Chainlink team to ensure the highest level of security on the oracle price feeds. Chainlink enables dApps to reliably connect to any external API and leverage secure off-chain computation to unlock more advanced use cases. Radiant utilizes high-quality data from Chainlink price feeds to help secure its money markets. Chainlink currently secures tens of billions of dollars across DeFi, insurance, gaming, and other major industries.

Lido is the leading liquid staking solution - providing a simple and secure way to earn interest on your digital assets. By staking with Lido, your assets remain liquid and can be used across a range of DeFi applications, earning extra yield. Radiant has partnered with LIDO to allow lending and borrowing of wrapped staked ETH within the Arbitrum money market. ### *Arbitrum Official Portal* ![](https://content.gitbook.com/content/c8CwAEN8ihh81y90gyG1/blobs/8IlGGJbUBWcggMI3fSjE/portal.png) Radiant has been selected by Offchain Labs to be listed on the Arbitrum Official Portal. To qualify, Offchain manually screens projects, and only lists live projects which meet the following criteria: * The project is technically mature * Audit reports are provided * Offchain Labs has ascertained the identity of the team building the project by reference recommendations from upstanding members of the community that have shared mutual relationships with both Offchain Labs and the protocol ### *Balancer Labs*

Balancer is a decentralized automated market maker (AMM) protocol built on Ethereum that represents a flexible building block for programmable liquidity. By separating the AMM curve logic and math from the core swapping functionality, Balancer becomes an extensible AMM that can incorporate any number of trading curves and pool types, such as custom weights like 80/20 for controlled exposure being utilized by Dynamic Liquidity provisioning. \\ # Branding

{% file src="/files/wekYr7xjqxANmypG0HHa" %} {% file src="/files/dYInmQ64XpRpZaw485QH" %} {% file src="/files/yXKqL5rJv1iEsVNTW9xw" %} {% file src="/files/zcMWGFYfmpSxmq81AaxZ" %} {% file src="/files/VhBr00EWdXPRXL10RSGB" %} {% file src="/files/jrzrhwpikLOWu6JwPsGp" %} {% file src="/files/mB0iOhfLEs5VXuYrxf7d" %} {% file src="/files/adK0DJ3EWrkeX1FSDLdC" %} {% file src="/files/4AWeO53vboOmES1dgHdp" %} {% file src="/files/Au6YgUfNbdkut5VA17Pl" %} {% file src="/files/wqtea3EN1GTxfHvuqh7C" %} {% file src="/files/ionC4zsHc0uFQn0pSPe0" %} {% file src="/files/HmEwDVf3zbEzbmmncdQW" %} {% file src="/files/bXMm4F5KERuSIKMbwBEP" %} {% file src="/files/CqCOtddwoUad79dFSWWd" %} # Co-Marketing Guidelines We are thrilled to collaborate and excited to introduce you to the Radiant community! {% embed url="" %} # Terms of Service Last Updated: November 22, 2024 Please read these Terms of Service (the “***Terms***”) carefully because they govern your use of the website located at (the “***Site***”) ] and DeFi services accessible via the Site and corresponding application (“***App***”) offered by Supernova Holdings, Ltd (the “***Company***”, “***we***”, “***us***” or “***our***”). The App facilitates access to the Radiant Protocol, which we do not own or control (the “***Protocol***”). The Protocol is a community-driven, peer-to-peer set of blockchain-based smart contracts and tools that enable certain users to request to borrow cryptoassets (such users, the “***Borrowers***”) and certain other users to lend such cryptoassets (such users, the “***Lenders***”), in which Borrowers may place cryptoassets as collateral (each such transaction, a “***Loan***”) (Borrowers and Lenders, collectively, “***Users***”). To make these Terms easier to read, the Site, App, and our services are collectively called the “***Interface***.” {% hint style="danger" %} **NOTICE ON PROHIBITED USE – RESTRICTED PERSONS:** THE INTERFACE AND ANY RELATED SERVICES ARE NOT OFFERED TO AND MAY NOT BE USED BY: PERSONS OR ENTITIES WHO RESIDE IN, ARE CITIZENS OF, ARE LOCATED IN, ARE INCORPORATED IN, OR HAVE A REGISTERED OFFICE IN ANY RESTRICTED TERRITORY, [AS DEFINED BELOW](#3.-who-may-use-the-interface) (EACH SUCH PERSON OR ENTITY FROM A RESTRICTED TERRITORY, A “***RESTRICTED PERSON***”). WE DO NOT MAKE EXCEPTIONS. THEREFORE, IF YOU ARE A RESTRICTED PERSON, THEN DO NOT ATTEMPT TO USE THE INTERFACE OR ANY RELATED SERVICES. USE OF A VIRTUAL PRIVATE NETWORK (“***VPN***”) OR ANY OTHER SIMILAR MEANS INTENDED TO CIRCUMVENT THE RESTRICTIONS SET FORTH HEREIN IS PROHIBITED. {% endhint %} **WHEN YOU AGREE TO THESE TERMS, YOU ARE AGREEING (WITH LIMITED EXCEPTION) TO RESOLVE ANY DISPUTE BETWEEN YOU AND THE COMPANY THROUGH BINDING, INDIVIDUAL ARBITRATION RATHER THAN IN COURT. PLEASE REVIEW CAREFULLY SECTION 16 (DISPUTE RESOLUTION) BELOW FOR DETAILS REGARDING ARBITRATION.** **HOWEVER, IF YOU ARE A RESIDENT OF A JURISDICTION WHERE APPLICABLE LAW PROHIBITS ARBITRATION OF DISPUTES, , THE AGREEMENT TO ARBITRATE IN SECTION 16 WILL NOT APPLY TO YOU BUT THE PROVISIONS OF SECTION 15 (GOVERNING LAW AND FORUM CHOICE) WILL APPLY INSTEAD.** ### **1. Agreement to Terms** By using our Interface, you agree to be bound by these Terms. If you don’t agree to be bound by these Terms, then you must not use the Interface. Notwithstanding the foregoing, the laws of some jurisdictions may limit or not permit certain provisions of this agreement, such as indemnification, the exclusion of certain warranties or the limitation of liability. In such a case, such provisions will apply only to the maximum extent permitted by the laws of such jurisdictions. Also, you may have additional legal rights in your jurisdiction, and nothing in these terms will prejudice such rights that you may have as a consumer of the Interface under such applicable law. ### **2. Changes to these Terms or the Interface** We may update these Terms from time to time in our sole discretion. If we do, we’ll let you know by posting the updated Terms on the Interface and/or may also send other communications. It’s important that you review these Terms whenever we update them or you use the Interface. If you continue to use the Interface after we have posted updated Terms, it means that you accept and agree to the changes. If you don’t agree to be bound by the changes, you may not use the Interface anymore. Because our Interface is evolving over time, we may change or discontinue all or any part of the Interface, at any time and without notice, at our sole discretion. ### **3. Who May Use the Interface?** You may use the Interface only if you are at least 18 years of age (or such other minimum age at which you can provide consent to data processing under the laws of your territory), and not otherwise barred from using the Interface under applicable law. In order to protect the integrity of the Interface, we reserve the right, at any time, in our sole discretion, to block access to the Interface from certain IP addresses and unique device identifiers. For the purposes of these Terms, “***Restricted Territory***” means of Algeria, Bangladesh, Bolivia, Belarus, Burundi, Burma (Myanmar), Cote D'Ivoire (Ivory Coast), Crimea and Sevastopol, Cuba, Democratic Republic of Congo, Ecuador, Iran, Iraq, Liberia, Libya, Mali, Morocco, Nepal, North Korea, Somalia, Sudan, Syria, Venezuela, Yemen, Zimbabwe or any other country to which Canada, Panama, the United States, the United Kingdom or the European Union embargoes goods or imposes similar sanctions. ### **4. About the Interface** 1. **Interface.** The Interface provides Users with access to the Protocol, which is a fully decentralized, non-custodial, community-governed lending protocol deployed on multiple blockchain networks and systems, and provides information about the Company’s ecosystem, governance, community, and various interfaces and integrations to the Interface. All information provided in connection with your access and use of the Interface is for informational purposes only. You should not take, or refrain from taking, any action based on any information contained on the Site or any other information that we make available at any time, including blog posts, data, articles, links to third-party content, Discord content, Discourse content, news feeds, tutorials, tweets, and videos. Before you make any financial, legal, technical, or other decisions involving the Interface, you should seek independent professional advice from a licensed and qualified individual in the area for which such advice would be appropriate. Because the Interface provides information about the Protocol, these Terms also provide some information about the use of the Protocol. This information is not intended to be comprehensive or address all aspects of the Protocol. 2. **Our Relationship.** You acknowledge and agree that the Company is an online platform provider and not a broker-dealer or a Lender. The Company does not direct or control the day-to-day activities of the users accessing the Site. Neither we nor any affiliated entity is a party to any transaction on the blockchain networks underlying the Protocol; we do not have possession, custody or control over any cryptoassets appearing on the Interface; and we do not have possession, custody, or control over any User’s funds or cryptoassets. Further, we do not store, send, or receive any funds or cryptoassets. You understand that when you interact with any Protocol smart contracts, you retain control over your cryptoassets at all times. The private key associated with the wallet address from which you transfer cryptoassets or the private key associated is the only private key that can control the cryptoassets you transfer into the smart contracts. You alone are responsible for securing your private keys. We do not have access to your private keys. Due to the non-custodial and decentralized nature of the technology, we are not intermediaries, agents, advisors, or custodians, and we do not have a fiduciary relationship or obligation to you regarding any other decisions or activities that you affect when using our Interface. You acknowledge that we, for the avoidance of doubt, do not have any information regarding any Users, Users’ identities, or services beyond what is available or obtainable publicly via the blockchain. We are not responsible for any activities you engage in when using the Interface, and you should understand the risks associated with cryptoassets, cryptoassets, blockchain technology generally, and the Interface. The software underlying blockchain networks on which the Protocol is deployed is open source, which means that anyone can use, utilize, and build on top of it. By using the Interface, you acknowledge and agree (i) that we are not responsible for the operation of the blockchain-based software and networks underlying the Protocol, (ii) that there exists no guarantee of the functionality, security, or availability of that software and networks, and (iii) that the underlying blockchain-based networks are subject to sudden changes in operating rules, such as those commonly referred to as “forks”. 3. **Fees.** There may be associated fees in connection with transactions enacted on a blockchain. All transactions using blockchains require the payment of gas fees, which are essentially transaction fees paid on every transaction that occurs on the selected blockchain network. Please note that gas fees are non-refundable. 4. **RDNT Rewards.** You may receive token rewards in the form of RDNT. Revenue generated through Borrowers’ interest is distributed directly to Users who vest or lock RDNT, subject to certain vesting and locking conditions. You may use the Interface by linking your digital wallet(s) on a supported bridge extension, which allows you to purchase, store, and engage in transactions using supported digital assets. More information on RDNT, rewards, vesting and locking is available at . 5. **Liquidation.** Borrowers may lose some or all of their collateral in certain circumstances, including if their collateral value does not properly cover their loan/debt value (“***Liquidation***”). Upon Liquidation, Borrowers may also incur a penalty fee. Users may seek out loans that are eligible for Liquidation and pay back part of the debt owed in exchange for receiving discounted collateral. More information on Liquidation is available at . 6. **Communication from the Interface.** You may elect to receive emails or other communications from the Company in connection with the Interface. If you elect receive communications in connection with your Loan, you agree and acknowledge that the Company is under no obligation to send any emails or communicate with you regarding such Loan or the expiration of such Loan, and that the Company will not be responsible or liable to you for any loss and takes no responsibility for and will not be liable to you for in the case of failure of such email or communication. 7. **Disputes Between Borrowers and Lenders.** The Company is not a party to any relationship between any Borrowers and/or Lenders or in the delivery or completion of borrowing/lending transactions. In the event that you have a dispute with any user of the Site, including any Borrowers or Lenders, you agree to address such dispute directly with such user. If permitted in your jurisdiction, you release the Company (and the Company’s officers, directors, agents, investors, subsidiaries, and employees) (collectively “**Releasees**”) from, and covenant not to sue Releasees for any and all claims, demands, or damages (actual or consequential) of any kind and nature, known and unknown, suspected and unsuspected, disclosed and undisclosed, arising out of or in any way connected with such dispute. As a Lender, to the degree that any collateral placed by a Borrower is a fraud, scam, or a non-authenticated asset, you agree and acknowledge that the Company and the Interface will not be responsible by any Loan made by you in reliance of collateral placed on the Interface. 8. **Regulatory and Compliance Suspensions or Terminations.** We may suspend or terminate your access to the Interface at any time in connection with any transaction as required by applicable law, any governmental authority, or if we in our sole and reasonable discretion determine you are violating these Terms or the terms of any third-party service provider. Such suspension or termination shall not be constituted a breach of these Terms by the Company. In accordance with its anti-money laundering, anti-terrorism, anti-fraud, and other compliance policies and practices, we may impose reasonable limitations and controls on the ability of you or any beneficiary to utilize the Interface. Such limitations may include, where good cause exists, rejecting transaction requests, freezing funds, or otherwise restricting you from using the Interface. ### **5.** Intellectual Property We exclusively own all right, title and interest in and to the Interface and any content made available through the Site, including all associated intellectual property rights. You acknowledge that the Interface and content are protected by copyright, trademark, and other laws. You agree not to remove, alter or obscure any copyright, trademark, service mark or other proprietary rights notices incorporated in or accompanying the Interface and content. Subject to your compliance with these Terms, we grant you a limited, non-exclusive, non-transferable, revocable right to access and use the Interface and content made available to you, solely for your non-commercial purposes. ### **6. Feedback.** We appreciate feedback, comments, ideas, proposals and suggestions for improvements to the Interface (“***Feedback***”). If you choose to submit Feedback, you agree that we are free to use it (and permit others to use it) without any restriction or compensation to you. ### **7. General Prohibitions and the Company’s Enforcement Rights** You agree not to do any of the following: 1. Post, upload, publish, submit or transmit any content that: (i) infringes, misappropriates or violates a third party’s patent, copyright, trademark, trade secret, moral rights or other intellectual property rights, or rights of publicity or privacy; (ii) violates, or encourages any conduct that would violate, any applicable law or regulation or would give rise to civil liability; (iii) is fraudulent, false, misleading or deceptive; (iv) is defamatory, obscene, pornographic, vulgar or offensive; (v) promotes discrimination, bigotry, racism, hatred, harassment or harm against any individual or group; (vi) is violent or threatening or promotes violence or actions that are threatening to any person or entity; or (vii) promotes illegal or harmful activities or substances; 2. Use, display, mirror or frame the Interface or any individual element within the Interface, the Company’s name, any Company trademark, logo or other proprietary information, or the layout and design of any page or form contained on a page, without the Company’s express written consent; 3. Access, tamper with, or use non-public areas of the Interface, the Company’s computer systems, or the technical delivery systems of the Company’s providers; 4. Attempt to probe, scan or test the vulnerability of any Company system or network or breach any security or authentication measures; 5. Avoid, bypass, remove, deactivate, impair, descramble or otherwise circumvent any technological measure implemented by the Company or any of the Company’s providers or any other third party (including another user) to protect the Interface; 6. Attempt to access or search the Interface or download content from the Interface using any engine, software, tool, agent, device or mechanism (including spiders, robots, crawlers, data mining tools or the like) other than the software and/or search agents provided by the Company or other generally available third-party web browsers; 7. Send any unsolicited or unauthorized advertising, promotional materials, email, junk mail, spam, chain letters or other form of solicitation; 8. Use any meta tags or other hidden text or metadata utilizing Company trademark, logo URL or product name without the Company’s express written consent; 9. Use the Interface, or any portion thereof, for any commercial purpose or for the benefit of any third party or in any manner not permitted by these Terms; 10. Forge any TCP/IP packet header or any part of the header information in any email or newsgroup posting, or in any way use the Interface to send altered, deceptive or false source-identifying information; 11. Attempt to decipher, decompile, disassemble or reverse engineer any of the software used to provide the Interface; 12. Interfere with, or attempt to interfere with, the access of any user, host or network, including, without limitation, sending a virus, overloading, flooding, spamming, or mail-bombing the Interface; 13. Collect or store any personally identifiable information from the Interface from other users of the Interface without their express permission; 14. Impersonate or misrepresent your affiliation with any person or entity; 15. Use RDNT for capital raising purposes (“***Capital Raising***”). Capital Raising is defined as receiving funds from the sale of RDNT, where the primary purpose of the sale of RDNT is to raise capital for you or another party. You acknowledge that any RDNT you receive is solely for use within the Protocol or the Interface and not for speculative purposes; 16. Violate any applicable law, rule, or regulation concerning the integrity of trading markets, including (but not limited to) the manipulative tactics commonly known as spoofing and wash trading; 17. Violate any applicable law or regulation; or 18. Encourage or enable any other individual to do any of the foregoing. The Company is not obligated to monitor access to or use of the Interface or to review or edit any content. However, we have the right to do so for the purpose of operating the Interface, to ensure compliance with these Terms and to comply with applicable law or other legal requirements. We reserve the right, but are not obligated, to remove or disable access to any content, at any time and without notice, including, but not limited to, if we, at our sole discretion, consider it objectionable or in violation of these Terms. If we have a reasonable belief that you have created multiple accounts or have associated the same digital asset wallet to multiple accounts, we reserve the right to disable your access to the Interface. If you believe we have erroneously disabled your access, you may contact us at . We have the right to investigate violations of these Terms or conduct that affects the Interface. We may also consult and cooperate with law enforcement authorities to prosecute users who violate the law. ### 8. **No Fiduciary Duties** The Interface is not intended to, and does not, create or impose any fiduciary duties on the Company. To the fullest extent permitted by law, any user of the Interface acknowledges and agrees that the Company owes no fiduciary duties or liabilities it or any other party, and that to the extent any such duties or liabilities may exist at law or in equity, those duties and liabilities are hereby irrevocably disclaimed, waived, and eliminated. Any user of the Interface further agrees that the only duties and obligations that the Company may owe are those set out expressly herein. ### **9. Copyright Policy** The Company respects copyright law and expects its users to do the same. It is the Company’s policy to terminate access in appropriate circumstances for account holders who repeatedly infringe or are believed to be repeatedly infringing the rights of copyright holders. ### **10. Links to Third Party Websites or Resources** The Interface may allow you to access third-party websites or other resources. We provide access only as a convenience and are not responsible for the content, products or services on or available from those resources or links displayed on such websites. You acknowledge sole responsibility for and assume all risk arising from your use of any third-party resources. ### **11. Termination** We may suspend or terminate your access to and use of the Interface, including suspending access to your account, at our sole discretion, at any time and without notice to you. You may cancel your access at any time by sending us an email at . Upon any termination, discontinuation or cancellation of the Interface or your access to the Interface, the following Sections, and such other provisions that by their nature are intended to survive, will survive: 5, 6, 7, 8, 11, 12, 13, 14, 15, 16 and 18. ### **12. Warranty Disclaimers** THE SERVICES ARE PROVIDED “AS IS,” WITHOUT WARRANTY OF ANY KIND. WITHOUT LIMITING THE FOREGOING, WE EXPLICITLY DISCLAIM ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, QUIET ENJOYMENT AND NON-INFRINGEMENT, AND ANY WARRANTIES ARISING OUT OF COURSE OF DEALING OR USAGE OF TRADE. WE MAKE NO WARRANTY THAT THE INTERFACE WILL MEET YOUR REQUIREMENTS OR BE AVAILABLE ON AN UNINTERRUPTED, SECURE, OR ERROR-FREE BASIS. WE MAKE NO WARRANTY REGARDING THE QUALITY, ACCURACY, TIMELINESS, TRUTHFULNESS, COMPLETENESS OR RELIABILITY OF ANY INFORMATION OR CONTENT ON THE INTERFACE. THE COMPANY WILL NOT BE RESPONSIBLE OR LIABLE TO YOU FOR ANY LOSS AND TAKES NO RESPONSIBILITY FOR, AND WILL NOT BE LIABLE TO YOU FOR, ANY USE OF THE SERVICES, INCLUDING BUT NOT LIMITED TO ANY LOSSES, DAMAGES OR CLAIMS ARISING FROM: (I) USER ERROR SUCH AS FORGOTTEN PASSWORDS, INCORRECTLY CONSTRUCTED TRANSACTIONS, OR MISTYPED WALLET ADDRESSES; (II) SERVER FAILURE OR DATA LOSS; (III) CRYPTOCURRENCY WALLETS OR CORRUPT FILES; (IV) UNAUTHORIZED ACCESS TO SERVICES; OR (V) ANY THIRD PARTY ACTIVITIES, INCLUDING WITHOUT LIMITATION THE USE OF VIRUSES, PHISHING, BRUTEFORCING OR OTHER MEANS OF ATTACK AGAINST ANY BLOCKCHAIN NETWORK UNDERLYING THE SERVICES. By accessing and using the Interface, you represent that you understand the inherent risks associated with using cryptographic and blockchain-based systems, and that you have a working knowledge of the usage and intricacies of cryptoassets and other digital assets such as bitcoin (BTC), ether (ETH), USD Coin (USDC) and other digital tokens such as those following the Ethereum Token Standard (ERC-20). You further understand that the markets for these cryptoassets are highly volatile due to factors including (but not limited to) adoption, speculation, technology, security, and regulation. You acknowledge that the cost and speed of transacting with cryptographic and blockchain-based systems are variable and may increase at any time. You further acknowledge the risk that your cryptoassets may lose some or all of their value while they are supplied to or from the Interface. You further acknowledge that we are not responsible for any of these variables or risks and cannot be held liable for any resulting losses that you experience while accessing Interface. Accordingly, you understand and agree to assume full responsibility for all of the risks of accessing, using and interacting with the Interface. ### **13. Indemnity** You will indemnify and hold the Company and its officers, directors, employees and agents harmless from and against any claims, disputes, demands, liabilities, damages, losses, costs and expenses, including, without limitation, reasonable legal and accounting fees arising out of or in any way connected with (a) your access to or use of the Interface, (b) any content that you post or otherwise make available through the Interface, or (c) your violation of these Terms. ### **14. Limitation of Liability** 1. TO THE MAXIMUM EXTENT PERMITTED BY LAW, NEITHER THE COMPANY NOR ITS SERVICE PROVIDERS INVOLVED IN CREATING, PRODUCING, OR DELIVERING THE SERVICES WILL BE LIABLE FOR ANY INCIDENTAL, SPECIAL, EXEMPLARY OR CONSEQUENTIAL DAMAGES, OR DAMAGES FOR LOST PROFITS, LOST REVENUES, LOST SAVINGS, LOST BUSINESS OPPORTUNITY, LOSS OF DATA OR GOODWILL, SERVICE INTERRUPTION, COMPUTER DAMAGE OR SYSTEM FAILURE OR THE COST OF SUBSTITUTE SERVICES OF ANY KIND ARISING OUT OF OR IN CONNECTION WITH THESE TERMS OR FROM THE USE OF OR INABILITY TO USE THE SERVICES, WHETHER BASED ON WARRANTY, CONTRACT, TORT (INCLUDING NEGLIGENCE), PRODUCT LIABILITY OR ANY OTHER LEGAL THEORY, AND WHETHER OR NOT THE COMPANY OR ITS SERVICE PROVIDERS HAVE BEEN INFORMED OF THE POSSIBILITY OF SUCH DAMAGE, EVEN IF A LIMITED REMEDY SET FORTH HEREIN IS FOUND TO HAVE FAILED OF ITS ESSENTIAL PURPOSE. 2. TO THE MAXIMUM EXTENT PERMITTED BY THE LAW OF THE APPLICABLE JURISDICTION, IN NO EVENT WILL THE COMPANY’S TOTAL LIABILITY ARISING OUT OF OR IN CONNECTION WITH THESE TERMS OR FROM THE USE OF OR INABILITY TO USE THE SERVICES EXCEED, AS APPLICABLE, THE AMOUNTS YOU HAVE PAID OR ARE PAYABLE BY YOU TO THE COMPANY FOR USE OF THE SERVICES OR, IF YOU HAVE NOT HAD ANY PAYMENT OBLIGATIONS TO THE COMPANY, ONE HUNDRED DOLLARS ($100). 3. THE EXCLUSIONS AND LIMITATIONS OF DAMAGES SET FORTH ABOVE ARE FUNDAMENTAL ELEMENTS OF THE BASIS OF THE BARGAIN BETWEEN THE COMPANY AND YOU**.** ### **15. Governing Law and Forum Choice** These Terms and any action related thereto will be governed by the laws of the Cayman Islands, without regard to its conflict of laws provisions. Except as otherwise expressly set forth in Section 16 (Dispute Resolution), the exclusive jurisdiction for all Disputes (defined below) that you and the Company are not required to arbitrate will be the courts located in George Town, Cayman Islands, and you and the Company each waive any objection to jurisdiction and venue in such courts. ### **16. Dispute Resolution** 1. **Mandatory Arbitration of Disputes.** We each agree that any and all disputes, claims, or controversies arising out of or relating in any way to these Terms, the breach, termination, enforcement, interpretation or validity thereof, or the use of the Interface (collectively, “***Disputes***”) will be resolved **solely by binding, individual arbitration and not in a class, representative or consolidated action or proceeding**. You and the Company agree that the Cayman Arbitration Act governs the interpretation and enforcement of this Section 16 and all Disputes, and that you and the Company are each waiving the right to a trial by jury or to participate in a class action. This arbitration provision shall survive termination of these Terms and/or the termination of your use of the Interface. 2. **Exceptions.** As limited exceptions to Section 16.1 above: (i) either you or the Company can seek to resolve a Dispute in small claims court if it qualifies; and (ii) we each retain the right to seek injunctive or other equitable relief from a court of competent jurisdiction to prevent (or enjoin) the actual or threatened infringement, misappropriation, or violation of our intellectual property rights. 3. **Notice.** Before initiating arbitration or a small claims court proceeding, you and the Company agree that each will send to the other party a written notice that describes the Dispute(s) and the relief sought (the “***Notice***”) to allow the parties to attempt to resolve the Dispute informally. The Notice to the Company should indicate your preferred mailing address and email address and should be sent to: . Any Notice from the Company will be sent via any means we have to contact you, including via airdrop to your wallet. You and the Company each agree to negotiate any Dispute between us in good faith. You and the Company each agree that neither may initiate arbitration proceedings or a small claims court proceeding unless the parties have made a good faith effort to resolve the Dispute through the informal resolution procedure described in this paragraph and are unable to do so within sixty (60) days after receipt of any Notice. Any applicable statue of limitations will be tolled for sixty (60) days while the parties engage in this informal dispute resolution procedure. 4. **Conducting Arbitration and Arbitration Rules.** For Dispute(s) that we cannot resolve within sixty (60) days of the Notice despite those good faith efforts, either you or the Company may start arbitration or small claims proceedings. The arbitration of all Disputes will be in binding arbitration conducted by the Cayman International Mediation & Arbitration Centre (“***CI-MAC***”) under the CI-MAC rules then in effect (rules available at ) and governed by the Arbitration Act (as amended) of the Cayman Islands. The number of arbitrators shall be one and the decision of the sole arbitrator to any such Dispute(s) shall be final and binding upon both parties. The arbitrator can award the same damages and relief that a court can award. You and the Company each waives any right you or it may have to assert the doctrine of forum non conveniens, to assert that it is not subject to the jurisdiction of such arbitration or courts, or to object to venue to the extent any proceeding is brought in accordance herewith. If any Dispute(s) asserted in any request or demand for arbitration could have been brought in small claims court, then either you or the Company may elect to have the Dispute(s) heard in small claims court, rather than in arbitration, at any time before the arbitrator is appointed, by notifying the other party of that election in writing. Any dispute about whether a Dispute qualifies for small claims court will be resolved by that court, not by an arbitrator. In the event of any such dispute, the arbitration proceeding will remain closed unless and until the small claims court issues a decision that the Dispute should proceed in arbitration.\ Any arbitration hearings will be conducted in George Town, Cayman Islands, but will be conducted remotely to the extent permitted by the CI-MAC Rules. The parties agree that, except as otherwise provided herein, the arbitrator shall have exclusive authority to decide all issues, including jurisdictional and arbitrability issues and the formation, existence, validity, interpretation, applicability, enforceability, and scope of this arbitration provision. The arbitrator is bound by this Agreement.\ The arbitrator shall issue a reasoned written decision sufficient to explain the essential findings and conclusions on which the award is based. The award shall be binding only among the parties and shall have no preclusive effect in any other arbitration or other proceeding involving a different party. Judgment on any award may be entered in any court having jurisdiction. This arbitration provision shall not preclude any party to the arbitration from at any time seeking injunctions or other forms of equitable relief in aid of arbitration from a court of appropriate jurisdiction, including whether an arbitration demand is filed in violation of these Terms. If for any reason this arbitration provision is found not to apply to a Dispute and as a result a Dispute proceeds in a court of general jurisdiction rather than in arbitration or small claims court, the Dispute shall be exclusively brought in accordance with Section 15 above. 5. **Arbitration Costs.** Payment of all filing, administration and arbitrator fees will be governed by the CI-MAC Rules. The Company will not seek to recover its attorneys’ fees and costs in arbitration from you unless the arbitrator finds that either the substance of your Dispute or the relief sought in your demand for arbitration was frivolous or was brought for an improper purpose. If you prevail in arbitration you will be entitled to an award of attorneys’ fees and expenses to the extent provided under applicable law. 6. **Injunctive and Declaratory Relief.** Except as provided in Section 16.2 above, the arbitrator shall determine all issues of liability on the merits of any claim asserted by either party and may award declaratory or injunctive relief only in favor of the individual party seeking relief and only to the extent necessary to provide relief warranted by that party’s individual claim. To the extent that you or we prevail on a claim and seek public injunctive relief (that is, injunctive relief that has the primary purpose and effect of prohibiting unlawful acts that threaten future injury to the public), the entitlement to and extent of such relief must be litigated in a civil court of competent jurisdiction and not in arbitration. The parties agree that litigation of any issues of public injunctive relief shall be stayed pending the outcome of the merits of any individual claims in arbitration. 7. **Class Action Waiver.** **YOU AND THE COMPANY AGREE THAT EACH MAY BRING CLAIMS AGAINST THE OTHER ONLY IN YOUR OR ITS INDIVIDUAL CAPACITY, AND NOT AS A PLAINTIFF OR CLASS MEMBER IN ANY PURPORTED CLASS, CONSOLIDATED, OR REPRESENTATIVE PROCEEDING.** Further, if the parties’ Dispute is resolved through arbitration, the arbitrator may not consolidate another person’s claims with your claims, and may not otherwise preside over any form of a representative or class proceeding. If you or the Company believes that any Dispute that the other has filed in arbitration is inconsistent with the limitations in this paragraph, then you or the Company may seek an order from a court determining whether the other’s Dispute is within the scope of this class action waiver. If a court or an arbitrator determines that any part of this arbitration provision or class action waiver is unenforceable with respect to any Dispute, then the arbitration provision and class action waiver will not apply to that Dispute. But the arbitration provision and class action waiver will still apply to all other Disputes, remedies and requests for relief that you or the Company may assert in that or any other action. In any such case, you and the Company agree that the parties will arbitrate all Disputes, remedies and requests for relief subject to individual arbitration first, and that any remaining unresolved Claims, remedies, or requests for relief may be pursued in court only after the arbitrator’s award has been issued. The parties agree that any statute of limitations applicable to the unresolved Disputes, remedies or requests for relief shall be tolled pending the outcome of the individual Disputes in arbitration. ### **17. Severability.** With the exception of any of the provisions in Section 16.6 (Class Action Waiver), if any part of these Terms is held invalid or unenforceable, then that part may be severed from these Terms and the remaining parts of these Terms will remain in full force and effect. ### 18. **General Terms** 1. **Reservation of Rights.** The Company and its licensors exclusively own all right, title and interest in and to the Interface, including all associated intellectual property rights. You acknowledge that the Interface is protected by copyright, trademark, and other laws of the United States and foreign countries. You agree not to remove, alter or obscure any copyright, trademark, service mark or other proprietary rights notices incorporated in or accompanying the Interface. 2. **Entire Agreement.** These Terms constitute the entire and exclusive understanding and agreement between the Company and you regarding the Interface, and these Terms supersede and replace all prior oral or written understandings or agreements between the Company and you regarding the Interface. If any provision of these Terms is held invalid or unenforceable by an arbitrator or a court of competent jurisdiction, that provision will be enforced to the maximum extent permissible and the other provisions of these Terms will remain in full force and effect. You may not assign or transfer these Terms, by operation of law or otherwise, without the Company’s prior written consent. Any attempt by you to assign or transfer these Terms, without such consent, will be null. The Company may freely assign or transfer these Terms without restriction. Subject to the foregoing, these Terms will bind and inure to the benefit of the parties, their successors and permitted assigns. 3. **Notices.** Any notices or other communications provided by the Company under these Terms will be given: (i) via email; or (ii) by posting to the Interface. For notices made by email, the date of receipt will be deemed the date on which such notice is transmitted. 4. **Waiver of Rights.** The Company’s failure to enforce any right or provision of these Terms will not be considered a waiver of such right or provision. The waiver of any such right or provision will be effective only if in writing and signed by a duly authorized representative of the Company. Except as expressly set forth in these Terms, the exercise by either party of any of its remedies under these Terms will be without prejudice to its other remedies under these Terms or otherwise. ### 19. **Contact Information** If you have any questions about these Terms or the Interface, please contact the Company at .