Update platform docs for Explorer release

assertions-book/previous-hacks/drift-security-council-takeover.mdx

@@ -0,0 +1,99 @@
+---
+title: Drift Admin Takeover
+description: Reported Drift administrative takeover and assertion patterns for constraining high-impact governance actions
+---
+
+This case study explains how a reported administrative takeover can lead to rapid value loss and which assertion patterns could constrain comparable high-impact actions in an EVM protocol.
+
+## What Happened
+
+In April 2026, Drift Protocol reported an active attack and suspended deposits and withdrawals. The Record reported that security firms estimated losses above USD 285 million, while other estimates were at least USD 130 million. TechRadar later summarized Drift's public explanation as a sophisticated attack involving durable nonces, misrepresented transaction approvals, and rapid takeover of Drift's Security Council administrative powers.
+
+Sources:
+- [The Record report on the Drift security incident](https://therecord.media/drift-crypto-heist-solana-hacker)
+- [TechRadar report on the Drift incident](https://www.techradar.com/pro/security/this-is-not-an-april-fools-joke-crypto-platform-drift-suspends-services-after-millions-stolen)
+
+<Note>
+Drift is not an EVM protocol. This page uses the incident as an operational-risk case study for comparable EVM systems with emergency councils, admin multisigs, governance executors, or fast-path roles.
+</Note>
+
+## Why It Worked
+
+The public reporting describes an attack on the administrative execution layer rather than a conventional smart-contract bug. The relevant risk pattern is that trusted signers or emergency-governance machinery can be induced to execute actions that are valid at the signature layer but unsafe for the protocol.
+
+For an EVM protocol, comparable high-impact actions include:
+
+- changing owners or role memberships,
+- lowering multisig thresholds,
+- upgrading implementation contracts,
+- minting or moving protocol assets,
+- pausing or unpausing critical systems,
+- changing risk parameters,
+- disabling safety checks or circuit breakers.
+
+## The Invariant
+
+The protocol should never enter a state where emergency or admin authority can be rapidly repointed, weakened, or used to move large value without satisfying the protocol's own governance policy.
+
+This can be expressed as several enforceable properties:
+
+- approved role graph remains intact,
+- signer threshold stays above a minimum,
+- new owners or role holders are on an allowlist or pass a timelock,
+- high-impact functions can only be called through approved governance routes,
+- protocol outflows stay within configured limits even when an admin action is validly signed.
+
+## Assertion Patterns
+
+### Admin Role-Graph Assertion
+
+An assertion can inspect role, owner, and threshold changes in the transaction and reject unsafe transitions.
+
+Useful checks include:
+
+- threshold cannot be reduced below the approved minimum,
+- emergency council members cannot be replaced outside an approved set,
+- admin roles cannot be granted to new addresses without a timelock,
+- ownership cannot move to an unrecognized executor.
+
+### High-Impact Action Allowlist
+
+An assertion can watch sensitive function selectors and require that they are called only through approved governance paths.
+
+Useful surfaces include:
+
+- `upgradeTo` or proxy implementation changes,
+- `grantRole`, `revokeRole`, and ownership changes,
+- minting functions,
+- treasury transfers,
+- risk-parameter changes,
+- emergency pause or unpause operations.
+
+### Outflow Circuit Breaker
+
+Even if an attacker reaches an admin role or function, an outflow circuit breaker can prevent rapid value extraction.
+
+Useful checks include:
+
+- maximum protocol asset outflow per transaction,
+- maximum outflow per rolling window,
+- tighter limits after admin-role changes,
+- separate limits for treasury, vault, and user collateral assets.
+
+## How Assertions Would Constrain It
+
+For an EVM protocol with comparable emergency-admin powers, assertions could block the unsafe transaction before it settles if the transaction:
+
+1. weakens the signer threshold,
+2. adds an unapproved admin,
+3. combines an admin change with large asset movement,
+4. calls a high-impact function outside the approved route, or
+5. moves value beyond the protocol's configured outflow limit.
+
+The key point is that the signature can be valid while the state transition is still unsafe. Runtime assertions give protocols a way to define that boundary.
+
+## Key Takeaways
+
+Operational security failures should not automatically become total protocol failures. Admin wallets, emergency councils, and governance executors are powerful because they are supposed to respond quickly, but that same power needs explicit runtime limits.
+
+Assertions can enforce the protocol's intended governance shape: who can hold authority, how much authority can change at once, and how much value can move when authority changes.

assertions-book/previous-hacks/kelpdao-rseth-layerzero-configuration.mdx

@@ -0,0 +1,82 @@
+---
+title: KelpDAO / rsETH LayerZero Configuration Incident
+description: Reported cross-chain verification failure affecting KelpDAO rsETH and assertion patterns that could constrain similar inflow risk
+---
+
+This case study explains how a reported cross-chain verification failure could create unsafe asset inflows and which assertion patterns could constrain the resulting state transition.
+
+## What Happened
+
+In April 2026, TechRadar reported that Lazarus Group stole roughly $290 million from KelpDAO through its LayerZero integration. The report described attackers compromising infrastructure used to verify cross-chain transactions and feeding false data that caused fraudulent transfers to be approved.
+
+The same report said LayerZero characterized the incident as isolated to KelpDAO's rsETH configuration and attributed it to a single-DVN setup. KelpDAO disputed that the incident was solely the result of its configuration.
+
+Sources:
+- [TechRadar report on the KelpDAO / LayerZero incident](https://www.techradar.com/pro/security/north-koreas-lazarus-makes-off-with-usd290m-crypto-in-kelp-dao-heist-after-siphoning-funds-using-fraudulent-transactions)
+
+<Warning>
+The public root-cause record is disputed. This page focuses on the observable risk class: a cross-chain configuration or verification failure can create unsafe inflows into protocols that depend on the asset, even when those downstream protocols did not make the configuration change themselves.
+</Warning>
+
+## Why It Matters
+
+Cross-chain assets can become dependencies for lending markets, vaults, and other protocols. If an upstream bridge, messaging layer, or token issuer accepts invalid messages, the downstream protocol may see apparently valid token balances or inflows even though the underlying backing assumptions have changed.
+
+The dangerous state is not only "a bridge was compromised." For a dependent protocol, the dangerous state is:
+
+- a supported asset's supply increases faster than expected,
+- the asset's backing no longer matches protocol assumptions,
+- a market accepts deposits from a newly unsafe origin, or
+- risk exposure grows before the protocol team can update parameters.
+
+## Assertion Patterns
+
+### Cross-Chain Inflow Circuit Breaker
+
+An inflow circuit breaker can limit how much of a bridged or restaked asset enters a protected protocol over a rolling window.
+
+Useful checks include:
+
+- maximum inflow per block, hour, or day,
+- maximum inflow from a specific bridge, origin chain, or endpoint,
+- maximum increase in a market's exposure to the asset,
+- stricter limits when the asset is newly listed or recently reconfigured.
+
+This would not need to prove exactly which cross-chain message was invalid. It would constrain the downstream impact by preventing unusually large inflows from being accepted all at once.
+
+### Backing and Supply Parity Assertion
+
+For assets whose safety depends on backing, the protocol can assert that minted or accepted supply remains within a tolerated range of verified backing data.
+
+Useful checks include:
+
+- total accepted supply does not exceed verified backing plus a tolerance,
+- bridge-minted supply on a destination chain does not jump without matching source-side accounting,
+- lending-market collateral value is capped when backing data is stale or inconsistent.
+
+### Message-Security Configuration Assertion
+
+If the protocol relies on a cross-chain asset or endpoint with configurable verification policy, an assertion can watch configuration surfaces.
+
+Useful checks include:
+
+- verifier or DVN sets remain in an approved configuration,
+- quorum or threshold values do not drop below a safe minimum,
+- endpoint changes pass through expected governance or timelock paths,
+- high-risk configuration changes trigger lower asset-flow caps until reviewed.
+
+## How Assertions Would Constrain It
+
+For an EVM protocol accepting an asset like rsETH as collateral or vault input, the assertions would not need to understand every LayerZero or KelpDAO internal detail. They would enforce local safety boundaries:
+
+1. The protected market cannot accept more than a configured amount of the asset over a rolling window.
+2. The market cannot grow exposure if asset backing or message-security data is stale, disputed, or outside policy.
+3. The protocol cannot silently continue with the same risk parameters after a critical upstream configuration changes.
+
+The core idea is to turn external dependency risk into enforceable local limits.
+
+## Key Takeaways
+
+The incident shows why protocols need protections around assets and dependencies they do not fully control. A lending market, vault, or structured product can be harmed by decisions made upstream by a bridge, restaking protocol, verifier set, or token issuer.
+
+Runtime assertions are useful because they can enforce the downstream protocol's own risk boundaries even when the external root cause is complex or disputed.

assertions-book/previous-hacks/prev-hacks-index.mdx

@@ -10,7 +10,23 @@ These pages analyze real-world hacks and demonstrate how assertions could have p
 Each analysis includes:
 - Detailed explanation of the attack mechanism
 - Root cause analysis of the vulnerability
-- Specific assertion code that would have prevented the exploit
+- Specific assertion patterns, and code examples where they have been implemented and tested
+
+## Cross-Chain, Runtime, and Operational Risk
+
+Recent incidents show that protocol risk often comes from external dependencies, bridge configuration, operational controls, and asset-flow assumptions rather than only from a bug in the protected contract itself. Runtime assertions are useful in these cases because they can enforce outcome-based limits around what state should never be reached.
+
+### [KelpDAO / rsETH LayerZero Configuration Incident](/assertions-book/previous-hacks/kelpdao-rseth-layerzero-configuration)
+**Attack Type:** Cross-chain Configuration + Message Verification Failure
+**Loss:** Reported $290M USD
+**Root Cause:** Reported compromise or misuse of cross-chain verification infrastructure, with public dispute over whether KelpDAO's rsETH LayerZero configuration was the direct cause
+**Prevention:** Cross-chain inflow circuit breakers, backing/supply parity assertions, and message-security configuration assertions
+
+### [Drift Admin Takeover](/assertions-book/previous-hacks/drift-security-council-takeover)
+**Attack Type:** Operational Security + Administrative Takeover
+**Loss:** Reported $280M+ USD
+**Root Cause:** Reported misrepresented approvals and durable nonce abuse enabled takeover of emergency administrative powers
+**Prevention:** Admin role-graph assertions, high-impact action allowlists, and protocol outflow circuit breakers
 
 ## Access Control & Administrative Vulnerabilities
 

credible/architecture-overview.mdx

@@ -129,17 +129,17 @@ flowchart LR
 The Assertion Enforcer is integrated with the block builder. During block production, the block builder invokes the Assertion Enforcer to validate transactions before including them.
 </Note>
 
-## Incident Lifecycle (Public View)
+## Invalidation Lifecycle (Public View)
 
-When an assertion is violated, the incident is recorded and exposed for transparency and alerts.
+When an assertion is violated, the invalidation is recorded and exposed for transparency and alerts.
 
 ```mermaid
 ---
-title: Incident Lifecycle
+title: Invalidation Lifecycle
 ---
 flowchart LR
     ENFORCER["Assertion Enforcer"] --> PLATFORM["Phylax Platform"]
-    PLATFORM --> DASH["Transparency Dashboard"]
+    PLATFORM --> DASH["The Phylax Explorer"]
     PLATFORM --> ALERTS["Slack/PagerDuty Alerts"]
 
     classDef enforcer fill:#7b1fa2,stroke:#4a148c,stroke-width:2px,color:#fff

credible/assertion-enforcer.mdx

@@ -15,6 +15,8 @@ The Assertion Enforcer operates inside the block production pipeline:
 4. Returns validation results to the network
 5. The network integration applies its inclusion policy to those results
 
+Depending on the network integration, validation can run synchronously before inclusion or through a bounded optimistic path where the builder checkpoints execution, runs assertions in parallel worker capacity, and rolls back if a transaction invalidates.
+
 ## Sidecar Architecture
 
 As a [sidecar](/credible/glossary#sidecar), the Assertion Enforcer:
@@ -102,21 +104,39 @@ The Assertion Enforcer integrates with block builders so that the network can ap
 - The network integration determines how those results affect inclusion
 - Block production continues normally with validated transactions
 
+### Invalidation Handling
+
+When an assertion invalidates a candidate transaction, the integration applies the network's documented inclusion policy. In the usual production path, the invalid transaction is excluded before settlement and the platform records an invalidation.
+
+Some integrations may use optimistic execution to keep assertion work out of the serial block-building path. In that model, the builder creates a rollback checkpoint before speculative execution. If a transaction invalidates, the builder rolls back to the checkpoint before that transaction, excludes the invalid transaction, and replays later transactions within the configured speculative window.
+
+Rollback and replay cost must be bounded by policy. Integrations should define the speculative window, publication boundary, timeout behavior, and what happens when assertion workers fall behind.
+
 ## Performance Model
 
-The Assertion Enforcer is designed to keep the synchronous block-building path small. In the common case, the block builder pays for routing work such as metadata collection, assertion selection, checkpoint creation, and work submission. Assertion execution itself can run separately from that serial path, depending on the network integration.
+The Assertion Enforcer is designed to keep the synchronous block-building path small. In the common case, the block builder pays for routing work such as metadata collection, assertion selection, checkpoint creation, and work submission. Assertion execution itself can run separately from that serial path, depending on the integration.
+
+The hot path should stay limited to the work required to route, schedule, and account for assertion execution:
+
+- collect the trace or metadata needed for assertion routing
+- select relevant assertions from the registry snapshot
+- create rollback checkpoints where the integration uses optimistic execution
+- submit bounded work to assertion workers
+- apply the validation result before the publication boundary
 
-The important performance constraint is keeping assertion work bounded and predictable for the transaction workload. Network integrations use bounded queues, publication policies, fine-grained triggers, deterministic gas or runtime limits, and bounded execution surfaces to keep validation predictable.
+The important performance constraint is keeping assertion work bounded and predictable for the transaction workload. Integrations use bounded queues, publication policies, fine-grained triggers, deterministic gas or runtime limits, and bounded execution surfaces to keep validation predictable.
 
 The enforcer also avoids network fetches on the transaction hot path. Assertion bytecode is fetched after deployment events and cached before validation.
 
+The primary performance risk is assertion tail latency. Production monitoring should track trigger rate, p95, p99, and maximum assertion execution time, invalidation behavior, worker backlog, and timeout rates.
+
 ## Production Admission and Resource Limits
 
 Production execution uses the active assertion set admitted through the configured registry and review process.
 
 Production assertion admission should account for:
 
-- Protected protocol surface and trigger conditions
+- Protected protocol areas and trigger conditions
 - Expected trigger frequency
 - Maximum gas or runtime budget
 - Expected read footprint
@@ -126,12 +146,27 @@ Production assertion admission should account for:
 
 These controls keep block-building resources predictable and help protocol teams understand which assertions are ready to promote from staging to production.
 
+## Resource Isolation and Griefing Controls
+
+Assertions should not automatically consume production block-building resources just because they were published. Production admission and resource limits protect the network from broad, expensive, or poorly scoped assertions.
+
+Common controls include:
+
+- Authorization or review before an assertion enters the production execution set
+- Trigger scoping so assertions run only for relevant contracts, selectors, or state changes
+- Runtime and read-footprint limits
+- Dedicated worker capacity for assertion execution
+- Timeout behavior with clear inclusion-policy consequences
+- Staging and backtesting requirements before production promotion
+
+Ingress filtering can also reduce repeated invalid submissions. When a transaction invalidates, the integration can record short-lived fingerprints for exact replays or repeated attempts against the same assertion and target contract or function. Broad fingerprints should use conservative TTLs and thresholds.
+
 ## Operational Expectations (Public)
 
 - **Non-invasive**: Runs alongside existing block builders without changing consensus rules
 - **Deterministic**: Given the same state, transaction, and assertion code, validation results are deterministic
 - **Staging support**: Networks can validate assertions before enforcing them in production
-- **Transparent outcomes**: Incidents are visible in the platform and dashboard
+- **Transparent outcomes**: Invalidations are visible in the platform and The Phylax Explorer
 
 ## Assertion Caching