# Security ### Audits
AuditorScopeURLDate
OpenZeppelinLending SystemPDF2021-11-01
Trail of BitsLending SystemPDF2022-01-07
PeckShieldLending SystemPDF2022-01-10
ABDKLending SystemPDF2022-01-26
PeckShieldLending SystemPDF2022-12-22
Sigma PrimeLending SystemPDF2022-12-26
Sigma PrimeLending SystemPDF2023-04-01
Composable SecurityTokenomics & RevenuePDF2025-08-22
Composable SecurityTokenomics & RevenuePDF2025-10-10
OctaneOracle Adapters & AggregatorsPDF2026-02-17
### 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.
SafeAddressRole
Governance0x57976e192C45461F5958045a0bC57102e90440eDPROPOSER_ROLE, CANCELLER_ROLE, EXECUTOR_ROLE on GovernanceTimelock & RiskTimelock
Sentinel0xe72df2DDE84880DD706C5976E92ed34BB586A38FEMERGENCY_ADMIN of Neverland's Lending Pool
Revenue0x909b176220b7e782C0f3cEccaB4b19D2c433c6BBAuthorized distributor of RevenueReward and revenue receiver of fees and revenue
Treasury0xe72df2DDE84880DD706C5976E92ed34BB586A38FNeverland Reserves
GuardianTBAExternal party CANCELLER_ROLE of GovernanceTimelock & RiskTimelock
#### Real-Time Transactions Monitoring & Execution Validation All multisig activity and protocol level transactions are continuously monitored in real time.
On-chain detection Transactions are detected immediately upon submission\ Matched against the pre-announced operation
Human-readable validation Monitoring system broadcasts a clear breakdown of what the transaction does
Signature verification Signers re-verify the live transaction before execution signatures are completed\ Every signature is recorded and tracked against the expected signer set
Execution confirmation System confirms completion\ Publishes a final verification event with full context
#### Drift Detection & Cancellation If any transaction deviates from the expected verification flow at any stage, it is treated as compromised. **Triggers include** 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:
TimelockMinimum DelayScope
GovernanceTimelock24HLending governance (pool admin, ACL admin), proxy upgrades for tokenomics, revenue, leaderboard, and nToken wrappers
RiskTimelock1HRisk parameter changes (supply/borrow caps, reserve configurations, interest rate updates)
The two timelocks are deployed at separate addresses and can never collapse into a single contract. This separation ensures that routine risk tuning does not require the same delay as structural governance changes, while still preventing instant parameter manipulation. #### Immutable Delay Floors Each timelock is deployed with a hardcoded `MIN_DELAY_FLOOR` embedded directly in the contract bytecode as an `immutable` value. This floor cannot be changed, upgraded, or bypassed by any governance action; it is fixed at deployment and persists for the lifetime of the contract. **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 %}
RoleHolderCapability
DEFAULT_ADMIN_ROLETimelock itselfGrant/revoke timelock roles
PROPOSER_ROLEGovernance Safe (multisig)Schedule new operations
EXECUTOR_ROLEGovernance Safe (multisig)Execute operations after the delay
CANCELLER_ROLEGovernance Safe (multisig)Cancel pending operations
#### Operation Lifecycle Every timelocked action follows the same onchain lifecycle: ``` schedule → [delay] → execute ↓ cancel ``` 1. **Schedule**: The **Governance Safe** multisig submits a transaction. 2. **Wait:** The operation enters the `Waiting` state for at least the timelock's delay. 3. **Execute:** After the delay elapses, the **Governance Safe** submits the execution. 4. **Cancel:** At any point before execution, the Governance Safe can cancel a pending operation. Once executed, an operation is permanently `Done` and cannot be reversed through the timelock itself. #### What the Timelocks Protect The following surfaces are exclusively controlled through timelocks: {% tabs %} {% tab title="GovernanceTimelock (24-hour delay)" %} Lending pool administration: `POOL_ADMIN`, `DEFAULT_ADMIN` on `ACLManager` **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 [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 %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.neverland.money/security.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.