Security
Audits
Audits
Monitoring
MonitoringMonitoring 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
OperationsSafe 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.
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
TimelocksAll 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:
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
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: The Governance Safe multisig submits a transaction.
Wait: The operation enters the
Waitingstate for at least the timelock's delay.Execute: After the delay elapses, the Governance Safe submits the execution.
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:
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
Risk parameter administration: RISK_ADMIN on ACLManager
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
PostureInternal 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.
Last updated

