Lagoon launched on Linea with a fundamental challenge: how do you secure tokenized private credit vaults where NAV updates happen off-chain, deposits can be instant or epoch-based, and users need institutional-grade protection without introducing centralized monitoring? They found the Credible Layer to be very helpful.
As one of the first RWA protocols to integrate the Credible Layer on Linea, Lagoon can now prevent entire categories of accounting manipulation and settlement attacks before transactions are ever sequenced.
Here's exactly how five assertions protect user funds across Lagoon’s dual-mode vault architecture. But first, a bit about Lagoon and the Credible Layer.
The Credible Layer
The Credible Layer introduces a new security primitive: assertions. Instead of trying to predict every possible attack, assertions define what states should never occur in a protocol and enable the rollup operator to prevent them before they're ever included in a block.
Core concept: Assertion: State → {true, false}
Assertions execute off-chain in a modified EVM (PhEVM) that's now part of Linea's sequencer and prevent transactions from being included in blocks if they would invalidate an assertion that a protocol defines.
Lagoon
Lagoon enables tokenized access to private credit by leveraging Lagoon Vault Infrastructure. The protocol operates in two distinct modes:
Synchronous Mode (v0.5.0): When NAV is fresh (within its lifespan, having not expired), users can deposit instantly and receive shares immediately at current pricing—critical for high-frequency DeFi integrations.
Asynchronous Mode: When NAV expires after the lifespan of the data, deposits enter an epoch-based settlement queue where the Safe invests capital into strategies (private credit, RWAs) before users claim shares.
Key Components:
- Lagoon Vault: Main contract managing deposits, redemptions, share pricing, and mode switching
- Silo: Immutable escrow holding pending deposits and redemptions during async settlement
- Safe: Multisig controlling asset deployment, NAV updates,
To secure this dual-mode architecture, where pricing happens off-chain and mode switches must be atomic, Phylax and Lagoon completed invariant mapping and implemented five assertions. Each assertion addresses a specific hacked state that could compromise user funds or vault integrity.
Five Security Assertions Deployed
1. Total Assets Accounting Integrity
Focus: The vault's totalAssets variable that represents Net Asset Value across all settlement operations and synchronous deposits.
What the assertion protects: Lagoon NAV is set by trusted valuation managers based on off-chain private credit performance. Attackers could exploit bugs in settlement logic to mint shares without corresponding asset increases, or burn shares without decreasing NAV. Asynchronous settlements spanning multiple blocks create windows where accounting inconsistencies could compound. Synchronous deposits need immediate accounting verification to prevent share dilution attacks.
How the assertion protects:
- Enforces that every operation modifying totalAssets produces the exact expected delta
- After deposit settlements, it confirms totalAssets increased by exactly pendingAssets.
- After redemption settlements, it validates totalAssets decreased by withdrawn amounts.
- For synchronous deposits, the assertion ensures totalAssets increases atomically with the deposited amount.
- Maintains solvency by verifying vault idle balance always covers all claimable redemptions, preventing the nightmare scenario where users hold shares but can't withdraw.
This assertion is currently under development.
2. Synchronous Deposit Mode Integrity
Focus: The mode-switching mechanism between instant deposits (sync) and epoch-based deposits (async), controlled by NAV expiration timestamps.
What the assertion protects: Mode confusion bugs could allow the wrong operations at the wrong times. Attackers could force sync deposits when NAV is stale, bypass epoch settlement queues, or get stuck in incorrect modes due to state transition errors.
How the assertion protects:
- Enforces strict mutual exclusivity: when isTotalAssetsValid() returns true, only syncDeposit() works, and requestDeposit() must revert.
- When NAV expires, the opposite holds—async mode activates and sync deposits block.
- Validates that sync deposits transfer assets directly to the Safe (not Silo) and mint shares immediately at the current rate without touching epoch systems.
- Prevents the valuation manager from updating NAV while sync mode is active, ensuring pricing stability during deposit windows. This is the most frequently checked assertion since it triggers on every deposit operation.
Explore the full assertion here.
3. Epoch Settlement Ordering and Claimability
Focus: The epoch-based settlement system that manages async deposit and redemption queues with strict odd/even sequencing.
What the assertion protects: Epoch ordering violations let users claim at incorrect conversion rates by timing their claims to exploit price movements. Attackers could double-claim by manipulating epoch boundaries or claim from unsettled epochs before NAV updates. Contract upgrades could introduce bugs that break epoch parity (deposits=odd, redeems=even), corrupting the entire settlement queue. Users could front-run settlements by requesting in one epoch and claiming before the next valuation.
How the assertion protects:
- Enforces that the current epoch always stays at least 2 ahead of the last settled epoch, maintaining the settlement buffer.
- Validates that deposit epochs remain odd and redeem epochs stay even across all operations. It blocks claims from epochs where requestId > lastEpochIdSettled.
- Verifies that once an epoch settles, its conversion rate locks forever—preventing retroactive price manipulation. Also, it critically checks that syncDeposit() never increments depositEpochId (only updateNewTotalAssets() does), keeping epoch and instant settlement systems isolated.
Explore the full assertion here.
4. Silo Balance Consistency
Focus: The immutable Silo contract that temporarily holds assets for pending deposits and shares for pending redemptions during async mode.
What the assertion protects: Silo accounting mismatches create direct thefts. Users could withdraw more assets than they deposited by exploiting balance calculation bugs. Shares held in Silo for redemptions could be claimed multiple times if the pending request tracking breaks. Settlement operations spanning multiple blocks create windows where Silo balances could drift from summed user requests. Synchronous deposits that bypass the Silo could accidentally route through it due to mode confusion, breaking accounting.
How the assertion protects:
- Validates Silo asset balance always meets or exceeds the sum of all pending deposit requests.
- Confirms Silo share balance covers all pending redemption requests. It uses event-based induction to track DepositRequest, DepositRequestCanceled, and RedeemRequest events, verifying balance changes match deltas without needing to enumerate all users.
- Allows Silo balances to exceed requests (airdrops/donations are OK), but never allows deficits. It verifies syncDeposit() never touches Silo balances—assets go directly to Safe, keeping sync and async flows completely isolated.
Explore the full assertion here.
5. NAV Validity and Expiration Lifecycle
Focus: The time-based NAV expiration system that controls mode switching via totalAssetsExpiration timestamps.
What the assertion protects: Mode switching is controlled by timestamp logic that could be exploited if expiration checks are inconsistent. Attackers could force sync deposits during expired NAV windows by front-running expiration transactions. The Safe could manipulate totalAssetsLifespan to create favorable windows for insider trading—setting long lifespans when NAV moves favorably. Valuation managers could update NAV while sync mode is active, changing prices during active deposits. Expiration logic bugs could trap the vault in one mode permanently.
How the assertion protects:
- Validates isTotalAssetsValid() consistently returns block.timestamp < totalAssetsExpiration across all checks.
- Confirms settlements properly reset expiration: totalAssetsExpiration = block.timestamp + totalAssetsLifespan.
- Enforces access control: updateNewTotalAssets() must revert when NAV is valid, forcing the Safe to call expireTotalAssets() first before any valuation update.
- Tracks TotalAssetsLifespanUpdated events to ensure the Safe can't silently manipulate timing windows. This prevents NAV updates during sync deposit windows and ensures mode switches happen atomically.
This assertion is currently under development.
The Integration
deployed three assertions that now prevent entire categories of accounting and settlement attacks from ever occurring. This is the power of preventing the hack directly instead of trying to find every hack vector before a hacker does. All thanks to Linea’s integration of the Credible Layer.
The integration occurred with zero downtime, no contract changes, and no redeployments. Assertions were simply deployed as smart contracts on Linea. They are then referenced directly by the Phylax sidecar in Linea's sequencer, meaning Lagoon's battle-tested code continues to run exactly as before while gaining new protection layers.
Being able to deploy assertions quickly and at no cost meant they could launch v0.5.0's synchronous deposit feature with institutional-grade security from day one. That means users can access an improved product with minimum delay.
All of Lagoon’s active assertions are publicly verifiable and transparent, as are all assertions on the Credible Layer. Anyone can inspect the rules protecting their funds, and institutional LPs can audit the security logic without trusting black-box systems. This openness builds investor confidence to bring more capital on-chain.