Security

Audits

Auditor	Scope	URL	Date
OpenZeppelin	Lending System	PDF	2021-11-01
Trail of Bits	Lending System	PDF	2022-01-07
PeckShield	Lending System	PDF	2022-01-10
ABDK	Lending System	PDF	2022-01-26
PeckShield	Lending System	PDF	2022-12-22
Sigma Prime	Lending System	PDF	2022-12-26
Sigma Prime	Lending System	PDF	2023-04-01
Composable Security	Tokenomics & Revenue	PDF	2025-08-22
Composable Security	Tokenomics & Revenue	PDF	2025-10-10
Octane	Oracle Adapters & Aggregators	PDF	2026-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

Monitoring is not limited to isolated contract events.

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	0xe72df2DDE84880DD706C5976E92ed34BB586A38F	EMERGENCY_ADMIN of Neverland's Lending Pool
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

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:

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)

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

There is no external admin that can reconfigure the timelocks instantly

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

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:

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

RiskTimelock (1-hour delay)

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

Security is treated as an ongoing process.

Every transaction, role change, and parameter update is observed, verified, and accountable.