**Users deposit assets** to earn **interest and rewards**, and to use them as collateral.
**Users borrow assets** against their **collateral**, discounted by token reward incentives.
**Optimized interest rates** adjust dynamically based on market demand.
Neverland’s lending markets are powered by `neverland-lending-core` 1.1.0, deployed on Monad.\
Users can supply assets to earn yield, borrow against collateral, and benefit from Neverland-specific features such as **self-repaying loans** and governance-directed incentives.
***
### 
Overview
**Engine:** `neverland-lending-core` 1.1.0 on Monad.\ **Assets:** Blue-chip stables and majors (e.g., WMON, WBTC, WETH, USDC, USDT etc.), plus selected ecosystem assets.\ **What you can do:**\ 
Supply assets → earn interest (nTokens).\ Borrow against supplied collateral within LTV limits.\ Repay, adjust, or close positions at any time.\ **Neverland integrations:**\ **DUST Incentives:** earn DUST rewards for supplying and borrowing.\ **Self-Repayment:** route veDUST rewards to reduce your loan automatically.\ **Revenue Distribution:** protocol revenue is governed by veDUST.
***
### How Lending Works
#### Supplying
Deposit a supported asset into the pool.\ Receive **nTokens** that accrue interest in real time.\ You can withdraw anytime, provided your position remains healthy (if you are also a borrower).
#### Borrowing
Use supplied assets as **collateral** to borrow other assets.\ Your **maximum borrow** depends on each collateral’s **Loan-to-Value (LTV)** and your total risk.\ Borrow interest is **variable** and updates automatically with market utilization.
#### Repaying & Withdrawing
Repay borrowed assets partially or fully at any time.\ Withdraw collateral as long as your **Health Factor** stays above 1.0 after the withdrawal.
***
### Risk Parameters
| Parameter | Meaning |
|---|---|
| LTV (Loan-to-Value) | Maximum amount you can borrow against collateral. |
| Liquidation Threshold | When a position becomes eligible for liquidation. |
| Liquidation Bonus | Discount liquidators receive when covering debt. |
| Reserve Factor | Percentage of interest routed to the Treasury. |
| Caps / Modes | Some assets may have supply or borrow limits, or be collateral-only. |
**Health Factor (HF)**
$$
HF = \frac{collateralValue \times liquidationThreshold}{debtValue}
$$
$$
\text{HF} > 1.0 \Rightarrow \text{safe} \qquad \text{HF} < 1.0 \Rightarrow \text{liquidatable}
$$
***
### Interest Rate Model
Rates follow a “kinked” curve per asset:
**Before the kink (Optimal Utilization):** borrow APY rises gradually as utilization grows.\ **After the kink:** borrow APY rises steeply to discourage over-utilization and protect liquidity.
This design ensures stability for lenders while maintaining capital efficiency for borrowers.
***
### Oracles
Neverland uses 
[**Chainlink**](https://chain.link/) **price feeds** for all supported assets when available.\
Each feed reports **USD-denominated prices (8 decimals)**, verified and standardized across the protocol.
**Base currency:** USD\ **Quote unit:** 1 × 10⁸ = $1.00
On Monad, prices are relayed through the **AaveV3PriceRouter**, which emits on-chain price snapshots for every lending action. This ensures consistent, indexable data for subgraphs and analytics while preserving full oracle security.
All pool operations use the latest validated oracle prices to determine borrowing capacity, Health Factor, and liquidation thresholds, ensuring consistent and manipulation-resistant valuations across the protocol.
***
### Incentives and the Neverland Flywheel
Neverland extends its lending core with a closed-loop incentive economy built around **DUST** and **veDUST**. Every action in the lending markets feeds back into governance and future rewards.
#### 1. Activity-Based DUST Incentives
Supplying or borrowing assets earns DUST rewards through the **DustRewardsController**.\ Emission rates adjust dynamically by market and utilization.\ Users can claim rewards and choose to:\ **Lock DUST** to gain veDUST voting power, or\ **Withdraw liquid DUST** (subject to penalty).\ This replaces fixed external emissions with usage-driven incentives.
#### 2. Governance Through veDUST
Locked DUST becomes **veDUST**, granting governance rights.\ veDUST holders vote on how protocol revenue is distributed across incentives, buybacks, and liquidity.\ Governance also decides emission priorities across markets.
#### 3. Revenue Recycling
Borrowing interest and liquidation fees collected by the **Treasury** are redistributed each epoch according to veDUST votes:\ **veDUST rewards** via the RevenueReward contract\ **LP incentives** via the LPStaking contract\ **Buybacks & burns** executed by the protocol-owned safe wallet\ This creates a feedback loop where lending activity directly funds community rewards and deflation.
#### 4. The Neverland Flywheel
Liquidations
If your Health Factor drops below 1.0 (e.g., collateral price down or debt value up), the position becomes eligible for partial liquidation:
A liquidator repays part of your debt and receives collateral at a **bonus**.\ Your debt decreases, collateral is reduced, and your Health Factor is restored above 1.0.\ You keep control of the remaining position and can stabilize or close it.
To minimize risk:
Maintain HF > 1.2.\ Diversify collateral.\ Use the self-repaying feature to gradually reduce exposure.
***
### Self-Repaying Loans
Neverland connects governance rewards to lending:
Enable **Self-Repay** on your veNFT.\ Your veDUST rewards **repays** your loan.\ This improves your position’s health over time with no manual effort.
See the [**Self-Repayment System**](/loan-self-repayment-system) page for details.
***
### Fees & Costs
**Borrow interest:** variable, depends on utilization and the asset’s rate strategy.\ **Flash loans:** low, fixed premium (protocol-configured).\ **Reserve factor:** portion of interest retained as protocol revenue.\ **Network fees:** standard gas costs on Monad for interactions (supply, borrow, repay, etc.).
***
### Typical User Journeys
**Earn yield (supplier):**\ Supply **MON** → receive **nMON** → accrue interest.\ Withdraw anytime.
**Access liquidity (borrower):**\ Supply **MON** as collateral → borrow **USDC** within **LTV**.\ Enable **Self-Repay** on your **veDUST** to passively reduce debt.\ Repay/adjust as needed; keep **HF safely above 1.0**.
**De-risk during volatility:**\ Repay part of the loan, add collateral, or reduce exposure to maintain Health Factor.\ Self-Repay can help chip away at debt in the background.
***
### At a Glance
`neverland-lending-core` markets on Monad.\ Oracle-secured asset pricing.\ Dynamic rates and transparent risk parameters.\ Integrated **DUST → veDUST → Revenue** flywheel.\ Optional **Self-Repaying Loans** powered by veDUST rewards.\ Governance-driven revenue distribution and deflationary mechanics.
# Efficiency Mode
### What is E-Mode?
**E-Mode** stands for **Efficiency Mode**.
It is an account-wide risk mode that groups highly correlated assets into a single borrowing and collateral basket. When your account uses a compatible category, Neverland can apply **higher capital efficiency** than the default per-asset configuration.
In practice, E-Mode can let you:
borrow more efficiently against correlated assets\ use a tighter collateral model for assets that usually move together\ unlock collateral usage for assets that may not be collateral-efficient in Default Mode
> Important: E-Mode is **not asset-by-asset**. It applies to your **whole account** for the market. You can only be in **one** E-Mode category at a time, or in **Default Mode**.
***
### Available E-Mode Categories
| Category | ID | Supply | Borrow | LTV | LT | LP |
|---|---|---|---|---|---|---|
| Liquid Staking Tokens | 1 | WMON sMON shMON gMON | WMON | 88% | 90% | 5% |
| Stablecoins | 2 | USDC USDT0 AUSD | USDC USDT0 AUSD | 93% | 94% | 4% |
Default Mode
Default Mode is the normal market configuration where **each reserve uses its own native collateral and borrowing rules**.
Default Mode does **not** use a category-wide correlated basket.
***
### How E-Mode Works
When you enable an E-Mode category:
1. Your account switches from reserve-native rules to the selected correlated category.
2. Assets inside that category can receive the category's boosted collateral treatment.
3. Borrowing compatibility is checked against the category's allowed borrow basket.
4. The change affects the **entire account**, not only the asset you clicked.
When you return to Default Mode:
1. The account leaves the correlated category.
2. Category-wide boosts are removed.
3. Every reserve goes back to its own native market parameters.
***
### What Changes When You Enable E-Mode?
Depending on the category and your current positions, E-Mode can change:
which supplied assets count efficiently as collateral\ the effective LTV used for correlated assets\ the effective liquidation threshold used for correlated assets\ which borrowed assets are compatible with your current mode\ your projected health factor
***
### What Neverland Checks Before Allowing a Switch
Neverland blocks unsafe or incompatible E-Mode changes before transaction submission.
#### 1. Incompatible Borrows
If you already have debt in an asset that does not belong to the target category's borrow basket, the switch is blocked.
Example:
you want to switch into **Stablecoins**\ your account still has an active `WMON` borrow
Result:
the switch is blocked until that incompatible debt is repaid
#### 2. Zero-LTV or Disabled Collateral After Switch
If assets you currently use as collateral would become unusable or effectively zero-LTV under the target mode, the switch is blocked.
Result:
you must disable or remove that conflicting collateral first
#### 3. Health Factor Safety Margin
If the projected post-switch health factor would fall **below `1.01`**, Neverland blocks the switch.
Result:
the transaction is not allowed through the app\ the UI explains that the switch would drop the account below the safety margin
> Note: If your account has no borrows, health factor does not provide meaningful additional signal, so the app focuses on the mode summary instead of a risk change.
***
### How E-Mode Affects Borrowing
If you are already inside an E-Mode category, borrowing is only allowed for assets that are borrow-enabled inside that active category.
This means:
being in **Stablecoins** can block non-stable borrowing\ being in **Liquid Staking Tokens** can block non-LST borrowing\ returning to **Default Mode** removes the category-wide borrow basket and falls back to reserve-native rules
***
### How E-Mode Affects Collateral
E-Mode can also change whether a reserve is practically usable as collateral for your account.
This is especially important for assets whose collateral usefulness depends on the active correlated basket.
#### If an asset requires E-Mode to be efficient as collateral
Neverland will tell you to enable a compatible E-Mode first.
#### If you try to toggle collateral directly
The collateral change modal does **not** change your account's E-Mode for you. It only changes collateral usage inside your **current** mode.
If a different E-Mode is required, the app routes you to **Manage E-Mode** instead.
***
### Supply & E-Mode Behavior
On supply flows, Neverland can require an E-Mode change before executing the supply with the intended collateral setup.
Current behavior on Neverland:
the app performs the **E-Mode switch first**\ then it submits the **supply transaction**\ this is intentionally handled as a **two-step chained flow**, not as a single bundled multicall
Why this matters:
it is more reliable for the current Neverland/Monad setup\ it avoids fragile bundled transaction behavior\ the app skips unnecessary E-Mode transactions if the account is already in the target category
***
### Manage E-Mode UI
The E-Mode entry point changes depending on your current state.
#### If E-Mode is disabled
The button shows:
**Enable E-Mode**
#### If E-Mode is active
The button shows:
**Manage E-Mode: {Active Category}**
Inside the Manage E-Mode modal, Neverland shows:
the current mode\ the selected next mode\ the category collateral basket\ the category borrow basket\ projected health factor changes, when relevant\ safety blocks for incompatible switches
***
### Practical Examples
#### Example 1: Enabling Stablecoins E-Mode
You supply `USDC` and want to borrow against a stable basket more efficiently.
If your account has only stable-compatible debt and collateral, enabling **Stablecoins** can increase capital efficiency versus Default Mode.
#### Example 2: Leaving E-Mode
You are in **Liquid Staking Tokens** mode and want to go back to normal reserve rules.
Neverland checks:
whether the switch would make your current collateral unsafe\ whether your health factor would drop below `1.01`
If not, the account can return to Default Mode.
#### Example 3: Asset Needs E-Mode for Collateral
You try to enable collateral on an asset whose useful collateral treatment depends on a compatible category.
Result:
the collateral toggle is blocked\ the app tells you to enable the required E-Mode first
***
### FAQ
#### Is E-Mode optional?
Yes. You can stay in **Default Mode** and use reserve-native rules.
#### Can I be in multiple E-Mode categories at once?
No. Only one category can be active at a time.
#### Does E-Mode affect only the asset I clicked?
No. E-Mode changes the **entire account's** correlated collateral and borrowing basket for the market.
#### Can E-Mode improve my health factor?
Sometimes yes, sometimes no.
It depends on:
what you supplied\ what you borrowed\ whether those assets are compatible with the target category\ how the category changes your collateral efficiency
#### Why is the app blocking my switch?
The most common reasons are:
incompatible active borrows\ collateral that would become unusable or zero-LTV\ projected health factor below `1.01`
***
### Risk Reminder
E-Mode increases efficiency by assuming stronger correlation between assets. That can improve capital usage, but it also means the account becomes more dependent on that correlation holding under stress.
Always review:
your current borrows\ your collateral mix\ your projected health factor\ whether Default Mode may be safer for your position structure
# DUST Incentives
The **DUST Incentives System** distributes protocol rewards to users who participate in Neverland’s lending markets and governance.
Rewards are generated continuously from supplying and borrowing activity across the protocol and are allocated transparently through the emission controller.
This system is designed to strengthen user participation in both the **lending markets** and **governance**, rewarding those who contribute liquidity or maintain long-term commitment through veDUST.
***
### Overview
Every market in Neverland is connected to the **DustRewardsController**, which tracks reward emissions and accruals for each user based on their supply and borrow balances.
The system continuously distributes DUST to active participants, aligning incentives for suppliers, borrowers, and governance participants.
Emissions are not fixed; they scale with market activity and utilization.\
The more you contribute supplying or borrowing, the larger your share of rewards.
***
### How Emissions Work
1. **Emission Source**
DUST rewards are distributed across Neverland’s **supply and borrow markets**.\ Each supported asset has a defined emission rate, which determines how many DUST tokens are emitted per second to that pool.\ Supply and borrow emissions may differ based on governance settings or liquidity priorities.
2. **Reward Accrual**
Rewards accrue automatically as users supply or borrow assets.\ The controller tracks each user’s share relative to total market activity.
3. **Claiming Rewards**
Users can claim their accrued DUST rewards directly through the app.\ Upon claiming, users can decide how to handle their rewards: lock them into a new time-lock, add to an existing lock, create a permanent lock, or withdraw with a penalty for immediate liquidity.
Emissions are distributed fairly and proportionally to each user’s participation.
***
### Claiming Options
Users can choose between several ways to handle their accumulated DUST rewards:
| Option | Description | Penalty | Ideal For |
|---|---|---|---|
| Create New Lock | Claim rewards into a new veDUST with a chosen duration (1 month – 1 year). | None | New governance participants |
| Add to Existing Lock | Add claimed rewards to an existing veDUST (extends commitment). | None | Users consolidating voting power |
| Create Infinite Lock | Claim rewards into a infinite veDUST (1:1 voting power, no decay). | None | Long-term governance holders |
| Direct Transfer | Claim as liquid DUST to your wallet. | 50% | Users needing liquidity |
Claiming Flow
Penalty Logic
When choosing **direct transfer** (claiming without locking), a penalty is applied to discourage short-term extraction. The penalty is **50%**, configurable by the protocol.
The user receives 50% of the claimed DUST as liquid tokens.\ The remaining 50% is sent to the **Treasury**, where it gets burned.
This structure aligns emissions with long-term participation and reduces circulating supply over time.
***
### Integration with Governance
The DUST Incentives system works alongside veDUST governance:
Users who lock DUST as veDUST gain **voting power** and can decide how revenue is directed.\ Locked users also receive revenue rewards from the protocol’s governance revenue share.
Together, this creates a continuous flywheel between **liquidity**, **governance**, and **emissions**.
***
### Key Characteristics
**Activity-driven emissions:** Rewards are generated directly from lending pool participation.\ **Automatic accrual:** Rewards accumulate seamlessly as users supply or borrow.\ **Flexible claiming:** Four claim options to match user preferences.\ **Penalty-aligned:** Direct claims reduce supply and strengthen token value.\ **Governance-integrated:** veDUST holders steer the protocol.\ **Composable architecture:** Designed to work across all Neverland markets.
***
### Summary
DUST emissions are distributed to those who make Neverland function: suppliers and borrowers; they also empower governance participants.\
Every action in the protocol earns DUST rewards, and every claim choice influences both personal and ecosystem growth.
By combining activity-based emissions with veDUST governance, Neverland creates a sustainable incentive model that rewards liquidity, strengthens governance, and reinforces long-term alignment between users and the protocol.
# veDUST Mechanics
**veDUST** is the vote-escrowed version of **DUST**, representing your commitment and influence in the Neverland ecosystem.
When you lock DUST, you mint veDUST, gaining **voting power**, **governance rewards**, and **priority influence** over how protocol revenue is used. The longer and larger the lock, the more powerful your vote.
### Core Formula
$$
\text{veDUST} = D\_{\text{locked}} \times \frac{t\_{\text{lock}}}{t\_{\text{max}}}
$$
Where:
$$
\begin{aligned}
D\_{\text{locked}} &= \text{amount of DUST locked} \\
t\_{\text{lock}} &= \text{selected lock duration} \\
t\_{\text{max}} &= \text{maximum possible lock (typically 1 year)}
\end{aligned}
$$
Voting power **decays linearly** over time:
$$
\text{veDUST}(t) = D\_{\text{locked}} \times \frac{t\_{\text{end}} - t}{t\_{\text{end}} - t\_{\text{start}}}
$$
At expiration $$(t = t\_{\text{end}})$$, veDUST reaches zero. Extending your lock increases $$t\_{\text{end}}$$ and restores voting power.\
**Permanent locks** grant full voting power indefinitely, without decay.
***
### veDUST as an NFT
Each veDUST position is minted as a **non-fungible token (NFT)**, representing a unique governance stake that you fully own.
The NFT contains:
Locked amount (`amount`)\ Unlock timestamp (`end`)\ Weighted start time (`effectiveStart`)\ Voting weight and reward receiver
NFTs are **fully transferable**: you can trade or sell your position at any time.\
This means you can exit early **without unlocking**, while keeping the entire system liquid and transparent.\
Neverland’s NFT architecture brings **flexibility** to a governance model that traditionally locks users in place.
***
### Early Unlocks & Fair Penalties
If you prefer to **unlock early**, you can. However, to keep things fair, Neverland applies a **proportional penalty** based on how much time remains on your lock. The earlier you withdraw, the higher the penalty. All penalties are **burned**, reducing total supply and rewarding the rest of the community.
$$
P\_{\text{user}} = D\_{\text{locked}} \times \frac{R}{10{,}000} \times \frac{t\_{\text{end}} - t\_{\text{now}}}{t\_{\text{end}} - t\_{\text{effective}}}
$$
Where:
$$
\begin{aligned}
R &= \text{maximum early-withdraw penalty } (7{,}500 = 75%) \\
t\_{\text{now}} &= \text{current time} \\
t\_{\text{effective}} &= \text{weighted average start} \\
t\_{\text{end}} &= \text{unlock time}
\end{aligned}
$$
Penalties **decay linearly** from full at creation to zero at expiry: simple, transparent, and fair.
All penalized tokens are **burned**, benefiting long-term lockers through greater scarcity and value.
***
### Weighted Start
Whenever you **add more DUST**, **extend**, or **merge** locks, Neverland uses a weighted average start time to ensure fairness:
$$
t\_{\text{effective}} = \frac{D\_1 t\_1 + D\_2 t\_2}{D\_1 + D\_2}
$$
*Example:* You lock 100 DUST on Jan 1 and add 50 DUST on Mar 1 → $$t\_{\text{effective}}$$ ≈ Feb 3. Your prior commitment still counts: you don’t lose credit for time already served.
This prevents “refreshing” near expiry from reducing penalties.
#### Lifecycle Behavior
| Action | Weighted Start Behavior | Penalty Impact |
| Create Lock | Set to block.timestamp | Starts fresh penalty period |
| Increase Amount | Weighted average (old + new) | Moves forward slightly, fair adjustment |
| Extend Duration | Unchanged | Reduces penalty (longer commitment) |
| Merge Locks | Weighted average of both locks | Blends time served fairly |
| Permanent Lock | Ignored (no decay or penalty) | Fully committed state |
Governance & Rewards Flywheel
veDUST powers Neverland’s **self-balancing flywheel**, connecting commitment, influence, and rewards.
#### **Governance Power**
Active locks carry real weight. The longer you stay locked, the stronger your vote and your share of rewards. Extending your lock keeps your influence active and your rewards high.
#### **Revenue Distribution**
All protocol revenue (interest spreads and liquidation fees) flows through veDUST governance.
Holders decide how it’s allocated between governance rewards, LP incentives, and DUST buybacks and burns:
$$
\text{Revenue}*{\text{to veDUST}} = \alpha \times \text{Revenue}*{\text{total}}
$$
where $$\alpha \le 0.5$$
Each holder’s share is:
$$
\text{Reward}\_i =
\frac{\text{veDUST}*i}{\sum*{j=1}^{N}\text{veDUST}*j}
\times
\text{Revenue}*{\text{to veDUST}}
$$
Because veDUST decays over time, the share of rewards naturally tilts toward users who **stay locked and engaged**, linking yield directly to participation.
#### **Deflationary Reinforcement**
Penalties from early unlocks permanently **burn DUST**, shrinking total supply and amplifying value for long-term holders. Every early exit strengthens the system by concentrating both governance power and future rewards among those still committed.
#### **Adaptive APR Equilibrium**
The effective APR adjusts automatically to the total DUST locked:
$$
\text{APR}*{\text{effective}} = \frac{\alpha \times \text{Revenue}*{\text{Total}} \times 12}{D\_{\text{locked}}}
$$
Fewer lockers = higher APR → stronger incentive to lock again. This self-correcting cycle keeps rewards balanced and sustainable.
#### **Self-Balancing Dynamics**
The combination of linear governance decay, weighted-start fairness, and burn-based penalties creates a *living economy*:
$$
\text{Fewer Locks} \Rightarrow \text{Higher APR} \Rightarrow \text{More Incentive to Re-Lock}
$$
veDUST isn’t just a governance token; it’s the engine that keeps Neverland’s ecosystem **healthy, fair, and continuously in motion**.Overview
Neverland’s governance uses a **vote-escrow model** inspired by veCRV but optimized for flexibility and sustainability. By locking DUST to mint veDUST, users gain governance power that allows them to vote on how the protocol’s revenue is allocated each epoch.
veDUST holders decide how revenue is divided among three primary categories:
**veDUST Participation Incentives**: rewards for veDUST lockers who participate in governance.\ **DUST Buybacks & Burns**: using revenue to reinforce deflationary tokenomics.\ **LP Staking Incentives**: rewards distributed to liquidity providers that support DUST markets.
***
### Revenue Flow
Revenue Model
Neverland’s revenue originates from the following sources:
**Borrowing Interest**: interest paid by borrowers in Neverland’s lending markets.\ **Liquidation Fees**: revenue collected from liquidations.\ **Protocol-Owned Liquidity**: DUST liquidity held by the protocol to stabilize markets and earn yield.
After collection, total revenue is allocated according to governance decisions as follows:
The portion assigned to **veDUST Rewards** is sent to the **RevenueReward** contract, which distributes rewards to veDUST holders.\ The portion assigned to **LP Staking Incentives** is routed to the **LPStaking** contract, which handles emissions to active liquidity providers.\ The portion assigned to **DUST Buybacks & Burns** is transferred to a **protocol-owned safe wallet**, which executes open-market buybacks and performs token burns transparently on-chain.
This structure ensures clear separation of revenue streams and full traceability of every allocation.
***
### Liquidity & Incentives
**LP Staking** – ensures consistent and deep liquidity for DUST pairs, rewarding engaged liquidity providers.\ **Protocol-Owned Liquidity** – creates a stable, self-sustaining liquidity base that reduces reliance on short-term yield farmers.
These mechanisms provide long-term liquidity stability and align incentives between the protocol and its users.
***
### Governance Cycle
Revenue distribution follows a recurring, governance-directed cycle:
1. **Collection:** Protocol-generated revenue accumulates in the **Treasury**.
2. **Vote:** veDUST holders vote on allocation weights for each category.
3. **Execution:** The Treasury routes funds to **RevenueReward**, **LPStaking**, and the **Buyback Safe** according to the voted percentages.
4. **Ongoing Epochs:** These allocations remain active until the next governance epoch, when veDUST holders can vote to adjust distribution weights. Typically a governance epoch duration is one month.
This structure ensures that all protocol earnings are handled transparently, governed by veDUST, and distributed according to community priorities.
***
### Key Principles
**Full redistribution:** 100% of protocol revenue is directed by veDUST governance.\ **Transparent accounting:** all allocations and burns are verifiable on-chain.\ **Dynamic weighting:** governance can rebalance incentives each governance epoch.\ **Deflationary mechanism:** buybacks and burns reduce circulating supply over time.\ **Aligned incentives:** active governance participation directly increases user rewards.
***
### Governance Epoch Example
Each governance epoch concludes with a vote from veDUST holders to determine how protocol revenue will be distributed in the following cycle. The resulting weights define the share of total revenue allocated to each incentive category.
**Example Allocation:**
| Category | % | Purpose |
|---|---|---|
| veDUST Participation Incentives | 50% | Distributed to veDUST lockers as rewards for active participation in governance. |
| DUST Buybacks & Burns | 30% | Used to buy DUST from the open market and permanently burn it, reducing the circulating supply. |
| LP Staking Incentives | 20% | Provided to liquidity providers that support DUST liquidity, ensuring stability and depth. |
**$50,000 →** veDUST participation rewards\ **$30,000 →** DUST buybacks and burns\ **$20,000 →** LP staking incentives
These allocations remain in effect until the next governance epoch, when veDUST holders can vote again to update the weighting.
***
### Why It Matters
Revenue distribution is one of Neverland’s defining mechanisms. It transforms governance decisions into real, measurable outcomes: rewarding commitment, maintaining liquidity, and supporting deflationary tokenomics.
Every DUST lock and every governance vote contributes directly to the protocol’s long-term sustainability, ensuring that Neverland remains a **fully community-driven, self-reinforcing ecosystem**.
Overview
Self-repayment provides a way for active participants to improve their loan health passively. By routing earned rewards directly into repayment, borrowers maintain lower utilization, reduced liquidation risk, and a smoother compounding experience.
Once enabled, all veDUST enrolled in self-repayment will automatically send their rewards to the user’s vault until the feature is turned off.
***
### How It Works
1. **Enable Self-Repay**\ The user enables self-repayment for their veDUST.\ The system deploys a **UserVault** to that wallet (one vault per user).
2. **Reward Redirection**\ Rewards generated from the veDUST enabled for the self-repay system are sent to the user’s vault instead of their wallet.\ Each veDUST can independently opt in or out of self-repayment.
3. **Automated Execution**
A protocol executor once per epoch:
Claims rewards to the vault
Swaps reward tokens into the chosen debt asset
Repays the user’s loan on their behalf
4. **Disable at Any Time**
Disabling self-repay restores the default reward flow directly to the wallet.
All future rewards bypass the vault until the feature is re-enabled.
***
### System Architecture
| Component | Description |
|---|---|
| RevenueReward | Routes veDUST rewards to either the owner or their assigned vault. |
| UserVaultFactory | Deploys one vault per user when first enabling self-repay. |
| UserVault | Holds rewards, performs swaps, and repays debt positions. |
| UserVaultRegistry | Controls aggregator whitelists, slippage limits, and executor permissions. |
Security and Safeguards
**Non-custodial:** Users remain owners of both the veDUST and the vault.\ **Slippage protected:** Swaps use Neverland oracle pricing to verify fair execution.\ **Whitelisted aggregators:** Only approved DEX aggregators are permitted.\ **Auto cleanup:** Self-repay is automatically disabled if the veDUST is transferred or merged.\ **Split inheritance:** If a veDUST is split, both resulting tokens retain self-repay status.\ **Recovery functions:** Users can recover ERC20 or MON from their vault at any time.
***
### Behavior Summary
| Action | Result |
|---|---|
| Enable self-repay | Rewards are redirected to the user’s vault |
| Disable self-repay | Rewards flow directly to the wallet |
| Transfer veDUST | Self-repay is disabled automatically |
| Split veDUST | Both new tokens inherit self-repay |
| Merge veDUST's | Self-repay is cleared for the merged token |
| Executor operation | Claims rewards, swaps them, and repays debt |
| Manual claim (disabled) | Rewards can still be claimed manually |
Operational Flow
Key Properties
1. **One vault per user** – All enrolled veDUST share the same UserVault.
2. **Non-custodial design** – Ownership of rewards and loans never leaves the user.
3. **Automatic cleanup** – Self-repay is cleared on transfers or merges.
4. **Inherited splits** – New tokens after a split maintain self-repay status.
5. **Verified swaps** – All swaps are validated against oracle prices with capped slippage.
6. **Controlled access** – Only the authorized executor can trigger automation.
***
### Why It Matters
The Self-Repayment System connects governance rewards and lending behavior into a single automated cycle. It rewards users who actively participate in governance with real financial benefits, while reducing overall protocol risk by improving borrower health.
Self-repay creates a continuous, closed loop:\ Governance rewards are earned by veDUST lockers.\ Those rewards automatically flow into the user’s vault.\ The vault repays debt, improving loan metrics and freeing borrowing capacity.
The result is a sustainable, incentive-aligned mechanism where governance participation strengthens both the individual and the protocol.
# Tokenomics
Neverland's token economy is designed to balance long-term sustainability, transparent governance, and controlled emissions. The native token, **Pixie Dust (DUST)**, powers every aspect of the protocol, from governance participation through **veDUST**, to liquidity incentives and deflationary mechanisms that strengthen value over time.
### Token Details
| Parameter | Description |
|---|---|
| Token Name | Pixie Dust (DUST) |
| Governance Token | veDUST (vote-escrowed locked DUST) |
| Total Supply | 100,000,000 DUST |
| Initial Circulation | 50,000 – 1,000,000 DUST at launch (Protocol-Owned Liquidity) |
| Emission Schedule | Structured 24-month distribution |
Emission Schedule
| Ecosystem Incentives | 40% | |
| Team | 20% | 24 months vesting |
| Treasury Reserve & Liquidity | 15% | |
| Marketing & Partnerships | 10% | 24 months vesting |
| Investors | 8% | 24 months vesting, 6 months cliff |
| Advisors | 5% | 24 months vesting |
| Expenses | 2% | 24 months vesting |
Deflationary Mechanisms
Neverland integrates several mechanisms to ensure that circulating supply decreases over time, reinforcing the value of DUST and rewarding long-term commitment.
**Governance-directed buybacks and burns** using **protocol-generated revenue.**\ Locking incentives **limit liquid token availability** and **help balance emissions** over time.\ Tokens penalized from early veDUST unlocks are burned, gradually reducing available supply.
Together, these mechanisms balance emissions and deflation, aligning protocol growth with token scarcity and long-term holder value.
# Governance
## Phase I Governance
Neverland Governance is live. veDUST holders can now vote directly on proposals that shape the protocol’s direction, making Neverland the first live governance system in the Monad ecosystem.
This page covers how Phase I governance works: the structure, the proposal process, voting mechanics, and how to participate.
{% hint style="info" icon="sparkle" %}
**New to governance?** Start by acquiring DUST and locking it for veDUST. Voting power is based on your veDUST power at the time a vote’s snapshot is taken, not your liquid DUST balance.
{% endhint %}
### Phase I Philosophy
Phase I is intentionally lightweight. Rather than introducing complex governance machinery from day one, the focus is on building participation habits, establishing clear processes, and decentralizing progressively as the ecosystem matures.
Meaningful decentralization doesn’t happen overnight. Early-stage realities, such as relatively low circulating supply, developing participation, and evolving operational structures, call for a framework that can adapt over time. Phase I is the starting point, not the destination.
### Governance Structure
Phase I separates responsibilities into two areas:
#### Operational governance
Handled by the core team. Covers day-to-day ecosystem coordination, partnerships, protocol operations, product improvements, communications, and ongoing execution. This separation allows Neverland to move efficiently during early growth without governance bottlenecks slowing development.
#### Directional governance
Where the community participates directly. Includes:
Protocol direction and strategy\ Governance framework changes\ Asset listings\ Major risk-related discussions\ Other strategic protocol matters
These decisions move through the formal governance process described below.
#### Emergency authority
The **Sentinel Safe** (Emergency Council) retains limited authority to pause or freeze protocol functionality in response to exploits, oracle failures, security incidents, or other critical risk events. This authority exists strictly to protect users and protocol integrity during emergencies.
### Governance Process
Governance moves through two stages: an open discussion phase (RFC) followed by a formal vote (NGV).
#### Stage 1: **Request For Comment (RFC)**
All proposals begin as an RFC on the [Neverland Governance Forum](https://governance.neverland.money).
A well-formed RFC should:
Clearly explain the problem being addressed\ Include supporting research or reasoning\ Propose a realistic solution or implementation path
Anyone can submit an RFC. During Phase I there is no fixed minimum discussion period; proposals mature organically through public discussion while the core team acts as governance facilitator, helping determine when a proposal is complete enough to proceed to a vote. This approach keeps discussions flexible while preventing incomplete proposals from rushing to a vote.
#### Stage 2: **Neverland Governance Vote (NGV)**
Once an RFC is ready, it advances to a formal vote on the [Neverland Vote Portal](https://vote.neverland.money).
### Voting Rules
| Parameter | Phase I value |
|---|---|
| Voting period | 7 days |
| Voting power basis | veDUST at snapshot |
| Initial quorum | 500,000 veDUST |
| Pass threshold | Simple majority |
How to Participate
#### Vote on a proposal
1. Lock DUST for veDUST (if you haven’t already)
2. Visit the [Vote Portal](https://vote.neverland.money)
3. Connect your wallet
4. Select an active proposal and cast your vote
Remember: your voting power is locked in at the snapshot taken when the vote begins.
#### Submit an RFC
1. Sign up on the [Governance Forum](https://governance.neverland.money)
2. Post your proposal in the RFC category with a clear problem statement, supporting reasoning, and a proposed path forward
3. Engage with community feedback and iterate
4. Once the proposal is sufficiently mature, it can advance to a formal NGV
#### Delegate your voting power
If you’d prefer not to vote directly, you can delegate your veDUST voting power, including for a fixed period, through the Vote Portal.
## What Comes Next
Phase I establishes the initial framework. It is intentionally an introductory structure - strong enough to build on, flexible enough to evolve.
As participation grows and governance processes mature, future phases will explore expanded decentralization, broader community responsibility, and additional governance mechanisms. These will be developed collaboratively with the DAO.
This is only the beginning. Welcome to Neverland Governance.
## Resources
[Neverland Governance Forum](https://governance.neverland.money)\ [Neverland Vote Portal](https://vote.neverland.money)
# Leaderboard
The [Neverland Leaderboard](https://app.neverland.money/leaderboard) is an incentive system that rewards productive protocol participation over time. Participation is automatic for all users interacting with the protocol. There is no opt-in, entry fee, or guaranteed payout.
Rewards are distributed probabilistically at the end of each cycle, weighted by participation. 100 winners each cycle receive a diamond-tier veDUST NFT containing a 250 DUST lock each.
### Tides
Leaderboard cycles are called **Tides**. Each Tide begins on a **full moon** and ends at the next full moon. Tides run on an approximately monthly cadence. Pearl balances reset at the start of each Tide. Pearls only accrue during the active Tide.
### Pearls
**Pearls** are a non-transferable accounting unit derived from on-chain activity. They are not tokens and do not represent ownership or guaranteed rewards.
Pearls are used to rank users within a Tide, and for weight probability during reward selection. They have no standalone value outside of the leaderboard system.
### Pearl Accrual
Pearls accrue daily based on protocol usage:
{% columns %}
{% column width="33.33333333333333%" %} **Supplying assets**
**Borrowing assets**
**veDUST power**
**DUST LP**
{% endcolumn %}
{% column width="66.66666666666667%" %}
`0.02 Pearls per $1 supplied / day`
`0.05 Pearls per $1 borrowed / day`
`0.25 Pearls per 1 veDUST power / day`
`0.25 Pearls per $1 LP value / day`
{% endcolumn %}
{% endcolumns %}
> Example: If you supply $1,000 for a full day: `0.02 × 1,000 × 1 day = 20 Pearls`
{% hint style="warning" %}
Accrual resets when the Tide ends.
{% endhint %}
### Pearl Settlement Timing
Pearls are **not updated instantly per transaction**.
User actions on the lending system, veDUST, and liquidity pools settle different components of Pearl accrual. The Leaderboard Keeper also periodically settles all positions (typically once per day), ensuring fair point accrual even when users are not actively interacting with Neverland.
Displayed Pearl balances reflect the **latest settlement**\ All elapsed time is captured\ **No Pearls are lost** between settlements
{% hint style="success" %}
Settlement timing affects **display**, not accrual.
{% endhint %}
### Multipliers
All bonuses are additive and then capped at a **10x total multiplier**.\
If additional multipliers or partnerships are introduced in the future, they will stack additively and remain subject to the same **10x total cap**.
```
Total Multiplier =
min(
1x (Base)
+ NFT Boost
+ Shiny Bonus
+ veDUST Boost (not currently present)
+ Testnet Bonus,
10x
)
```
### NFT Partnership Boosts
**Active Partnerships**
Some users receive Pearl multipliers applied to accrual. **Testnet participants** will receive a multiplier during the first Tide, and our **Partner NFT holders** receive an ongoing multiplier while the NFT is held. Multipliers apply automatically and may change over time.
Four partner collections are currently active: [**The 10k Squad**](https://x.com/the10kSquad), [**LilStars**](https://x.com/Lilstarrrs), [**RealNads**](https://x.com/RealNadsClub), and [**Overnads**](https://x.com/overnads).
| Project | Collection Address | Boost Structure |
|---|---|---|
| The 10k Squad | 0x818030837E8350ba63E64d7dC01A547fA73c8279 | Flat 20% |
| LilStars | 0xCaBF3c04B90f4Fe1B521Fcaf4AcB25D5df478e52 | Flat 15% |
| Overnads | 0xFb5BA4061f5c50b1DAA6C067Bb2dFB0A8EbF6a8D | 10% → 9% → 8.1% |
| RealNads | 0xe20c4f8CAcDb1854151f3E12144BdC919e608B9B | 10% → 9% → 8.1% |
A Multiplier applies **as long as the NFT is held**\ Boosts apply to **all Pearl sources** (Supply, Borrow, veDUST, LP)\ **Buys, sales, or transfers** of the NFT update your multiplier at the **next settlement**\ Holding more than one NFT from the same collection provides **no additional benefit**
This ensures fair distribution while preventing multiplier inflation through NFT concentration.
### Shiny Boost
Every **shiny veDUST** character in your wallet adds a flat **+5%** to all your Pearls. Shiny boosts stack **additively** with each other and with NFT partnership boosts.
```
Shiny Boost = 1 + (0.05 x number of shiny veDUST held)
```
> Example: 6 shiny veDUST = `1 + (0.05 x 6)` = **x1.30** applied to all Pearl accrual
In the combined **Multipliers** formula above, this enters as **Shiny Bonus**, `0.05x x number of shiny veDUST`, which is the amount above the base. The `1x` base is already a term in that formula and is counted once.
**Rules**
The boost applies **as long as the shiny veDUST is held**\ Boosts apply to **all Pearl sources** (Supply, Borrow, veDUST, LP)\ **Every** shiny counts, unlike partner collections, where duplicates within one collection add nothing\ **Buys, sales, or transfers** update your boost at the **next settlement**
Shiny characters are created with Character Magic consumables from the profile shop. See [Profiles & Shop](/profiles-and-shop).
### LP Position Requirements
#### Eligible Pool
* Pair: **DUST / DUST - Uniswap V2**
* Pool Address: `0x86dBF00485871C901C5129bD525348Db96c2eB2d`
#### Rate
```
0.25 Pearls per $1 per day
```
> Example: $5,000 LP for 12 hours (0.5 day) = `0.25 × 5,000 × 0.5 = 625 Pearls`
### Reward Selection Mechanics
At the end of each Tide, **100 winners** are selected using a **bucketed, weighted random process**.
For each rank bracket, winners are selected by running a **weighted random draw once per winner slot**. If a bracket has *Y* winners, the process runs *Y* draws, and each selected wallet is removed from the bracket before the next draw. In each draw, a user’s probability is proportional **to their Pearls relative to the total Pearls remaining** in that bracket, meaning probabilities apply per draw and higher Pearl balances increase expected outcomes without guaranteeing selection.
Bracket Distribution:
{% columns %}
{% column width="25%" %} 1–100
101–200
201–300
301+
{% endcolumn %}
{% column width="75%" %}
**50** winners
**25** winners
**15** winners
**10** winners
{% endcolumn %}
{% endcolumns %}
Only users with non-zero Pearls are eligible. Within each bracket, selection is random and weighted by Pearl balance. Higher participation increases odds but does not guarantee selection.
#### Selection Method
Weighted random per bracket\ Probability per draw:
```
Your Pearls ÷ Total Bracket Pearls
```
#### Example (Ranks 101–200)
Your Pearls: 5,000\ Bracket Total: 100,000
```
Chance per draw ≈ 5%
Expected wins ≈ 1.25
```
### Blacklist & Eligibility
Governance can blacklist addresses\ Blacklisted wallets do not appear on leaderboards\ Blacklisting is reversible\ Status is verifiable via `LeaderboardConfig`
### Point Precision & Display
UI shows human-readable values (e.g. `1,234.5`)\ Internally stored with **18 decimal precision**
Example:
```
1,234 Pearls
= 1234567890123456789012 (raw)
```
This prevents rounding drift and preserves exactness.
### Verification & Smart Contracts
Nothing here is abstract, discretionary, or opaque. Everything ties back to on-chain data.
#### Core Contracts
`EpochManager` handles all epoch lifecycle management, scheduling start and end times for each Tide. `LeaderboardConfig` manages Pearl accrual rates (deposit, borrow, veDUST, LP), LP pool eligibility, blacklist, and manual point adjustments. `VotingPowerMultiplier` defines veDUST tier multipliers based on voting power thresholds (currently unused). `NFTPartnershipRegistry` stores NFT partnership configurations and their boost multipliers. `LeaderboardKeeper` settles users on-demand, syncing their voting power, NFT holdings, and LP positions, ensuring points accrue fairly for everyone, even when they're not actively interacting with Neverland.
#### How to Verify
Pearl accrual derives from on-chain events\ Rate changes emit events with timestamps\ Position balances match lending pool state\ Multiplier changes are logged (NFT, veDUST)
| Contract | Address |
|---|---|
| EpochManager | 0xdA27A7745CBE958B0d00268cf63394A0d09c0216 |
| LeaderboardConfig | 0xDff18C7a928544449eF2Bb84c609f95427d7fcc8 |
| LeaderboardKeeper | 0x550eAaD1Ddc5Fd13Bc9818D99f985E7367D5D2B9 |
| NFTPartnershipRegistry | 0xAB71Ce6910F255CC61fAf78EBd69A2B3dbC26Cd9 |
| VotingPowerMultiplier | 0x9b203C61d03e64550BFbC17EF56438D1a67D80b7 |
Processes raw on-chain events\ Public source code\ Anyone can re-run it\ Leaderboard output matches chain state exactly
{% hint style="info" %}
The leaderboard indexer is **publicly accessible** under the Neverland GitHub organization [here](https://github.com/Neverland-Money/neverland-hyperindex).
Documentation is provided to allow anyone to **run the indexer locally** and independently validate leaderboard data against on-chain events.
{% endhint %}
### Tide History
Every settled Tide publishes a **draw report** containing the summary, the bracket breakdown, and all 100 winners with their rank, Pearl balance, and per-draw probability. The full leaderboard snapshot the draw ran against is published beside it as a separate `leaderboard.json`, and `winners.json` records the random seed, so anyone can reproduce the selection. All of it lives in the public [tide draw repository](https://github.com/Neverland-Money/neverland-tide-draw).
| Tide | Start (UTC) | End (UTC) | Participants | Report |
| ---: | ---------------- | ---------------- | -----------: | -------------------------------------------------------------------------------------------- |
| 1 | 2026-01-03 10:00 | 2026-02-01 22:00 | 2,257 | [Report](https://github.com/Neverland-Money/neverland-tide-draw/blob/main/tides/1/report.md) |
| 2 | 2026-02-01 23:00 | 2026-03-03 11:00 | 2,705 | [Report](https://github.com/Neverland-Money/neverland-tide-draw/blob/main/tides/2/report.md) |
| 3 | 2026-03-03 12:00 | 2026-04-02 03:00 | 2,814 | [Report](https://github.com/Neverland-Money/neverland-tide-draw/blob/main/tides/3/report.md) |
| 4 | 2026-04-02 04:00 | 2026-05-01 17:00 | 2,567 | [Report](https://github.com/Neverland-Money/neverland-tide-draw/blob/main/tides/4/report.md) |
| 5 | 2026-05-01 18:00 | 2026-05-31 10:00 | 2,456 | [Report](https://github.com/Neverland-Money/neverland-tide-draw/blob/main/tides/5/report.md) |
| 6 | 2026-05-31 15:30 | 2026-06-30 00:00 | 2,265 | [Report](https://github.com/Neverland-Money/neverland-tide-draw/blob/main/tides/6/report.md) |
| 7 | 2026-06-30 01:00 | 2026-07-29 15:00 | 2,160 | [Report](https://github.com/Neverland-Money/neverland-tide-draw/blob/main/tides/7/report.md) |
| 8 | 2026-07-29 16:00 | 2026-08-28 04:00 | 2,024 | [Report](https://github.com/Neverland-Money/neverland-tide-draw/blob/main/tides/8/report.md) |
| 9 | 2026-08-28 05:00 | 2026-09-26 17:00 | — | **Current Tide** |
Every settled Tide has drawn **100 winners** across the four rank brackets. Participant counts and draw reports are published once a Tide settles. Epoch windows are scheduled on-chain by `EpochManager` and can be read directly with `getEpoch( What’s Not Included
Currently disabled (may activate in future Tides):
veDUST holding tier multipliers\ Daily activity bonuses\ Referral bonuses\ Streak bonuses
### Fair Play & Anti-Gaming
#### Sybil Resistance
Multiple wallets allowed\ Rewards are probabilistic\ NFT, shiny, and testnet bonuses are wallet-bound
{% hint style="danger" %}
Splitting activity across multiple wallets does **not** increase overall winning odds, as it simply divides your Pearls and therefore splits your probability of selection.
{% endhint %}
#### Flash Loan Protection
Time-weighted accrual\ Same-block borrow/repay earns negligible Pearls\ Sustained positions matter
#### Design Intent
Higher Pearls improve odds\ No rank guarantees rewards\ Built for healthy usage habits
### Important Notes
Rewards are **not guaranteed.** Results are **not retroactive.** Ranking does **not** entitle users to rewards. Outcomes vary by Tide. The system is fair in **process**, not in individual outcomes.
Pearls are calculated mechanically from your **on-chain behavior** using published rates. Rewards are random but weighted. There are **no discretionary levers**, **no off-chain favoritism**, and **no invisible boosts**.
# Security
### Audits
| Auditor | Scope | URL | Date |
|---|---|---|---|
| OpenZeppelin | Lending System | 2021-11-01 | |
| Trail of Bits | Lending System | 2022-01-07 | |
| PeckShield | Lending System | 2022-01-10 | |
| ABDK | Lending System | 2022-01-26 | |
| PeckShield | Lending System | 2022-12-22 | |
| Sigma Prime | Lending System | 2022-12-26 | |
| Sigma Prime | Lending System | 2023-04-01 | |
| Composable Security | Tokenomics & Revenue | 2025-08-22 | |
| Composable Security | Tokenomics & Revenue | 2025-10-10 | |
| Octane | Oracle Adapters & Aggregators | 2026-02-17 | |
| Sherlock | Lending System | 2026-07-02 |
Monitoring
Monitoring is not a visibility layer. It is a control surface.
Neverland does not treat monitoring as a passive reporting layer. Coverage extends beyond privileged operations to broader protocol-critical activity across governance workflows, administrative control surfaces, oracle behavior, reserve conditions, and live transaction patterns. Operationally sensitive actions and abnormal protocol conditions are observed continuously so that unexpected behavior can be identified early, escalated immediately, and contained before it can propagate.
This monitoring is designed to provide visibility not only into what is executed, but into the surrounding protocol context in which activity occurs. The objective is straightforward: actions that affect protocol integrity, user safety, or system stability must remain observable, accountable, and defensible at every stage.
**Coverage**
Multisig proposals and privileged transaction flows\ Timelocked governance and risk actions\ Administrative role and ownership changes\ Oracle behavior and pricing integrity\ Risk parameter movement and reserve conditions\ Protocol-wide transaction patterns and abnormal activity
**Response**
Unexpected or inconsistent activity is treated as a security event\ Events are escalated internally for immediate review\ Preventive action can be taken before an issue is allowed to propagate\ Review continues until the affected action or protocol condition is fully understood
{% hint style="info" icon="shield" %}
Monitoring is not limited to isolated contract events.
{% endhint %}
Neverland also maintains ecosystem-level awareness around the conditions in which protocol activity occurs, including relevant market behavior, dependency health, and broader operational context. This helps distinguish routine activity from activity that may be technically valid at face value but inconsistent with the environment around it.
For example, an action may appear ordinary in isolation yet warrant immediate scrutiny when it coincides with unusual market conditions, irregular oracle behavior, unexpected administrative movement, or abnormal protocol activity.
Security monitoring is designed to evaluate that wider context, not just the single transaction.
### Operations
#### Safe Multisig Architecture
All privileged operations across Neverland are executed through dedicated multisig wallets. These multisigs act as the sole entry point for proposing and executing timelocked actions.
| Safe | Address | Role |
|---|---|---|
| Governance | 0x57976e192C45461F5958045a0bC57102e90440eD | PROPOSER_ROLE, CANCELLER_ROLE, EXECUTOR_ROLE on GovernanceTimelock & RiskTimelock |
| Sentinel | 0x06Fe1d4F4B7cA7D3d1fB3164968F0F7383D02e0E | EMERGENCY_ADMIN of Neverland's Lending Pools |
| Revenue | 0x909b176220b7e782C0f3cEccaB4b19D2c433c6BB | Authorized distributor of RevenueReward and revenue receiver of fees and revenue |
| Treasury | 0xe72df2DDE84880DD706C5976E92ed34BB586A38F | Neverland Reserves |
| Guardian | TBA | External party CANCELLER_ROLE of GovernanceTimelock & RiskTimelock |
Transactions are detected immediately upon submission\ Matched against the pre-announced operation
Monitoring system broadcasts a clear breakdown of what the transaction does
Signers re-verify the live transaction before execution signatures are completed\ Every signature is recorded and tracked against the expected signer set
System confirms completion\ Publishes a final verification event with full context
Mismatched calldata\ Unexpected nonce usage\ Missing or invalid signer acknowledgments\ Unverified on-chain submissions
**Response**
Transaction is immediately cancelled\ Execution is blocked\ Incident is escalated internally for review
There is zero tolerance for mismatch between what is approved offchain and what is executed onchain.
***
### Timelocks
All governance and risk parameter changes are enforced through on-chain timelocks. No privileged action can take immediate effect, every change must be publicly scheduled, wait through a mandatory delay, and only then be executed. This gives users, integrators, and monitoring systems a guaranteed window to review upcoming changes and react before they take effect.
#### Two-Lane Architecture
Neverland operates two independent timelocks, each purpose-built for a different class of action:
| Timelock | Minimum Delay | Scope |
|---|---|---|
GovernanceTimelock | 24H | Lending governance (pool admin, ACL admin), proxy upgrades for tokenomics, revenue, leaderboard, and nToken wrappers |
RiskTimelock | 1H | Risk parameter changes (supply/borrow caps, reserve configurations, interest rate updates) |
**GovernanceTimelock**: 24-hour floor (`86400` seconds)\ **RiskTimelock**: 1-hour floor (`3600` seconds)
A governance proposal can *increase* the active delay beyond the floor but can never *reduce* it below. Any attempt to call `updateDelay` with a value below the floor reverts with `DelayBelowMinimumFloor`. This guarantees a permanent minimum observation window regardless of future governance decisions.
The contract that enforces this is `NeverlandTimelockController`, which extends [OpenZeppelin v5's TimelockController](https://docs.openzeppelin.com/contracts/5.x/api/governance#TimelockController) with the floor check.
#### Self-Administered Role Model
Each timelock holds its own `DEFAULT_ADMIN_ROLE`, meaning that any change to the timelock's role assignments (adding or removing proposers, executors, or cancellers) must itself be scheduled and executed through that same timelock's delay.
{% hint style="warning" icon="xmark" %}
There is no external admin that can reconfigure the timelocks instantly
{% endhint %}
| Role | Holder | Capability |
|---|---|---|
DEFAULT_ADMIN_ROLE | Timelock itself | Grant/revoke timelock roles |
PROPOSER_ROLE | Governance Safe (multisig) | Schedule new operations |
EXECUTOR_ROLE | Governance Safe (multisig) | Execute operations after the delay |
CANCELLER_ROLE | Governance Safe (multisig) | Cancel pending operations |
**ACL admin authority**\ `PoolAddressesProvider.getACLAdmin()`\ **Protocol ownership surfaces:**\
`PoolAddressesProvider`\ `PoolAddressesProviderRegistry`\ `ReservesSetupHelper`\ `WrappedTokenGatewayV3`\ **All proxy upgrades:**\ Core Tokenomics & Revenue `ProxyAdmin`\ Leaderboard `ProxyAdmin`\ Wrapped Tokens `ProxyAdmin`\ Self-Repay Vaults `UserVaultBeacon`
{% endtab %}
{% tab title="RiskTimelock (1-hour delay)" %}
Risk parameter administration: `RISK_ADMIN` on `ACLManager`
{% endtab %}
{% endtabs %}
#### Future Timelock Canceller Role
Neverland will introduce a new dedicated multisig wallet with the `CANCELLER_ROLE` on both `GovernanceTimelock` and `RiskTimelock` within the system.
**Responsibilities**
Operates independently from proposers and executors\ Has exclusive authority to cancel scheduled operations during the delay window\ Acts as an additional safety layer in case of compromised proposals or changing conditions
This adds another layer of defense by ensuring scheduled operations can be halted by an external trusted authority before execution if needed. This multisig, **“Guardian Safe”**, will consist of one Neverland team member alongside several external security analysts and trusted ecosystem participants, with a high threshold to prevent griefing and ensure responsible use.
#### What Remains Outside Timelocks
Emergency pause actions are intentionally kept outside the timelock system. The **“Sentinel Safe”** holds `EMERGENCY_ADMIN` directly and can pause the protocol without delay. This is a deliberate design choice; an emergency pause that requires a 24-hour wait would defeat its purpose.
Certain runtime governance surfaces (e.g., `Dust`, `DustLock`, leaderboard configuration) also remain under direct ownership, as they do not control user funds or protocol upgrades.
***
### Posture
#### Internal Security & Monitoring
In addition to external partners, Neverland maintains in-house security capabilities.
**Internal coverage**
Dedicated security analysts monitor all protocol activity\ Multisig operations, oracle behavior, and risk parameters are continuously tracked
**Monitoring capabilities**
Real-time alerting covering all Neverland transactions\ Nadette AI Assistant built-in multisig transaction summary alerts\ Public Indexer tracking protocol-wide admin roles\ Automated sanity checks\ Immediate intervention when required
#### External Security Partnership
Neverland works closely with 
[Octane](https://www.octane.security/) for continuous security monitoring and analysis via AI-driven tooling.
**Scope**
Review of critical components such as oracle adapters and protocol integrations\ Security tooling and infrastructure support across the protocol
{% hint style="success" icon="shield" %}
**Security is treated as an ongoing process.**
Every transaction, role change, and parameter update is observed, verified, and accountable.
{% endhint %}
# Profiles & Shop
Neverland Profiles bring your wallet identity, cosmetics, badges, activity, and veDUST collection into one public surface.
You can open a profile by wallet address, linked X handle, or your own shortcut. The same profile also gives you a home for themes, titles, gifts, and shop inventory.
***
### Profile access
Profiles support three entry formats: **address profiles** at `/profile/0x...`, **handle profiles** at `/profile/@handle`, and **your own shortcut** at `/profile/me`.
***
### Visibility settings
You manage profile visibility from **Profile Settings**. Each mode changes how much identity Neverland resolves and shows around your wallet.
| Setting | What others can see |
|---|---|
| Private | Address-only view. No handle, avatar, title, theme, NFT identity, or personalized profile identity. Onchain footprint can still remain visible because wallet data is public. |
| Semi-Public | Handle, avatar, level, rank, title, theme, badges, and NFT artwork gallery. NFT token IDs, character names, lock amount, duration, veDUST power, lending cards, and LP cards stay hidden. |
| Public | Full profile identity, NFT details, lending positions, LP positions, badges, titles, theme, and public profile surfaces. |
Profile actions
Profile owners can share their profile to X, copy the canonical profile link, download a share card as a PNG, or open **Settings** directly from the profile header.
| Action | What it does |
|---|---|
| Share | Opens an X post composer with your Neverland profile link. |
| Copy | Copies your canonical profile link. |
| Download | Downloads your profile share card as a PNG. |
| Settings | Opens profile settings. |
Profile settings
Profile Settings let you upload a custom avatar, reset that avatar back to X, resync your X handle and display image, set a display name up to 18 characters, and switch between Private, Semi-Public, and Public visibility.
Avatar uploads support common image formats and are cropped square. If you leave the display name blank, Neverland falls back to your X name.
***
### Levels
Profiles show a level based on all-time Pearls earned from Neverland leaderboard activity. The maximum level is 40.
| Level | Frame family |
| ----: | ------------ |
| 1-10 | Sapphire |
| 11-20 | Emerald |
| 21-30 | Ruby |
| 31-40 | Diamond |
Private views hide level presentation details from the personalized header, but profile badges can still appear.
***
### Badges
Badges are earned profile achievements. They can appear on every visibility tier, including **Private**.
| Badge | How it is earned |
|---|---|
| OG | Wallet had Neverland activity during the launch window: Nov 24, 2025 to Feb 24, 2026 UTC. |
| Legendary Holder | Wallet currently holds at least one Legendary veDUST character. |
| Olympic Gold Medalist | Wallet currently holds a first-place Olympic edition character. |
| Olympic Silver Medalist | Wallet currently holds a second-place Olympic edition character. |
| Olympic Bronze Medalist | Wallet currently holds a third/fourth-place Olympic edition character. |
| Bug Hunter | Wallet has linked Discord and currently holds the Bug Hunter role. |
| Tide Winner | Wallet won a settled monthly Tide. One badge can appear per Tide won. |
| Title Badges | Some earned Name Titles can also appear as profile badges. |
Nadette’s Shop
Nadette’s Shop is the cosmetic layer of the profile system. Profile owners enter through the shop door on their own profile. Visitors can see the shop for discovery, but they cannot enter another user’s shop directly unless they are gifting.
The shop is organized into **Character Magic**, **Profile Themes**, and **Name Titles**. Paid items use DUST. From the shop, you can add items to a basket, claim eligible cosmetics, preview themes, equip owned items, manage inventory, send gifts, and build a wish list.
***
#### Character Magic items
Character Magic items are consumables used on veDUST NFT characters.
| Item | Cost | Compatible with | What it does |
|---|---|---|---|
| Enchanted Coral | 5 DUST | Mermaid NFTs | Attempts to make a Mermaid character shiny. |
| Fairy Wand | 5 DUST | Pixie NFTs | Attempts to make a Pixie character shiny. |
| Lucky Doubloon | 5 DUST | Pirate NFTs | Attempts to make a Pirate character shiny. |
| Rainbow Fruit | 5 DUST | Lost Boy NFTs | Attempts to make a Lost Boy character shiny. |
| Tick-Tock Clock | 20 DUST | Shiny attempts | Automatically consumes to bypass a token’s daily shiny-attempt cooldown. |
| Mysterious Potion | 50 DUST | Legendary NFTs | Attempts to make a Legendary character shiny. |
| Rare Crystal | 50 DUST | All eligible NFTs | Guaranteed character reroll within the same archetype. |
| Transmogrification Stew | 50 DUST | Lost Boy, Mermaid, Pirate, Pixie NFTs | Guaranteed character reroll into another core archetype, excluding Legendary. |
Profile themes
Themes change the visual background and styling of your profile.
| Theme | Cost | How to get it |
|---|---|---|
| Explorer | Free | Starter theme. |
| Island Believer | 25 DUST | Buy in shop. |
| Island Native | 25 DUST | Buy in shop. |
| Moonlight Dreamer | 25 DUST | Buy in shop. |
| Shopkeeper’s Assistant | 25 DUST | Buy in shop. |
| Mermaid’s Cove | Free claim | Provide at least $20,000 DUST liquidity. |
| Pirate’s Bay | Free claim | Hold at least 50,000 veDUST power. |
Name titles
Name Titles appear before or after your display name.
* **Prefix example:** `Tide Rider Catalyst`
* **Suffix example:** `Catalyst the Olympian`
**Purchasable titles**
| Title | Cost | Placement |
| --------------- | ------: | --------- |
| Tide Rider | 5 DUST | Prefix |
| Pixie Confidant | 10 DUST | Prefix |
**Starter title**
| Title | Cost | Placement |
| ------------ | ---: | --------- |
| the Explorer | Free | Suffix |
**Claimable achievement titles**
| Title | Placement | How to unlock |
|---|---|---|
| Olympian | Suffix | Own at least one Neverland Olympics veDUST NFT. |
| Collector | Suffix | Collect at least 20 unique characters. |
| Curator | Suffix | Collect at least 40 unique characters. |
| The Legendary | Prefix | Collect all 50 characters, including every Legendary. |
| Pixie Catcher | Suffix | Collect all 10 Pixie characters. |
| Pirate Captain | Prefix | Collect all 10 Pirate characters. |
| Lost Boy Leader | Suffix | Collect all 10 Lost Boy characters. |
| Lagoon Lounger | Suffix | Collect all 10 Mermaid characters. |
| Deep Sea Diver | Suffix | Provide more than $10,000 liquidity to the Neverland USDC/DUST pool. |
| Diamond Hoarder | Suffix | Hold at least 10,000 veDUST power inside an infinite lock. |
| Sea of Supply Sailor | Prefix | Supply more than $50,000 across Neverland lending markets. |
| Borrower’s Bay Buccaneer | Prefix | Run more than 3x leverage on Neverland lending markets. |
Inventory
Your Inventory contains owned themes, titles, consumables, and unopened gifts. From here, you can equip or unequip themes and titles, use consumables on compatible veDUST NFTs, open received gifts, and check item quantities.
Consumables stack by quantity. Themes and titles are unique, so duplicate purchases are disabled once owned.
***
### Wish List
Your Wish List lets other users know which paid shop items you want. Profile owners can open the wish list from the profile page, select **Edit Wishlist**, add or remove eligible paid items, and then save or clear the draft. Visitors can open a visible profile’s wish list, click a wished item, and start a gift purchase from there.
Claimable achievement items and starter items are not wish-list eligible. The wish list is only for purchasable gifts.
***
### Gifting
Visitors can gift shop items from another user’s profile. Gift mode supports paid gifts for another profile, multiple items in one basket, optional gift notes, and direct gifting from wish-list items. It also shows which items the recipient has already wished for.
Gift notes can be up to **300 characters**. Received gifts appear as gift boxes in the recipient’s inventory, and the recipient opens the gift box to receive the item.
{% hint style="info" %}
Themes and titles cannot be gifted again if the recipient already owns them, while consumables can be gifted repeatedly.
{% endhint %}
Sender identity follows the sender’s profile privacy settings. **Public** or **Semi-Public** senders can show a display name or handle, while **Private** senders appear as a shortened wallet address.
***
### Important notes
{% hint style="warning" %}
* Wallet data is public onchain. Visibility controls what Neverland resolves and displays as profile identity, but it does not make wallet activity private.
* Public and Semi-Public profiles are discoverable by handle, while Private profiles remain address-only.
* Badges may still show on Private profiles.
* Some achievement cosmetics are revocable if the qualifying wallet state changes, while character-collection titles are designed to remain owned once earned.
{% endhint %}
# Smart Contracts
Mainnet
Neverland is built on a modular architecture designed around [`neverland-lending-core v1.1.0`](https://www.npmjs.com/package/@neverland-money/lending-core). The core is derived from Aave V3 and hardened by Neverland with its own precision and security patches, then extended with custom layers for incentives, governance, and self-repaying automation. All contracts are deployed on **Monad Mainnet**. Most sit behind transparent proxies governed by Neverland's **ProxyAdmin** contracts; the rest are deployed directly and cannot be upgraded.
***
### Primary Tokens
| Token | Type | Address |
|---|---|---|
| DUST | ERC-20 | 0xAD96C3dffCD6374294e2573A7fBBA96097CC8d7c |
| veDUST | ERC721-C | 0xBB4738D05AD1b3Da57a4881baE62Ce9bb1eEeD6C |
Tokenization
{% tabs %}
{% tab title="Listed Reserves" %}
| Token | Address | Active |
|---|---|---|
| WMON | 0x3bd359C1119dA7Da1D913D1C4D2B7c461115433A | true |
| WBTC | 0x0555E30da8f98308EdB960aa94C0Db47230d2B9c | true |
| cbBTC | 0xd18B7EC58Cdf4876f6AFebd3Ed1730e4Ce10414b | true |
| WETH | 0xEE8c0E9f1BFFb4Eb878d8f15f368A02a35481242 | true |
| AUSD | 0x00000000eFE302BEAA2b3e6e1b18d08D69a9012a | true |
| USDC | 0x754704Bc059F8C67012fEd69BC8A327a5aafb603 | true |
| USDT0 | 0xe7cd86e13AC4309349F30B3435a9d337750fC82D | true |
| sMON | 0xA3227C5969757783154C60bF0bC1944180ed81B9 | true |
| gMON | 0x8498312A6B3CbD158bf0c93AbdCF29E6e4F55081 | true |
| shMON | 0x1B68626dCa36c7fE922fD2d55E4f631d962dE19c | true |
| earnAUSD | 0x103222f020e98Bba0AD9809A011FDF8e6F067496 | true |
| XAUt0 | 0x01bFF41798a0BcF287b996046Ca68b395DbC1071 | true |
| loAZND | 0x9c82eB49B51F7Dc61e22Ff347931CA32aDc6cd90 | false |
| Token | Address |
|---|---|
| nWMON | 0xD0fd2Cf7F6CEff4F96B1161F5E995D5843326154 |
| nWBTC | 0x34c43684293963c546b0aB6841008A4d3393B9ab |
| nCBBTC | 0xcc7f5F78Bedfc65c2fDD93C7537832eEa1324774 |
| nWETH | 0x31f63Ae5a96566b93477191778606BeBDC4CA66f |
| nAUSD | 0x784999fc2Dd132a41D1Cc0F1aE9805854BaD1f2D |
| nUSDC | 0x38648958836eA88b368b4ac23b86Ad44B0fe7508 |
| nUSDT0 | 0x39F901c32b2E0d25AE8DEaa1ee115C748f8f6bDf |
| nSMON | 0xdFC14d336aea9E49113b1356333FD374e646Bf85 |
| nGMON | 0x7f81779736968836582D31D36274Ed82053aD1AE |
| nSHMON | 0xC64d73Bb8748C6fA7487ace2D0d945B6fBb2EcDe |
| nEARNAUSD | 0xaCaaA891b30E13D024AB67b6EcA9c2EcBD8cf52b |
| nXAUT0 | 0x3351683194670680Edd1700Bfbe146403684AEdf |
| nLOAZND | 0x293e2f01a38Fe690Eb8E570AB952b24b225113a7 |
| Token | Address |
|---|---|
| variableDebtWMON | 0x3acA285b9F57832fF55f1e6835966890845c1526 |
| variableDebtWBTC | 0x544a5fF071090F4eE3AD879435f4dC1C1eeC1873 |
| variableDebtCBBTC | 0x74F2ef7c9cf6D3a3587c3F91569827CC17715F08 |
| variableDebtWETH | 0xdE6C157e43c5d9B713C635f439a93CA3BE2156B6 |
| variableDebtAUSD | 0x54fC077EAe1006FE3C5d01f1614802eAFCbEe57E |
| variableDebtUSDC | 0xb26FB5e35f6527d6f878F7784EA71774595B249C |
| variableDebtUSDT0 | 0xa2d753458946612376ce6e5704Ab1cc79153d272 |
| variableDebtXAUT0 | 0x9F31559410bC89660A03546dC906763F9F2648F9 |
| Token | Address |
|---|---|
| wnWMON | 0xdB39A9D4a1f1b4e93A5684d602207628aD60613C |
| wnWBTC | 0x8959f4E6ED1f4567a464959793d5f8f6f33C1C8B |
| wnCBBTC | 0x98a297e6424787E57Af119949d7E00b721F832BB |
| wnWETH | 0xB3b850ac62B89fe9f4eFB652b516108a8aEb8848 |
| wnAUSD | 0x82c370ba90E38ef6Acd8b1b078d34fD86FC6bAC9 |
| wnUSDC | 0x8d5c2Df3Eef09088Fcccf3376D8EcD0Dd505f642 |
| wnUSDT0 | 0x4e8aaecCE10ad9394e96fE5f2bd4e587A7B04298 |
| wnSMON | 0x08139339dd9A480CEB84D9C7CcE48BE436dB20b3 |
| wnGMON | 0x29D2075E5151B1A6863bDC40EA86bD5e8aFd1705 |
| wnSHMON | 0x5e073494678fB7FA4a05bB17d45941Dd9Dc469c1 |
| wnEARNAUSD | 0xD45D54ad7Ae6D5dEdb0De7B283Fe0b4e2ba40217 |
| wnXAUT0 | 0x22139A346b6312EB0A9812C67CfCe4A694676d59 |
| wnLOAZND | 0xD786F7569C39A9F64E6A54Eb77db21364E90F279 |
| Contract | Address |
|---|---|
| StaticATokenFactory (Proxy) | 0x81148e8e1D9910080317E11c9f178559Ba23Bc80 |
| StaticATokenFactory (Impl.) | 0x6D48BeEa61aA165a54f0DD937919204F1A59ED1B |
Architecture Overview
Neverland’s deployment consists of several logical layers:
| Layer | Purpose | Examples |
|---|---|---|
| Lending System | neverland-lending-core | Pool, PoolConfigurator, ACLManager, ReservesSetupHelper |
| Governance & Tokenomics | veDUST locking, emissions, and reward routing | DustLock, DustRewardsController, RevenueReward |
| Self-Repayment System | Automation layer connecting rewards to loan repayment | UserVault, UserVaultFactory, UserVaultRegistry |
| Utilities | Aggregated data and helper functions for the app UI and integrations | NeverlandUiProvider, NeverlandDustHelper |
| Proxy Admin | Controls upgradeability of all transparent proxies | ProxyAdmin |
Proxies vs. Implementations
Most contracts use the **Transparent Proxy** pattern.
**Proxy** = the address users interact with (stateful).\ **Implementation** = the logic contract behind the proxy (upgradable).\ **ProxyAdmin** manages upgrade permissions. Neverland runs three, one each for core tokenomics, the leaderboard, and the wrapped tokens, listed under Upgradables Administration below.
When verifying interactions or events on explorers, always reference the **Proxy** address.
***
### Lending System
{% tabs %}
{% tab title="Core Lending" %}
| Contract | Address |
|---|---|
| ACLManager | 0x73A78AFa04b629e22db3BEC357bfc4a8B4f149DF |
| Pool (Proxy) | 0x80F00661b13CC5F6ccd3885bE7b4C9c67545D585 |
| Pool (Impl.) | 0x507c53dE7B334dae1ECFE2E6d8cF75716431c3fC |
| PoolAddressesProvider | 0x49D75170F55C964dfdd6726c74fdEDEe75553A0f |
| PoolAddressesProviderRegistry | 0xD0CCDe10CAcd12f1c839Db6400B82a82ab90fa9B |
| PoolDataProvider | 0xfd0b6b6F736376F7B99ee989c749007c7757fDba |
| Contract | Address |
|---|---|
| PoolConfigurator (Proxy) | 0x193672B2454850EE247435E365a87F7cb857a0f7 |
| PoolConfigurator (Impl.) | 0x5AB804148E72C0E83e445624bD07d0f247b5ad22 |
| ReservesSetupHelper | 0xE7D17A88C66b4ED0b73872937cdC5e081C118DcD |
| Name | Address | Reserves |
|---|---|---|
| Volatile Easy High | 0xbDad50bda8F044569e076AEB2418c0910F10E726 | WMON, WBTC, cbBTC, WETH, XAUt0 |
| Stable Easy High | 0x3eDC7F33E5564848c6751A1D9192E0650bc7ECcE | USDC, USDT0, AUSD |
| Volatile One | 0x9B4528918159e1ae937740051Fb69bcD4E164cc3 | sMON, gMON, shMON |
| earnAUSD | 0x21F3a41061BC0F527a71D5AD5Dc18d2594C14B43 | earnAUSD |
| Stable Flatten | 0xf462fEF6bf18AfeC12C93474Cce5C2FDF94034f4 | loAZND |
Isolated Markets
Alongside the main market, Neverland lists **Pendle Principal Tokens (PT)** in dedicated **isolated pools**. Each isolated market is independent infrastructure, with its own `Pool`, `PoolConfigurator`, `ACLManager`, `AaveOracle`, `PoolDataProvider` and reserve tokens, registered under the shared **PoolAddressesProviderRegistry** (`0xD0CCDe10CAcd12f1c839Db6400B82a82ab90fa9B`).
Isolation means a PT listing can never change the collateral rules, caps, or liquidity of the main market, and a position in one pool is never netted against a position in another.
The **PT is collateral only** and can never be borrowed.\ The **settlement asset is the only borrowable reserve**, and is never usable as collateral.\ There is **no E-Mode category** in an isolated pool.\ The AaveOracle **fallback is set to** `address(0)` on purpose: a stale or zero price freezes the market rather than letting it misprice collateral.
{% hint style="info" %}
Each PT is priced by a Neverland `PendlePtDiscountOracleAdapter`, which discounts the settlement asset’s USD price linearly to maturity. At maturity the discount reaches zero and the PT prices one-to-one with its settlement asset.
{% endhint %}
{% tabs %}
{% tab title="Pendle AUSD" %}
| Property | Value |
|---|---|
| Market ID | Neverland Pendle AUSD Isolated Pool |
| Provider ID | 2 |
| PT Maturity | 8 October 2026 |
| Collateral | PT-AUSD-8OCT2026 (non-borrowable) |
| Borrowable | AUSD |
| Contract | Address |
|---|---|
| PoolAddressesProvider | 0xb80397A931FcFdA3aC999a3a5639C328Dc72A58F |
| Pool (Proxy) | 0x690AD251a0D9c8A47cf1bC5e4C0dBd3131eE09D3 |
| Pool (Impl.) | 0x0a2373D6D2a97A477EbACE7F9419a650C8625AD4 |
| PoolConfigurator (Proxy) | 0x281aC1f6Cbb640c24E5582f70FDA192Db397D191 |
| PoolConfigurator (Impl.) | 0x26dFd9e953699A4474f70eFAE4Dd5df454FF2f64 |
| ACLManager | 0x589Fa97F64C1241B846AA44A6fee479f975b17a8 |
| PoolDataProvider | 0xeEb78818C026A3c1b82804627d101e27Ce5E60CB |
| ReservesSetupHelper | 0xAF1B0C0eD94eCD6e7998a8F0f36d414d9C0113EC |
| AaveOracle | 0x995E806f9f1434111a785C22a021D38456bB2798 |
| Interest Rate Strategy | 0xb60CBB281b753Cbf03bA77d8d8D023552EC07b66 |
| Reserve | Underlying | nToken | Variable Debt Token |
|---|---|---|---|
| AUSD | 0x00000000eFE302BEAA2b3e6e1b18d08D69a9012a | 0xF58E7aDC6F4eC524C09B7b6f058d3aB48D7CD65e | 0x9da2d91D0CcF2daaf16B8Bd2778593Af1C369657 |
| PT-AUSD-8OCT2026 | 0x9FC74f8Ed616B5BaF52a170caa97d6d3898602d1 | 0xf5A4D774aFFD6f22B6fE76ce20BB9312F23C8784 | n/a |
| Asset | Source | Contract |
|---|---|---|
| AUSD | Chainlink AUSD/USD | 0xE20751C7B5867bCBef815ffc1b284c3f412a9e13 |
| PT-AUSD-8OCT2026 | PendlePtDiscountOracleAdapter | 0x1Df73A14709FeEAc83386fd1b8099dEc4B00f789 |
| Property | Value |
|---|---|
| Market ID | Neverland Pendle shMON Isolated Pool |
| Provider ID | 3 |
| PT Maturity | 18 March 2027 |
| Collateral | PT-shMON-18MAR2027 (non-borrowable) |
| Borrowable | WMON |
| Contract | Address |
|---|---|
| PoolAddressesProvider | 0x300fA05F6fc9503EAbaAcB1dec7C35D65229f86f |
| Pool (Proxy) | 0x99Cbb76041fB8206E2459085Afb98BBc683Db527 |
| Pool (Impl.) | 0xf921266d241A324cB436f609C10495e7815a37F2 |
| PoolConfigurator (Proxy) | 0x490089AFc4e3E4CcF37E431c9cF770B9DFC5a504 |
| PoolConfigurator (Impl.) | 0xC1b3c9D83C8Ef1dCE869A289aAd4b035BE1ac7aA |
| ACLManager | 0x9140082F52a09879DA6E3f1C6D9B2598162b6A73 |
| PoolDataProvider | 0xD2638FB3b0b5cb81a6Cdc856Cb72f95CB4103C43 |
| ReservesSetupHelper | 0x2909A728eF474E529D8bF0565C043eb16CF6450F |
| AaveOracle | 0x2C6159B137fCc98fC6a9390Ec7d866dcAeE693B0 |
| Interest Rate Strategy | 0x980b30F9BF389Cc57158174DC4432E887606f896 |
| NeverlandNativeGateway | 0x05e61c923093e569401Edc2ac6AeAE01E7e60a53 |
| Reserve | Underlying | nToken | Variable Debt Token |
|---|---|---|---|
| WMON | 0x3bd359C1119dA7Da1D913D1C4D2B7c461115433A | 0xe0fDCBB0855f950dDf5f21595383f7f2a173E01e | 0x02fC32CD3c8220841eEc85da9F99D9B2Dd883BbC |
| PT-shMON-18MAR2027 | 0xA7deaC306A4520f4f2F94D150Ca2fBd13080b607 | 0xe3d0A73c78506c2D6DF38A1148327E918a555E1D | n/a |
| Asset | Source | Contract |
|---|---|---|
| WMON | Chainlink MON/USD | 0xBcD78f76005B7515837af6b50c7C52BCf73822fb |
| PT-shMON-18MAR2027 | PendlePtDiscountOracleAdapter | 0x6db6a7b0f7Ac248226aF14997223fe9D3088f204 |
Governance & Tokenomics
{% tabs %}
{% tab title="Governance" %}
| Contract | Address |
|---|---|
| Dust (Proxy) | 0xAD96C3dffCD6374294e2573A7fBBA96097CC8d7c |
| Dust (Impl.) | 0xF59df2e38e23406c80ac778CCAA4319BAbe0D0d3 |
| DustLock (Proxy) | 0xBB4738D05AD1b3Da57a4881baE62Ce9bb1eEeD6C |
| DustLock (Impl.) | 0xf7533D3bfC31F0D3F6292e2336DA84434435f3b5 |
| DustLockLegendaryLedger | 0x367973382fa8Fc9508B5C8f4B0F9EEd462aF3185 |
| Contract | Address |
|---|---|
| DustRewardsController (Proxy) | 0x57ea245cCbFAb074baBb9d01d1F0c60525E52cec |
| DustRewardsController (Impl.) | 0x6aD1EcdA817ECB7696D21f6e600C7ec44AcFB1e6 |
| DustLockTransferStrategy | 0xa966190d7BD099718110103d1778bb232Bd1661E |
| Contract | Address |
|---|---|
| RevenueReward (Proxy) | 0xff20ac10eb808B1e31F5CfCa58D80eDE2Ba71c43 |
| RevenueReward (Impl.) | 0x7E5E603DF59278aF2B2d12521c0EC6f14fD2df8d |
| Contract | Address |
|---|---|
| UserVaultRegistry | 0x794CCdb375Ab08C340528a71Ba433a9016c657A5 |
| UserVaultImplementation | 0x0904B276a467CfCBD7B2F900aDaAAD783AEeC98F |
| UserVaultBeacon | 0xc9Fe3Db9b14A538FaB2eeBa33a8FeaB6ED7DdCeb |
| UserVaultFactory (Proxy) | 0xe82f2fa836BC5DB42a36C66027c0113BcAA28143 |
| UserVaultFactory (Impl.) | 0x95AF995C9dcB1b6cFFEe6d81631dab5527884370 |
| Contract | Address |
|---|---|
| NeverlandProfileItemsSeller (Proxy) | 0xcEE8d6d42a37a9d721B41CeFa16DaB7F0d0a14EB |
| NeverlandProfileItemsSeller (Impl.) | 0x81882ce65044073F005cb6d3180A36fe1ef898F9 |
| SpecialEditionRegistry (Proxy) | 0x9A0231CeaB25EA0D820cfE73bFC3cd2D7681d532 |
| SpecialEditionRegistry (Impl.) | 0xC1Ab101608a493dbcf91Af13ba9436802Dc8cdcf |
Helpers
| Contract | Address |
|---|---|
| WalletBalanceProvider | 0x8911Db480C1c0c1E06f17C2Bc76b26D861e40D47 |
| UiPoolDataProviderV3 | 0xcE58B4E4F082139804E3426129Ecfc1c1657A72a |
| WrappedTokenGatewayV3 | 0x800409dBd7157813BB76501c30e04596Cc478f25 |
| NeverlandUiProvider | 0x74132CE97c02E286d221715B3df6094790A1DEc1 |
| NeverlandDustHelper | 0x4b80e62364Ee452e8C9d3ea342E445f515A2CD9b |
Oracle System
| Market | AaveOracle |
|---|---|
| Main Market | 0x94bbA11004B9877d13bb5E1aE29319b6f7bDEdD4 |
| Pendle AUSD Isolated | 0x995E806f9f1434111a785C22a021D38456bB2798 |
| Pendle shMON Isolated | 0x2C6159B137fCc98fC6a9390Ec7d866dcAeE693B0 |
Chainlink Oracles
[**Chainlink**](https://chain.link/) is the **industry-standard oracle platform** bringing the capital markets onchain and the **market leader** powering the **majority of decentralized finance** (DeFi).
Neverland uses Chainlink **price feeds** for **all major assets**, securing **over 99%** of the protocol’s TVL. Each feed provides USD-denominated prices with **8 decimals**, which are validated through the AaveOracle contract and standardized across the protocol.
| Asset | Trigger | Source | Contract |
|---|---|---|---|
WMON | 1h / 0.02% | MON/USD | 0xBcD78f76005B7515837af6b50c7C52BCf73822fb |
WBTC | 1h / 0.02% | BTC/USD | 0xc1d4C3331635184fA4C3c22fb92211B2Ac9E0546 |
cbBTC | 1h / 0.02% | cbBTC/USD | 0x3dDc1bAE752aaEe31b577bF844c799C349A1d6BD |
USDC | 1h / 0.05% | USDC/USD | 0xf5F15f188AbCB0d165D1Edb7f37F7d6fA2fCebec |
USDT0 | 1h / 0.05% | USDT/USD | 0x1a1Be4c184923a6BFF8c27cfDf6ac8bDE4DE00FC |
AUSD | 1h / 0.05% | AUSD/USD | 0xE20751C7B5867bCBef815ffc1b284c3f412a9e13 |
WETH | 1h / 0.05% | ETH/USD | 0x1B1414782B859871781bA3E4B0979b9ca57A0A04 |
earnAUSD | 24h / 0.05% | earnAUSD/AUSD | 0xF25c84187a7608036b6660205B6068DBc9560dB6 |
sMON | 24h / 0.05% | sMON/MON | 0xF285a4B6e38151E27bBb846197707C8B9BAf8D55 |
shMON | 24h / 0.05% | shMON/MON | 0x39B76F22dcf8A93b68C72Fe2e63B3530168D0579 |
gMON | 24h / 0.05% | gMON/MON | 0xbFc4Fc9376a0DA7929475379EB37DFCb9C553B9c |
XAUt0 | 1h / 0.05% | XAU/USD | 0x61dD33A34E47a181EE02e42eE0546a3DA808f1B4 |
| Ratio | Contract |
|---|---|
| sMON/MON | 0x056d0eF95A4e046D028b00E6eC00bB4A8b1eBb96 |
| shMON/MON | 0x54a1020D118B9BeF3F3A4ec8E24AeEc9DFdBe4c3 |
| gMON/MON | 0xf97dfEd6Aa4cc387aBC5d47F0062A91CB4E4A755 |
| earnAUSD/AUSD | 0x66608681545aaa50D9ebdBd9542fEeA4e49B85da |
Governance Price Source
One reserve is not priced by a market feed. `loAZND` is in wind-down: the reserve is **frozen**, its collateral parameters have been reduced to the protocol floor, and its price is published by a governance-controlled feed while positions are unwound.
| Asset | Trigger | Source | Contract |
|---|---|---|---|
loAZND | Governance | GovernedPriceOracle | 0x9eF202F1A9962138a5918721Aa36b4665634975F |
Upgradables Administration
| ProxyAdmin | Address |
|---|---|
| Core Tokenomics | 0x6400650cED1eD7179143D40b4431c3cC8c068D90 |
| Leaderboard | 0x400916532d9298acfFD49B826258738115CF23f1 |
| Wrapped Tokens | 0x0cBe49645BCC84eD90A6aA4D93dfEb2Cc836F721 |
Usage Notes
Always interact with **Proxy** addresses in wallets or scripts.\ For read-only data (APYs, reserves, etc.), query **UiPoolDataProviderV3** and **NeverlandUiProvider**.\ The contracts listed on this page are verified on Monad mainnet explorers. Those behind a transparent proxy are upgradeable through their **ProxyAdmin**; the rest are immutable once deployed.\ Contract events are indexed under the “Neverland” market namespace for easy traceability.
# FAQ
## General
[**Website**](https://neverland.money/)
#### [App](https://app.neverland.money/)
#### 
[**Follow us on 𝕏**](https://x.com/neverland_money)
#### 
[**Discord Community**](https://discord.gg/neverland)
#### 
[**Telegram Announcements**](https://t.me/neverland_money)
#### 
[Medium Newsletter](https://news.neverland.money/)
#### 
[Github](https://github.com/Neverland-Money)