diff --git a/assertions-book/previous-hacks/drift-security-council-takeover.mdx b/assertions-book/previous-hacks/drift-security-council-takeover.mdx
new file mode 100644
index 0000000..ef977ef
--- /dev/null
+++ b/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)
+
+
+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.
+
+
+## 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.
diff --git a/assertions-book/previous-hacks/kelpdao-rseth-layerzero-configuration.mdx b/assertions-book/previous-hacks/kelpdao-rseth-layerzero-configuration.mdx
new file mode 100644
index 0000000..ae3f412
--- /dev/null
+++ b/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)
+
+
+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.
+
+
+## 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.
diff --git a/assertions-book/previous-hacks/prev-hacks-index.mdx b/assertions-book/previous-hacks/prev-hacks-index.mdx
index 7d05716..6ceb87e 100644
--- a/assertions-book/previous-hacks/prev-hacks-index.mdx
+++ b/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
diff --git a/credible/architecture-overview.mdx b/credible/architecture-overview.mdx
index 655d886..fc2db4e 100644
--- a/credible/architecture-overview.mdx
+++ b/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.
-## 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
diff --git a/credible/assertion-enforcer.mdx b/credible/assertion-enforcer.mdx
index 596eb0f..b16bb8a 100644
--- a/credible/assertion-enforcer.mdx
+++ b/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
diff --git a/credible/cheatcodes-reference.mdx b/credible/cheatcodes-reference.mdx
index db2acf0..18dae43 100644
--- a/credible/cheatcodes-reference.mdx
+++ b/credible/cheatcodes-reference.mdx
@@ -11,7 +11,7 @@ This reference lists the Credible Layer cheatcodes exposed through `credible-std
Cheatcodes are grouped by API status:
-- **Legacy precompiles**: launch-era APIs that remain part of the legacy assertion surface.
+- **Legacy precompiles**: existing precompiles from before the Reshiram update. They remain available for legacy assertions.
- **Reshiram precompiles**: newer APIs based on explicit `ForkId` snapshot reads, call context, richer log and call inspection, and protection-suite helpers.
- **Deprecated cheatcodes**: legacy fork-switching APIs. Do not use them in new assertions.
@@ -33,8 +33,8 @@ enum AssertionSpec {
| Spec | Availability |
| --- | --- |
-| `Legacy` | Standard launch precompile set. Reshiram-only precompiles are unavailable. |
-| `Reshiram` | Reshiram precompiles plus the non-deprecated shared surface. Legacy-only fork-switching selectors are unavailable. |
+| `Legacy` | Standard pre-Reshiram precompile set. Reshiram-only precompiles are unavailable. |
+| `Reshiram` | Reshiram precompiles plus the non-deprecated shared APIs. Legacy-only fork-switching selectors are unavailable. |
| `Experimental` | Unrestricted access to all available precompiles. May include untested or dangerous behavior. |
Register the spec in the assertion constructor:
@@ -121,7 +121,7 @@ Use `id` with call-scoped APIs such as `PhEvm.ForkId({forkType: 2, callIndex: id
## Legacy Precompiles
-Legacy precompiles are the standard launch-era cheatcodes. Some are still useful, but prefer the Reshiram equivalents when you need explicit snapshot selection or call-scoped behavior.
+Legacy precompiles are the standard cheatcodes from before the Reshiram update. Some are still useful, but prefer the Reshiram equivalents when you need explicit snapshot selection or call-scoped behavior.
### `getLogs`
diff --git a/credible/credible-introduction.mdx b/credible/credible-introduction.mdx
index e72ae88..cb650c1 100644
--- a/credible/credible-introduction.mdx
+++ b/credible/credible-introduction.mdx
@@ -53,7 +53,7 @@ Use this page to choose the right kind of documentation for what you need next:
- See the adoption path for writing assertions, deploying them, and monitoring incidents.
+ See the adoption path for writing assertions, deploying them, and monitoring invalidations.
See the high-level integration path for enforcement during block building.
@@ -61,8 +61,8 @@ Use this page to choose the right kind of documentation for what you need next:
Browse pattern catalogs and exploit case studies in the Assertions Book.
-
- Inspect deployed assertions, incidents, and public protocol coverage.
+
+ Inspect deployed assertions, invalidations, and public protocol coverage.
@@ -71,6 +71,7 @@ Use this page to choose the right kind of documentation for what you need next:
- **Pre-execution prevention** — Exploits are blocked before they execute, not detected after
- **No contract changes** — Add protection to any contract, including immutable ones
- **Transparent & verifiable** — All rules are public Solidity, auditable by anyone
+- **Readable security posture** — Understand circuit breakers and verifiable operational risks through clear, plain-English breakdowns
- **No external execution services** — Enforcement runs within the network’s block-building flow
- **Deterministic decisions** — Binary enforcement based on your rules, not opaque scoring
diff --git a/credible/credible-layer-overview.mdx b/credible/credible-layer-overview.mdx
index 3adcf14..406e7eb 100644
--- a/credible/credible-layer-overview.mdx
+++ b/credible/credible-layer-overview.mdx
@@ -26,7 +26,7 @@ At a glance:
- Written in Solidity with familiar Forge patterns
- No contract modifications or downtime required
- Works with immutable contracts
-- All rules are publicly verifiable on the [transparency dashboard](/credible/glossary#transparency-dashboard)
+- All rules are publicly reviewable in [The Phylax Explorer](/credible/glossary#the-phylax-explorer)
- [Implementation effort](/credible/development-effort) is comparable to writing Forge invariant tests
diff --git a/credible/credible-std-overview.mdx b/credible/credible-std-overview.mdx
index bd0ac61..3bcbdb9 100644
--- a/credible/credible-std-overview.mdx
+++ b/credible/credible-std-overview.mdx
@@ -54,7 +54,7 @@ test = "test"
### Legacy Trigger Helpers
-Use these helpers for the launch-era trigger surface:
+Use these helpers for the pre-Reshiram trigger APIs:
```solidity
function registerCallTrigger(bytes4 fnSelector) internal view;
diff --git a/credible/dapp-explorer.mdx b/credible/dapp-explorer.mdx
new file mode 100644
index 0000000..4c9789c
--- /dev/null
+++ b/credible/dapp-explorer.mdx
@@ -0,0 +1,95 @@
+---
+title: 'The Phylax Explorer'
+description: 'Browse public protocol protection posture, evidence, and invalidation data'
+---
+
+**[The Phylax Explorer](/credible/dapp-explorer)** is the public dashboard for projects that have opted into runtime enforcement. It shows what a protocol has protected, which evidence the team has added, and what invalidation information is public.
+
+The Phylax Explorer can show:
+
+- Projects and protected contracts
+- Active assertion posture
+- Summaries of protected actions, assertion behavior, circuit breakers, failure modes, and assertion triggers
+- Operational risk properties where verifiable
+- Deployed-vs-audited code context where available
+- GitHub, audit, and formal verification links
+- Aggregate invalidation history, such as a reference ID and timestamp
+
+
+
+
+
+
+For a high-level view of how the platform interfaces with the rest of the system, see
+[Interface Overview](/credible/interfaces-overview).
+
+
+### Search / Filter
+
+- You can search for projects at any time using the project search field or by hitting `cmd/ctrl + k`
+- You can filter projects by network
+
+## Security Posture Evidence
+
+The Phylax Explorer is designed to help users inspect protocol security information without reducing it to a score.
+
+The Phylax Explorer can show the protections that are active for each public project, the contracts they apply to, the actions they check, and the unsafe conditions they are meant to prevent. Where supporting evidence is available, The Phylax Explorer can also show admin and upgrade information, audit links, and deployed-vs-audited code context.
+
+Use this view to answer questions such as:
+
+- Which contracts are protected?
+- Which assertions are active?
+- What actions cause each assertion to run?
+- What failure modes are the assertions designed to block?
+- Who appears to control upgrades or sensitive operations?
+- Does the deployed code appear to match known audited code?
+
+For more detail, see [Security Posture in The Phylax Explorer](/credible/explorer-security-posture).
+
+## Accessing The Phylax Explorer
+
+1. Click the "Explorer" tab in the navigation bar
+2. Browse projects
+
+## Use Cases
+
+**For Allocators and Risk Teams**
+- Review which controls a protocol has listed publicly
+- Compare protected contracts, active assertions, upgrade information, audit context, and evidence across protocols
+
+**For Users and Security Researchers**
+- Verify which assertions protect a protocol before interacting
+- Review public evidence and invalidation metadata when available
+
+**For Protocol Teams**
+- Show users, partners, and investors what protections are active
+- Explain assertion coverage without requiring every reviewer to read source code first
+- Keep project metadata, audit links, and repository context current
+
+**For Developers**
+- Browse assertions from protocols with similar contracts
+- Learn from existing assertion implementations
+- Copy and adapt assertion patterns for your own protocol
+
+## Why Users Trust Protected Protocols
+
+- **Public registry**: Assertions and protected contracts are visible on-chain
+- **Transparent enforcement**: Dropped transactions appear as limited public invalidation records and detailed private project invalidations
+- **Auditable rules**: Assertions are published Solidity, not opaque policy
+
+## Next Steps
+
+
+
+ Learn more about the platform
+
+
+ Create your own project
+
+
+ Learn more about invalidations
+
+
+ Learn how to write assertions
+
+
diff --git a/credible/dapp-incidents.mdx b/credible/dapp-incidents.mdx
deleted file mode 100644
index 7fe411f..0000000
--- a/credible/dapp-incidents.mdx
+++ /dev/null
@@ -1,148 +0,0 @@
----
-title: 'Incidents'
-description: 'View incidents prevented by the Credible Layer'
----
-
-Incidents group invalidating transactions: transactions that violated assertions protecting contracts. In production, the [Enforcer](/credible/glossary#assertion-enforcer) drops those transactions before settlement. In staging, the platform records that the transaction would have been dropped, but the transaction still lands on the live network because staging is observe-only.
-
-
-For the end-to-end flow, see the incident lifecycle diagram in
-[Architecture Overview](/credible/architecture-overview#incident-lifecycle-public-view).
-
-
-## How Incidents Are Grouped
-
-An incident represents the invalidation of an assertion over a one-hour time period. Multiple invalidating transactions can belong to the same incident if they violate the same assertion within that window.
-
-**Why group transactions into incidents?**
-
-- An attacker may craft multiple transactions that all violate the same assertion—these represent the same logical attack
-- One hour is a reasonable estimate for how long an attack attempt might last
-- After one hour without violations, a new invalidation likely indicates a different attack and creates a new incident
-
-This grouping ensures you receive meaningful alerts without being spammed by repeated notifications for the same security event.
-
-
-This is our initial approach to incident grouping and may be refined based on user feedback.
-
-
-## Project Incidents (Manager View)
-
-Project incidents are visible only to the project manager and live inside the project dashboard.
-
-Non-owners see project events, not incidents.
-
-### Access and Navigation
-
-- Open a project and select the **Incidents** tab.
-- Route: `/projects/{project_id}/incidents`
-
-
-
-
-
-
-### Incidents
-
-The incidents list shows recent incidents for the project, ordered by most recent.
-
-Each row includes:
-
-- **Timestamp**
-- **Contract Affected**
-- **Assertion Triggered**
-- **Invalid Transactions** count
-- **Environment** (staging or production)
-
-Click a row to open the incident detail view.
-
-
-
-
-
-### Incident Detail and Invalidating Transactions
-
-The incident detail page summarizes the incident and lists invalidating transactions.
-It includes:
-
-- **Incident detail card** with date, contract affected, assertion triggered, assertion group, invalid transaction count, and environment
-- **Critical warning banner** if any invalidating transaction landed on-chain
-- **Invalid Transactions** list with expandable rows and action buttons
-
-Each invalidating transaction includes:
-
-- Transaction hash, to/from, value, calldata, and block number (if available)
-- **Open Debug View** to inspect the trace
-- **Copy Data as JSON** to export the transaction
-
-
-
-
-
-### Debug Trace View
-
-The debug trace view opens from an invalidating transaction.
-
-- Route: `/projects/{project_id}/trace/{incident_id}/{transaction_id}`
-- **Transaction Attributes** panel with copy-all action
-- **Execution Context** panel (block environment + previous transactions)
-- **Transaction Trace** panel with status: pending, in progress, completed, failed, or skipped
-
-
-
-
-
-
-
-
-
-### Real-Time Updates and Alerts
-
-When a project manager is viewing the incidents list, new incidents stream into the list in real time.
-You can also set up external alerts via webhooks:
-
-- **Slack Integration**: Configure Slack webhooks to receive incident notifications
-- **PagerDuty Integration**: Configure PagerDuty webhooks to receive incident notifications
-
-See [Integrations](/credible/dapp-integrations) for setup instructions.
-
-## Public Transparency Incidents
-
-The public explorer includes a limited invalidations view for transparency. Detailed transaction payloads, traces, and project-specific incident evidence are only available to project managers and collaborators with access.
-
-Detailed invalidation evidence is scoped to the project team so they can triage with full payloads and traces while public views remain concise.
-
-### Staging vs. Production
-
-| Environment | What an invalidation means | User impact |
-| --- | --- | --- |
-| Staging | The transaction would have violated an assertion under production enforcement | The transaction is recorded for review but is not dropped |
-| Production | The transaction violated an enforced assertion | The transaction is dropped before settlement |
-
-## Use Cases
-
-- Monitor when assertions prevent violations for your projects
-- Review attempted invalid transactions targeting your protocol
-- Tune assertions based on staging invalidations before production promotion
-- Add or refine assertions based on incident data
-
-
-Incident viewing is read-only. You cannot modify or delete incident records.
-
-
-## Next Steps
-
-
-
- Learn more about the platform
-
-
- Browse projects and assertions
-
-
- Learn how to write effective assertions
-
-
- Understand how assertion validation works
-
-
diff --git a/credible/dapp-integration.mdx b/credible/dapp-integration.mdx
index 95393f6..bfc94a2 100644
--- a/credible/dapp-integration.mdx
+++ b/credible/dapp-integration.mdx
@@ -12,7 +12,7 @@ If you are ready to execute deployment, use [Deploy Assertions with the Platform
Use it before deployment to identify the contracts, assertions, admins, and environments involved in the rollout.
-Project creation and assertion deployment require authorization for the target contracts. Depending on the contract and network, authorization can happen through an on-chain admin verifier such as `owner()` or through [manual verification](/credible/manual-verification).
+Project creation and assertion deployment require authorization for the target contracts. Depending on the contract and network, authorization can happen through an on-chain admin verifier such as `owner()` or, for rollup contracts only, through [manual verification](/credible/manual-verification).
## Adoption Workflow
@@ -21,7 +21,7 @@ Teams follow the same underlying steps. The CLI is used to author and deploy ass
is used to manage deployments and monitoring.
- **CLI authoring**: write assertions locally and create a release with `pcl apply`
-- **Platform management**: link contracts, stage or deploy, and monitor incidents
+- **Platform management**: link contracts, stage or deploy, and monitor invalidations
## End-to-End Flow
@@ -36,14 +36,14 @@ flowchart LR
Platform --> Registry[On-Chain Registry]
Registry --> Enforcer[Assertion Enforcer]
Enforcer --> Outcome[Block Inclusion Decision]
- Outcome --> Incidents[Incidents + Dashboard]
+ Outcome --> Invalidations[Invalidations + The Phylax Explorer]
```
## What You Control
- Which assertions protect which contracts
- Staging vs production deployments
-- Incident notification routing and monitoring
+- Invalidation notification routing and monitoring
## Coverage Planning
@@ -60,7 +60,7 @@ This map helps the protocol team decide which assertions belong in the first rel
## Authorization Requirements
-Before assertions can be deployed for a contract, the platform needs to determine which protocol admin can manage that contract's assertion lifecycle. The common path is owner-based verification. If your contracts do not expose a supported ownership interface, use [How to Request Manual Verification](/credible/manual-verification) to understand the fallback process.
+Before assertions can be deployed for a contract, the platform needs to determine which protocol admin can manage that contract's assertion lifecycle. The common path is owner-based verification. If your rollup contracts do not expose a supported ownership interface, use [How to Request Manual Verification](/credible/manual-verification) to understand the fallback process. Manual verification is not available for Ethereum mainnet contracts.
## Deployment Modes
@@ -72,14 +72,14 @@ Learn more about ownership checks in [Ownership Verification](/credible/ownershi
## What Users Can Verify
- Which assertions are active for a protocol
-- On-chain registry entries and transparency views
-- Incident history for protected contracts
+- On-chain registry entries and views in The Phylax Explorer
+- Invalidation history for protected contracts
## What Successful Rollout Looks Like
- Assertions cover critical protocol invariants and admin operations
- Staging assertions are validated before moving to production
-- Teams review incidents and iterate on coverage over time
+- Teams review invalidations and iterate on coverage over time
## Next Steps
diff --git a/credible/dapp-integrations.mdx b/credible/dapp-integrations.mdx
index 032364a..8ae2c56 100644
--- a/credible/dapp-integrations.mdx
+++ b/credible/dapp-integrations.mdx
@@ -1,9 +1,9 @@
---
-title: 'Incident Notifications'
-description: 'Configure Slack and PagerDuty to receive real-time incident notifications'
+title: 'Invalidation Notifications'
+description: 'Configure Slack and PagerDuty to receive real-time invalidation notifications'
---
-Set up Slack and PagerDuty integrations to receive notifications when [assertion incidents](/credible/dapp-incidents) occur in your Credible Layer projects.
+Set up Slack and PagerDuty integrations to receive notifications when [assertion invalidations](/credible/dapp-invalidations) occur in your Credible Layer projects.
Looking for the high-level adoption flow? See [How to Plan a Platform Integration](/credible/dapp-integration).
@@ -21,7 +21,7 @@ Looking for the high-level adoption flow? See [How to Plan a Platform Integratio
## Slack Integration
-The Slack integration sends formatted incident notifications to a channel of your choice using Slack's Incoming Webhooks.
+The Slack integration sends formatted invalidation notifications to a channel of your choice using Slack's Incoming Webhooks.
@@ -35,7 +35,7 @@ The Slack integration sends formatted incident notifications to a channel of you
1. In your newly created Slack app, go to **Features → Incoming Webhooks**
2. Toggle **Activate Incoming Webhooks** to **On**
3. Click **Add New Webhook to Workspace**
-4. Select the channel where you want incident notifications
+4. Select the channel where you want invalidation notifications
5. Click **Allow**
@@ -63,7 +63,7 @@ Copy this URL.
## PagerDuty Integration
-The PagerDuty integration creates incidents in PagerDuty when assertion violations occur, using the Events API v2.
+The PagerDuty integration creates PagerDuty incidents when assertion invalidations occur, using the Events API v2.
@@ -91,27 +91,27 @@ Click the **PagerDuty Integration Guide** button in the Credible Layer Settings
1. After saving, click **Send Test Notification**
-2. Verify the incident appears in your PagerDuty service
+2. Verify the PagerDuty incident appears in your PagerDuty service
## What Gets Notified
-Both integrations send notifications when [assertion incidents](/credible/dapp-incidents) occur. Notifications include:
+Both integrations send notifications when [assertion invalidations](/credible/dapp-invalidations) occur. Notifications include:
- Project name and affected contract
- Network/chain information
- Transaction details (hash, block number)
- Assertion violation reason
-- Direct link to view the incident in the dashboard
+- Direct link to view the invalidation in the dashboard
-## How Incidents Are Grouped
+## How Invalidations Are Grouped
-You receive one notification per incident, not per transaction. An incident is defined as an assertion being invalidated within a one-hour time window.
+You receive one notification per invalidation group, not per transaction. An invalidation group is defined as an assertion being invalidated within a one-hour time window.
-If an attacker crafts multiple transactions that all violate the same assertion, these are grouped into a single incident since they represent the same logical attack. After one hour without violations, a new invalidation creates a new incident.
+If an attacker crafts multiple transactions that all violate the same assertion, these are grouped together since they can represent the same logical attack. After one hour without violations, a new invalidation creates a new group.
-This prevents notification spam while ensuring you're alerted to distinct security events. See [Incidents](/credible/dapp-incidents#how-incidents-are-grouped) for more details.
+This prevents notification spam while ensuring you're alerted to distinct security events. See [Invalidations](/credible/dapp-invalidations#how-invalidations-are-grouped) for more details.
This grouping logic is our initial approach and may be refined based on user feedback.
@@ -140,7 +140,7 @@ Removing an integration stops all notifications but does not delete historical d
| Slack webhook URL rejected | Ensure the URL starts with `https://hooks.slack.com/services/` |
| PagerDuty key rejected | Verify the key is exactly 32 alphanumeric characters |
| Test notification not received | Check that the integration is correctly configured in Slack/PagerDuty |
-| No notifications on incidents | Verify the integration shows as "configured" in Settings |
+| No notifications on invalidations | Verify the integration shows as "configured" in Settings |
## Security
@@ -151,8 +151,8 @@ Removing an integration stops all notifications but does not delete historical d
## Next Steps
-
- Learn about incident monitoring
+
+ Learn about invalidation monitoring
Manage your projects
diff --git a/credible/dapp-invalidations.mdx b/credible/dapp-invalidations.mdx
new file mode 100644
index 0000000..8576da7
--- /dev/null
+++ b/credible/dapp-invalidations.mdx
@@ -0,0 +1,138 @@
+---
+title: 'Invalidations'
+description: 'Review invalidation events, invalidating transactions, assertion results, and replay evidence'
+---
+
+An invalidation is recorded when a transaction violates an assertion protecting a contract. In production, the [Enforcer](/credible/glossary#assertion-enforcer) applies the network's documented enforcement policy. On enforced transaction paths, the transaction is rejected before settlement. In staging, the platform records that the transaction would have been rejected, but the transaction can still land on the live network because staging is observe-only.
+
+
+For the end-to-end flow, see the invalidation lifecycle diagram in
+[Architecture Overview](/credible/architecture-overview#invalidation-lifecycle-public-view).
+
+
+## How invalidations are organized
+
+An invalidation event identifies the assertion and contract involved in a violation. An event can contain one or more invalidating transactions, allowing related attempts to be reviewed together while preserving transaction-level evidence.
+
+The platform separates invalidations by environment:
+
+- **Production**: violations detected on enforced assertion paths
+- **Staging**: observe-only violations recorded while an assertion is being evaluated before production promotion
+
+## Project Invalidations (Manager View)
+
+Detailed project invalidations are visible only to the project manager and approved collaborators inside the project dashboard.
+
+Full invalidation evidence is private by default. Project teams can opt in to share invalidation data with Phylax support or participating network security teams when they need help debugging or coordinating a response.
+
+### Invalidation list
+
+Open a project and select **Invalidations**. The page shows the current assertion status, recent invalidation activity, and separate **Production** and **Staging** tabs.
+
+Each invalidation row includes:
+
+- **Date occurred**
+- **Invalidation ID**
+- **Assertion affected**
+- **Contract affected**
+- **Network**
+- **Environment**
+
+Select a row to open the invalidation event.
+
+
+
+
+
+### Invalidation event
+
+The invalidation event page summarizes the event and lists its invalidating transactions.
+
+Event details include:
+
+- **Date occurred**
+- **Invalidation ID**
+- **Public Ref ID**, when available
+- **Assertion affected**
+- **Contract affected**
+- **Environment**
+
+The **Invalid Transactions** table lists the date, transaction hash, sender, and recipient for each transaction in the event. Select a transaction to open its replay.
+
+
+
+
+
+### Invalidating transaction replay
+
+The transaction replay explains what the transaction attempted, how the protocol call executed, and why the assertion rejected it.
+
+The replay includes:
+
+- **Replay overview**: transaction status, hash, sender, recipient, transaction type, nonce, gas, and network
+- **Assertion result**: assertion name, selector, adopter, and revert reason
+- **What changed**: confirmed token, vault, Safe, and administrative events shown in execution order
+- **Execution evidence**: separate views of transaction execution and assertion evaluation
+- **Developer data**: raw transaction and assertion traces, including hidden internal calls when expanded
+- **Execution context**: block state, prior transactions, and block environment used for the replay
+
+The replay shows two separate results:
+
+1. **Transaction execution:** Did the protocol call run successfully?
+2. **Assertion evaluation:** Did the resulting state satisfy the assertion?
+
+A call can pass the first check and fail the second. In that case, the assertion rejects the transaction.
+
+
+
+
+
+### Real-time updates and alerts
+
+Project teams can configure external notifications:
+
+- **Slack**: receive invalidation notifications through a Slack integration
+- **PagerDuty**: send invalidation notifications to an incident-response workflow
+
+Invalidation alerts can represent an active exploit attempt, a false positive affecting legitimate protocol activity, or an assertion that needs tuning. See [Integrations](/credible/dapp-integrations) for setup instructions.
+
+## Invalidations in The Phylax Explorer
+
+The Phylax Explorer can show redacted aggregate invalidation history, such as a reference ID and timestamp, when that data is public. Full transaction payloads, replay evidence, traces, staging records, notification settings, and project-specific evidence remain available only to project managers and approved collaborators.
+
+## Staging vs. production
+
+| Environment | What an invalidation means | User impact |
+| --- | --- | --- |
+| Staging | The transaction would have violated an assertion under production enforcement | The transaction is recorded for review but is not rejected |
+| Production | The transaction violated an enforced assertion | The transaction is rejected before settlement on enforced paths, or handled according to the documented integration policy |
+
+## Use cases
+
+- Monitor assertion violations across production and staging
+- Review the state change and assertion result for an invalidating transaction
+- Inspect transaction execution, assertion evaluation, traces, and replay context
+- Tune assertions using staging evidence before production promotion
+
+
+Invalidation viewing is read-only. You cannot modify or delete invalidation records.
+
+
+## Next steps
+
+
+
+ Learn more about the platform
+
+
+ Browse projects and assertions
+
+
+ Learn how to write effective assertions
+
+
+ Understand how assertion validation works
+
+
diff --git a/credible/dapp-overview.mdx b/credible/dapp-overview.mdx
index 7a590ff..836b4e6 100644
--- a/credible/dapp-overview.mdx
+++ b/credible/dapp-overview.mdx
@@ -1,9 +1,13 @@
---
title: 'Platform Overview'
-description: 'Overview of the Phylax platform and its role in the Credible Layer stack'
+description: 'Overview of the Phylax platform, The Phylax Explorer, and invalidation monitoring'
---
-The [Phylax platform](https://app.phylax.systems) is the interface for managing assertions and monitoring invalidations. Protocol teams use it to create projects, link contracts, review releases, deploy assertions, and inspect events that would violate those assertions. When deploying assertions, teams choose between Staging (for testing) or Production (for active protection). Users, auditors, and researchers use the public explorer to review which assertions protect specific protocols.
+The [Phylax platform](https://app.phylax.systems) is the interface for managing assertions, reviewing protocol protection posture, and monitoring invalidations. Protocol teams use it to create projects, link contracts, review releases, deploy assertions, add evidence links, and inspect events that would violate those assertions. When deploying assertions, teams choose between Staging for testing and Production for active protection.
+
+Public users, allocators, auditors, and researchers use [The Phylax Explorer](/credible/dapp-explorer) to review what a protocol has protected, how those protections work, which operational properties are visible, whether deployed code appears to differ from known audited code, and what evidence supports the protocol's public security posture.
+
+The platform also includes views in The Phylax Explorer that help protocols explain their security setup. These views can show assertion summaries, assertion triggers, operational risk cards, public audits, and deployed-vs-audited code context where evidence is available.
When you create a project and deploy assertions through the platform, the project remains an off-chain organizing layer. The on-chain [State Oracle](./credible-layer-contracts#state-oracle) contracts are the source of truth for which assertion IDs are attached to which contract addresses and when those assertions become active.
@@ -11,21 +15,32 @@ Adding an assertion or removing one is not instantaneous. Both operations pass t
## Core Components
-### Transparency Dashboard
+### The Phylax Explorer
+
+**[The Phylax Explorer](/credible/dapp-explorer)** is the public dashboard that displays the security and operational risk posture of protocols that have opted into runtime enforcement. Users can find the following:
+
+- Summaries of the actions protected by circuit breakers and assertions
+- Scenarios the assertions prevent
+- Summaries of what each assertion or circuit breaker does and the failure modes they prevent
+- If the protocol is governed by an admin multisig wallet, documentation of the breakdown of roles on the admin wallet, its signer threshold, and the time delay required when making changes
+- Documentation of whether each contract is upgradeable or not
+- Whether the current deployed protocol has meaningfully diverged from the code at the time of audit
+
+### Security Posture Evidence
-The [Transparency Dashboard](/credible/dapp-transparency-dashboard) provides public visibility into projects and their assertions. Browse, search, and review which protocols are protected and how.
+The Phylax Explorer can organize assertion summaries, operational risk cards, and deployed-vs-audited code checks into one public project view. This helps protocol teams show what is protected, what evidence is available, and what still needs review.
### Projects
The [Projects](/credible/dapp-projects) interface enables protocol teams to create and manage projects, link contract addresses, and associate assertions with their contracts.
-### Incidents
+
+
+
-The [Incidents](/credible/dapp-incidents) page tracks invalidations: transactions that violated assertions in production, or would have violated assertions in staging. Production invalidations correspond to transactions that were dropped before settlement. Staging invalidations are observe-only records that help teams tune assertions before promotion.
+### Invalidations
-
-
-
+The [Invalidations](/credible/dapp-invalidations) page tracks transactions that violated assertions in production, or would have violated assertions in staging. Production invalidations correspond to transactions that were dropped before settlement. Staging invalidations are observe-only records that help teams tune assertions before promotion.
## Authentication
@@ -37,17 +52,24 @@ Authentication is required to create and manage projects. Open the platform at [
## Key Features
-- **Public transparency**: Browse public projects, protected contracts, and assertion posture
+- **Public project review**: Browse public projects, protected contracts, and assertion posture
+- **Protection summaries**: Review release-generated summaries of protected actions, circuit breakers, assertion behavior, and failure modes
+- **Operational risk cards**: Inspect verifiable properties such as admin roles, signer thresholds, timelocks, role segregation, and upgradeability when available
+- **Deployed-vs-audited code context**: See whether current deployed implementation code appears to differ from the most recent known audited code when metadata is available
+- **Evidence links**: Review project-provided GitHub, audit, and formal verification links
- **Release review**: Inspect assertion changes before signing on-chain deployment transactions
- **Unified management**: Manage assertion releases, project metadata, and notification settings from one interface
- **Invalidation monitoring**: Track assertion failures in staging and production
-- **Verifiable security**: Users can verify protection before interacting with protocols
+- **Verifiable posture**: Users can review protection before interacting with protocols
## Getting Started
-
- Browse and search public projects and assertions
+
+ Browse public projects, assertions, evidence, and operational posture
+
+
+ Understand assertion summaries, risk cards, and audit context
Create and manage your protocol projects
@@ -55,7 +77,7 @@ Authentication is required to create and manage projects. Open the platform at [
Step-by-step guide to deploying assertions
-
+
Track production drops and staging invalidations
@@ -67,9 +89,6 @@ Authentication is required to create and manage projects. Open the platform at [
Understand ownership requirements
-
- Fallback process for immutable contracts
-
High-level adoption flow for protocol teams
diff --git a/credible/dapp-projects.mdx b/credible/dapp-projects.mdx
index 354aeef..7d4a1e7 100644
--- a/credible/dapp-projects.mdx
+++ b/credible/dapp-projects.mdx
@@ -7,6 +7,8 @@ Projects are the organizational unit in the [Phylax platform](https://app.phylax
## What are Projects?
+Projects enable you to manage all your protocol's assertions from a single interface. The project itself is an off-chain organizing layer; the on-chain [State Oracle](/credible/credible-layer-contracts#state-oracle) remains the source of truth for which assertions are active for each protected contract.
+
A project groups together:
- One or more smart contract addresses
- Assertions that protect those contracts
@@ -14,9 +16,6 @@ A project groups together:
- Staging and production invalidations
- Notification settings and project events
- Collaborators and role-based access
-- Project metadata (name, description, target chain)
-
-Projects enable you to manage all your protocol's assertions from a single interface. The project itself is an off-chain organizing layer; the on-chain [State Oracle](/credible/credible-layer-contracts#state-oracle) remains the source of truth for which assertions are active for each protected contract.
## Creating a Project
@@ -43,7 +42,7 @@ To create a new project:
Only authorized admins can create a project for a contract. Most deployments use owner-based verification by default. See [Ownership Verification](/credible/ownership-verification) for details.
-For contracts that don't pass the default verifier, you may be able to [request manual verification](/credible/manual-verification).
+For rollup contracts that don't pass the default verifier, you may be able to [request manual verification](/credible/manual-verification). Manual verification is not available for Ethereum mainnet contracts.
## Managing Projects
@@ -55,23 +54,31 @@ Once created, you can manage your project through the project dashboard:
- View project metadata
- See all assertions
- See project events in the audit log, including assertion, contract, release, notification, collaborator, and invalidation activity
-- See all [incidents](/credible/dapp-incidents)
+- See all [invalidations](/credible/dapp-invalidations)
-### Add or Remove Contracts
-- Add new contract addresses to your project
-- Remove contracts that are no longer active
-- Update contract information
+### Create a Release
+- Run `pcl apply` to build your assertions and create a pending release
+- Review the requested assertion changes before confirming the release
+- Open the returned release link in the platform
-### Deploy Assertions
-- Deploy assertions to your project via `pcl apply`
-- Review release changes through the platform
-- View all active assertions protecting your contracts
+### Deploy the Release Onchain
+- Review the release and link assertions to protected contracts
+- Choose Staging or Production
+- Sign the deployment transaction
-
-
+
+
-For detailed instructions on deploying assertions, see the [Deploy Assertions guide](/credible/deploy-assertions-dapp#step-4-deploy-the-assertion).
+
+
+
+
+
+
+
+
+For detailed instructions, see the [Deploy Assertions guide](/credible/deploy-assertions-dapp#step-4-deploy-the-assertion).
### Project Settings
@@ -84,14 +91,14 @@ Here you can update the project name, description, and delete the project.
You can transfer projects and contracts (including their associated assertions) to other wallets. This allows you to transfer project ownership while maintaining all linked assertions and contracts.
**Protocol admin / manager wallet:**
-The wallet that signs assertion lifecycle transactions can be separate from the day-to-day platform account. Use this separation when your team wants project collaborators to review releases and incidents without requiring routine access to the multisig or governance wallet that controls deployment.
+The wallet that signs assertion lifecycle transactions can be separate from the day-to-day platform account. Use this separation when your team wants project collaborators to review releases and invalidations without requiring routine access to the multisig or governance wallet that controls deployment.
**Access controls:**
Admins can invite collaborators by email or wallet address. Use roles to separate review work from deployment authority:
| Role | Typical permissions |
| --- | --- |
-| Viewer | View incidents and project information without making changes |
+| Viewer | View invalidations and project information without making changes |
| Editor | Create releases and configure notifications |
| Admin | Manage members, settings, and the protocol manager wallet |
@@ -99,26 +106,40 @@ Admins can invite collaborators by email or wallet address. Use roles to separat
Detailed invalidation evidence is scoped to project members. Admins can opt in to share invalidations or transactions dropped by the node operator with Phylax support and network teams for customer support and debugging.
**Integrations:**
-Set up integrations to receive notifications when incidents occur, including Slack and PagerDuty where available.
+Set up integrations to receive notifications when invalidations occur, including Slack and PagerDuty where available.
+### Security Evidence Links
+
+Protocol teams can keep project evidence up to date so The Phylax Explorer can show a more complete public project page.
+
+Useful evidence includes:
+
+- public repository links
+- audit report links
+- audit scope or commit references, where available
+- formal verification links, where applicable
+- protected-contract labels
+- assertion names and descriptions
+
+This metadata helps reviewers understand what is protected, which code was reviewed, and whether deployed code appears to match known audited code.
+
## Project Dashboard
The project dashboard provides a unified view of your project's security:
-- **Active Assertions**: See all assertions currently protecting your contracts
-- **Assertion Deployment**: Deploy or remove assertions for your project
-- **Ready for Deployment**: Assertions submitted via `pcl` that need to be linked and deployed
-- **Assertion Status**: Monitor execution status and any triggered violations. Status shows whether assertions are marked for enforcement/staging or enforced/staged
-- **Recent Incidents**: View detailed incidents for your project (see [Incidents](/credible/dapp-incidents#project-incidents-manager-view))
-- **Audit Log**: Review project changes, assertion lifecycle events, collaborator changes, release activity, and invalidations over time
-- **Project Settings**: Update project details and manage contracts
+- **Assertions**: View active and pending assertions
+- **Releases**: Review and deploy changes
+- **Operational Risk**: Review authority and change paths
+- **Evidence**: Review audits and deployed-code context
+- **Invalidations**: Inspect assertion violations
+- **Audit Log and Settings**: Review activity and manage the project
-
+
### Audit Log
@@ -133,7 +154,7 @@ Audit log entries can include:
- Production and staging release events
- Protocol manager changes
- Collaborator role changes
-- Invalidations and incident-related activity
+- Invalidation-related activity
diff --git a/credible/dapp-transparency-dashboard.mdx b/credible/dapp-transparency-dashboard.mdx
deleted file mode 100644
index 4ca39a4..0000000
--- a/credible/dapp-transparency-dashboard.mdx
+++ /dev/null
@@ -1,90 +0,0 @@
----
-title: 'Transparency Dashboard'
-description: 'Browse and analyze public projects and their active assertions'
----
-
-The Transparency Dashboard is a public interface that displays projects registered on the Credible Layer, their linked contracts, and the assertions protecting them.
-
-
-For a high-level view of how the platform interfaces with the rest of the system, see
-[Interface Overview](/credible/interfaces-overview).
-
-
-## Features
-
-### Browse Projects
-
-View public projects and their details:
-- Project names, descriptions, and target chains
-- Linked contract addresses
-- Active assertions protecting each contract
-- Assertion implementation details, trigger conditions, and parameters
-- Recent public events related to contracts and assertions being added or removed
-- Limited public invalidation records, when available
-
-### Search / Filter
-
-- You can search for projects at any time using the search bar in the top right corner or by hitting `cmd/ctrl + k`
-- You can filter projects by network
-
-## Accessing the Transparency Dashboard
-
-1. Click the "Transparency" tab in the navigation bar
-2. Browse projects
-
-
-
-
-
-## Use Cases
-
-**For Users and Security Researchers**
-- Verify which assertions protect a protocol before interacting
-- Compare security postures across protocols
-
-**For Developers**
-- Browse assertions from protocols with similar contracts
-- Learn from existing assertion implementations
-- Copy and adapt assertion patterns for your own protocol
-
-## Visibility Boundaries
-
-The public explorer is designed to make assertion posture reviewable without exposing private incident evidence.
-
-Public views can show:
-- Projects and protected contracts
-- Active assertion posture
-- Public project events
-- Limited invalidation metadata
-- Aggregate invalidation history, such as a reference ID and timestamp
-
-Private project views are required for:
-- Full invalidating transaction payloads
-- Execution traces and assertion traces
-- Staging invalidations
-- Notification and project management settings
-
-Detailed invalidation evidence is scoped to project managers and approved collaborators. Public views keep the dashboard useful for posture review while private views retain the full payloads and traces needed for triage.
-
-## Why Users Trust Protected Protocols
-
-- **Public registry**: Assertions and protected contracts are visible on-chain
-- **Transparent enforcement**: Dropped transactions surface as limited public invalidation records and detailed private project incidents
-- **Auditable rules**: Assertions are published Solidity, not opaque policy
-
-## Next Steps
-
-
-
- Learn more about the platform
-
-
- Create your own project
-
-
- Learn more about invalidations
-
-
- Learn how to write assertions
-
-
diff --git a/credible/deploy-assertions-dapp.mdx b/credible/deploy-assertions-dapp.mdx
index 83a10ba..86ac20b 100644
--- a/credible/deploy-assertions-dapp.mdx
+++ b/credible/deploy-assertions-dapp.mdx
@@ -71,7 +71,7 @@ Configure your `credible.toml` and create a release with `pcl apply`:
pcl apply
```
-This reads your `credible.toml` configuration, builds the assertion contracts, previews the requested changes, and creates a pending release on the platform after you confirm. See [Apply Assertions](/credible/apply-assertions) for detailed instructions on configuring `credible.toml` and using `pcl apply`.
+This reads your `credible.toml` configuration, builds the assertion contracts, previews the requested changes, and creates a pending release on the platform after you confirm. Creating a release also generates the plain-English summaries shown in The Phylax Explorer for the protections in that release. See [Apply Assertions](/credible/apply-assertions) for detailed instructions on configuring `credible.toml` and using `pcl apply`.
## Step 4: Deploy the Assertion
@@ -118,7 +118,7 @@ After deployment, manage assertions through your project dashboard:
- **View Active Assertions**: See all assertions protecting your contracts
- **Monitor Status**: Check assertion execution and triggered violations
-- **View Incidents**: View incidents that were prevented by assertions
+- **View Invalidations**: View transactions that were invalidated by assertions
- **Update Assertions**: Submit new versions as your protocol evolves
- **Remove Assertions**: Request removal when needed; the assertion remains active until the State Oracle timelock finishes
@@ -126,7 +126,7 @@ After deployment, manage assertions through your project dashboard:
| Error | Solution |
|-------|----------|
-| "Contract ownership verification failed" | Ensure your wallet passes the admin verifier (often `owner()`) or [request manual verification](/credible/manual-verification) if available |
+| "Contract ownership verification failed" | Ensure your wallet passes the admin verifier (often `owner()`) or, for rollup contracts only, [request manual verification](/credible/manual-verification) if available |
| "Assertion already exists" | Use a different name or update the existing assertion |
| "Authentication expired" | Run `pcl auth login` to refresh |
@@ -155,7 +155,7 @@ Full walkthrough from authentication to deployment:
Test your assertions before deployment
-
+
Monitor prevented violations
diff --git a/credible/evaluate-credible-layer.mdx b/credible/evaluate-credible-layer.mdx
index cd5b821..5bd22fa 100644
--- a/credible/evaluate-credible-layer.mdx
+++ b/credible/evaluate-credible-layer.mdx
@@ -11,14 +11,14 @@ This checklist helps teams evaluate whether the Credible Layer is a fit for thei
- Can we encode those rules as assertions in Solidity?
- Do we want pre-execution protection rather than post-mortem monitoring?
- Are we comfortable with transparent, public rules?
-- Do we have a team to monitor incidents and iterate on rules?
+- Do we have a team to monitor invalidations and iterate on rules?
## For Networks & Sequencers
- Can we integrate an external enforcer into block building?
- Do we want a policy layer for transaction admission?
- Do we want to offer protocol teams optional enforcement?
-- Do we have monitoring and incident review workflows?
+- Do we have monitoring and invalidation review workflows?
## Decision Support
diff --git a/credible/explorer-security-posture.mdx b/credible/explorer-security-posture.mdx
new file mode 100644
index 0000000..3fa9e7c
--- /dev/null
+++ b/credible/explorer-security-posture.mdx
@@ -0,0 +1,87 @@
+---
+title: 'Security Posture in The Phylax Explorer'
+description: 'How The Phylax Explorer presents release-generated protection summaries, operational authority, change paths, and supporting evidence'
+---
+
+The Phylax Explorer is a public diligence surface for protocols that use runtime enforcement. It brings together the protocol's protected actions, assertion details, operational authority, contract change paths, and supporting evidence so reviewers can evaluate the underlying facts in one place.
+
+The Phylax Explorer does not assign a security score or claim that a protocol is safe. Instead, it shows what can be verified and links reviewers to the contracts, accounts, assertion source code, and security documents that support each finding.
+
+
+Public views in The Phylax Explorer are for review. Some transaction payloads, traces, staging data, and project-management controls are only available to project members.
+
+
+## Start with the project overview
+
+The project overview establishes the scope of the review. It identifies the network, protocol manager, public repository, protected contracts, active assertions, and available audits or security documents.
+
+The overview also includes a plain-English project summary and a list of protected actions. The project team creates these summaries as part of each new release, so the description reflects the assertions included in that release rather than a static project description.
+
+
+
+
+
+## Understand what each assertion protects
+
+Open an assertion to review the protection at assertion level. The summary connects the assertion's intent to the deployed contracts and execution conditions that a technical reviewer can inspect.
+
+An assertion page can show:
+
+- **Unsafe condition**: the failure mode the assertion is designed to prevent
+- **Protected action**: the transaction behavior the assertion blocks when its rule is violated
+- **Linked contracts**: the contracts covered by the assertion
+- **Triggers**: the calls or state changes that cause the assertion to execute
+- **Source code**: the implementation behind the plain-English description
+
+These summaries make assertion behavior easier to assess, but they do not replace review of the assertion source code, protocol contracts, or audit reports.
+
+## Review operational authority and change paths
+
+The **Operational Risk** section describes how the reviewed contracts can change. It begins with a project-level finding and four summaries that answer:
+
+- **Who holds change power?** The authority mechanisms that control the reviewed paths, such as multisig wallets.
+- **What is the fewest approval count?** The lowest signer threshold among the reviewed paths.
+- **How soon can a change execute?** The shortest enforced waiting period found across those paths.
+- **Can another route avoid protections?** Whether an alternate path can bypass approvals or delays used elsewhere.
+
+These are project-wide summaries of the least-protected reviewed route. They should be read with the detailed evidence below them, not as independent ratings.
+
+
+
+
+
+### Who can do what
+
+The **Who can do what** table maps each affected contract to its authority mechanism and controlling account. For a multisig-controlled route, it also shows the signer threshold and links to the authority account on the block explorer.
+
+This separates the question of who can authorize a change from the question of what that authority can change.
+
+### How protocol changes can happen
+
+The **How protocol changes can happen** section expands each reviewed route. A route identifies:
+
+- what can change, such as fees, roles, availability, authorized solvers, or contract implementation
+- which contract is affected and whether it is direct or upgradeable
+- the account or signer group that authorizes the change
+- the minimum approvals required
+- the earliest execution time, including any enforced delay
+- the contracts and accounts that make up the route
+- whether the route can execute sooner than another route protecting the same outcome
+
+### Contracts with no change route
+
+When the analysis finds no active material change path for a contract at the pinned block, The Phylax Explorer lists it under **Contracts with no change route**. The 0x-settler project demonstrates this distinction: contracts with reviewed owner-controlled solver routes appear separately from contracts for which no material change route was active.
+
+This is evidence about the analyzed state, not a permanent immutability guarantee. Review the pinned analysis, contract links, and any staleness warning before relying on the result.
+
+## Inspect the supporting evidence
+
+Protocol teams can publish repository links, audit reports, audited commit references, and formal verification materials. The **Audits and security documents** table makes every public report uploaded by the project team available from the project overview.
+
+Evidence should be reviewed whenever contracts are upgraded, assertions are added or removed, governance authority changes, or a new audit is published. Operational-risk analysis can also become stale as on-chain configuration changes, so check its update warning and underlying contract links before making a decision.
+
+
+The Phylax Explorer is not a certification, audit replacement, insurance product, or guarantee that a protocol cannot fail.
+
diff --git a/credible/faq.mdx b/credible/faq.mdx
index 0f9cd11..cc3ee15 100644
--- a/credible/faq.mdx
+++ b/credible/faq.mdx
@@ -18,7 +18,7 @@ Use this page for short answers. If you are trying to complete a task, go to the
### What is the Phylax Credible Layer?
The Credible Layer is a network extension that enables developers to link security rules to their smart contracts on-chain.
-These rules are defined in Solidity, executed off-chain, and enforced by the network during block building. Since these rules are verifiable, apps can turn implicit security assumptions into an explicit security posture using our transparency dashboard so that users can trust the apps they use.
+These rules are defined in Solidity, executed off-chain, and enforced by the network during block building. Since these rules are verifiable, apps can turn implicit security assumptions into an explicit security posture using The Phylax Explorer so that users can inspect the protections behind the apps they use.
**Learn More:**
- [Credible Layer Overview](/credible/credible-layer-overview) - Non-technical introduction
@@ -28,7 +28,7 @@ These rules are defined in Solidity, executed off-chain, and enforced by the net
There are several key advantages:
1. **Off-chain Execution**: Rules that would be too expensive or impossible to express on-chain due to gas costs and limits can be implemented easily as assertions as they are run off-chain. Our current benchmarks show around 1000x efficiency gains.
-2. **Simpler Security Model**: By writing invariants that define a state to prevent instead of every edge case that would lead there, you simplify and strengthen your protocol. If you are confused about what an invariant is, read on 👇🏻
+2. **Simpler Security Model**: By writing invariants that define a state to prevent instead of every edge case that would lead there, you simplify and strengthen your protocol.
3. **No redeployment or downtime**: Add new security rules without modifying your existing contracts. You can even add rules to immutable contracts. To learn how this is possible read the [How do you extend the validation logic of the sequencer to the platform?](#how-do-you-extend-the-validation-logic-of-the-sequencer-to-the-platform) section below.
**Learn More:**
@@ -55,16 +55,17 @@ While audits provide point-in-time code reviews, the Credible Layer offers conti
- [Writing Assertions Guide](/credible/write-first-assertion)
- [Assertions Book](/assertions-book/assertions-book-intro)
-### What is the transparency dashboard?
-The transparency dashboard is a tool that allows anyone to view public projects and their active assertion posture.
-It is useful for end users because they can review what protections a protocol has made visible, while developers can use it to learn from assertions used by protocols with similar contracts.
+### What is The Phylax Explorer?
+**[The Phylax Explorer](/credible/dapp-explorer)** is the public dashboard that displays the security and operational risk posture of protocols that have opted into runtime enforcement.
+
+Users can find summaries of actions protected by circuit breakers and assertions, scenarios the assertions prevent, operational details for admin multisig wallets, upgradeability documentation, and whether the currently deployed protocol has meaningfully diverged from the code at the time of audit.
**Learn More:**
- [Deploy Assertions](/credible/deploy-assertions-dapp)
-- [Glossary - Transparency Dashboard](/credible/glossary#transparency-dashboard)
+- [Glossary - The Phylax Explorer](/credible/glossary#the-phylax-explorer)
### Is the Credible Layer a SaaS protocol?
-No. The Credible Layer is a protocol with a product surface around it: the platform and `pcl` help teams author, review, deploy, and monitor assertions, while the on-chain registry remains the source of truth for active assertion state.
+No. The Credible Layer is a protocol with product tools around it: the platform and `pcl` help teams author, review, deploy, and monitor assertions, while the on-chain registry remains the source of truth for active assertion state.
Access to assertion management is still gated by authorization. Only verified protocol admins can attach assertions to protected contracts, and supported networks may have onboarding or availability constraints.
@@ -146,7 +147,7 @@ considered invalid and is dropped before it can be included in a block.
**Learn More:**
- [Assertion Enforcer](/credible/assertion-enforcer)
-- [Incidents](/credible/dapp-incidents)
+- [Invalidations](/credible/dapp-invalidations)
### What are cheatcodes and how do they help?
@@ -178,11 +179,11 @@ Editing an assertion is straightforward:
Yes, you can copy and adapt assertions from other protocols and use them to protect your own protocol.
You should make sure that the assertions are compatible with your protocol.
It will make the most sense to copy assertions for standard libraries and interfaces.
-You can inspect public assertion posture on the transparency dashboard. Some project and invalidation details are only visible to project managers and collaborators.
+You can inspect public assertion posture in The Phylax Explorer. Some project and invalidation details are only visible to project managers and collaborators.
**Learn More:**
- [Assertions Book](/assertions-book/assertions-book-intro)
-- [Transparency Dashboard](/credible/dapp-transparency-dashboard)
+- [The Phylax Explorer](/credible/dapp-explorer)
---
@@ -205,12 +206,12 @@ You can inspect public assertion posture on the transparency dashboard. Some pro
**Learn More:**
- [Architecture - Abstract Overview](/credible/architecture-overview#abstract-overview)
-### How are L1-originated transactions handled for OP Stack rollups?
+### How are externally originated transactions handled?
-OP Stack integrations define a validation policy for L1-originated deposits as part of the network integration. The policy specifies where assertion validation runs, how results are routed to sequencing components, and which incident metadata is sent to affected protocols.
+Network integrations define validation policy for transactions that do not enter through ordinary user RPC flow, such as bridge-originated actions, delayed queues, scheduled system transactions, or forced-inclusion-style paths. The policy specifies where assertion validation runs, how results are routed into sequencing or block-building components, what timeout behavior applies, and which invalidation context is sent to affected protocols.
**Learn More:**
-- [Network Integration Overview - L1-originated transaction paths](/credible/network-integration#l1-originated-transaction-paths)
+- [Network Integration Overview - Transaction Source Coverage](/credible/network-integration#transaction-source-coverage)
- [Glossary - Forced Inclusion Transactions](/credible/glossary#forced-inclusion-transactions)
### Does the Credible Layer introduce new trust assumptions or centralization points?
@@ -242,15 +243,13 @@ The practical requirement is that assertion workers keep up with the transaction
### How do you extend the validation logic of the sequencer to the platform?
-For OP stack chains, Flashbots introduced a piece of software that enables a sequencer to have an external block-builder that implements custom block-building logic, without changing the sequencer itself. This is also what powers Flashblocks.
-
-For other chains, the exact implementation varries but generally follows the following architecture:
+The exact implementation depends on the network architecture. The shared model is that the network adds an enforcement hook around block building, sequencing, preflight validation, or another documented inclusion boundary.
-Our custom block builder enables the sequencer to check each transaction against assertions defined through the platform.
-This requires no changes to contracts as it is effectively middleware.
+That hook sends candidate transaction context to the Assertion Enforcer. The enforcer selects relevant assertions, executes them, and returns a valid or invalid result that the integration applies before settlement. This requires no changes to protected contracts because assertions run as enforcement middleware around transaction inclusion.
**Learn More:**
-- [Architecture - OP Stack Implementation](/credible/network-integrations/architecture-op-stack)
+- [Network Integration Overview](/credible/network-integration)
+- [Assertion Enforcer](/credible/assertion-enforcer)
- [Glossary - Block Builder](/credible/glossary#block-builder)
### Can anyone write assertions for my contracts?
@@ -264,7 +263,9 @@ This way, we ensure that no malicious third party reduces functionality by writi
### My protocol doesn't support the owner interface. Can I still use the Credible Layer?
-Yes, but you may need manual verification. If your contracts are immutable or do not expose an admin interface such as `owner()`, Phylax can verify off-chain evidence that your team controls the protocol and then register the selected protocol admin for the specific contracts.
+Yes, if the contracts are deployed on a supported rollup. You may need manual verification if your contracts are immutable or do not expose an admin interface such as `owner()`. Phylax can verify off-chain evidence that your team controls the protocol and then register the selected protocol admin for the specific contracts.
+
+Manual verification is not available for Ethereum mainnet contracts because enforcement works differently on L1 and L2 blockchains.
**Learn More:**
- [Ownership Verification](/credible/ownership-verification)
diff --git a/credible/glossary.mdx b/credible/glossary.mdx
index 659a3d2..63e6a32 100644
--- a/credible/glossary.mdx
+++ b/credible/glossary.mdx
@@ -54,8 +54,8 @@ Learn more: [Assertion Enforcer](/credible/assertion-enforcer)
### Platform
The [Phylax platform](https://app.phylax.systems) is the web application interface for interacting with the Credible Layer. It allows protocol teams and end-users to deploy, manage, and view assertions and projects.
-### Transparency Dashboard
-A public interface for browsing projects, protected contracts, active assertions, and limited invalidation metadata. Detailed project management data, staging invalidations, transaction payloads, and traces are only available in private project views.
+### The Phylax Explorer
+A public dashboard that displays the security and operational risk posture of protocols that have opted into runtime enforcement. It can show summaries of actions protected by circuit breakers and assertions, scenarios the assertions prevent, assertion and circuit breaker behavior, admin multisig details, contract upgradeability documentation, and deployed-vs-audited code context where available. Detailed project management data, staging invalidations, transaction payloads, and traces are only available in private project views.
### Sidecar
A software architecture pattern where a component runs alongside the main application without changing core protocol rules. The Credible Layer operates as a sidecar to the network's block builder, intercepting and validating transactions during the block building process.
@@ -164,10 +164,10 @@ The ability to inspect the rules and registry state behind a protocol's Credible
## Prevention
-### Incident
-A security event representing the invalidation of an assertion over a one-hour time period. Multiple dropped transactions can belong to the same incident if they violate the same assertion within that window. This grouping treats repeated attempts to exploit the same vulnerability as a single logical attack.
+### Invalidation
+A transaction that violated an assertion protecting a contract. In production, the transaction is dropped before settlement. In staging, the platform records that the transaction would have been dropped, but the transaction still lands on the live network because staging is observe-only.
-Learn more: [Incidents](/credible/dapp-incidents)
+Learn more: [Invalidations](/credible/dapp-invalidations)
### Revert
What happens at the EVM/Solidity level when an assertion function detects that a transaction violates the rules defined in the assertion. When an assertion reverts, it signals that the transaction would result in an undesired state. The sidecar detects this revert and notifies the sequencer that the transaction should be dropped.
diff --git a/credible/interfaces-overview.mdx b/credible/interfaces-overview.mdx
index 4c80fdf..cefd789 100644
--- a/credible/interfaces-overview.mdx
+++ b/credible/interfaces-overview.mdx
@@ -44,7 +44,7 @@ The Credible Layer combines protocol components with Phylax-operated product sur
| `pcl` CLI | Builds, tests, authenticates, and submits assertion releases | Local developer tooling |
| Backtesting | Replays assertions against historical transactions before promotion | Phylax-operated development service |
| Staging | Runs assertions against live network activity without dropping transactions | Phylax-operated validation environment |
-| Platform | Manages releases, incidents, audit logs, collaborators, alerts, and project metadata | Phylax product |
+| Platform | Manages releases, invalidations, audit logs, collaborators, alerts, and project metadata | Phylax product |
## Guidance
diff --git a/credible/manual-verification.mdx b/credible/manual-verification.mdx
index f9fd41c..efc9fb8 100644
--- a/credible/manual-verification.mdx
+++ b/credible/manual-verification.mdx
@@ -1,16 +1,21 @@
---
title: 'How to Request Manual Verification'
-description: 'Request protocol admin authorization when contracts lack supported owner interfaces'
+description: 'Request protocol admin authorization for rollup contracts that lack supported owner interfaces'
---
-This guide shows you how to prepare a manual verification request when your contracts are immutable or do not expose a supported admin interface such as `owner()`.
+This guide shows you how to prepare a manual verification request when your rollup contracts are immutable or do not expose a supported admin interface such as `owner()`.
Manual verification is the fallback path. If your target contracts expose a supported owner interface, use the normal [Ownership Verification](/credible/ownership-verification) and [deployment](/credible/deploy-assertions-dapp) flow instead.
+
+Manual verification is only available for contracts deployed on rollups. It is not available for Ethereum mainnet contracts because enforcement works differently on L1 and L2 blockchains.
+
+
## Prerequisites
+- The target contracts are deployed on a supported rollup, not Ethereum mainnet.
- The target contracts do not pass automatic owner-based verification.
- You can identify the contract addresses that need a protocol admin.
- You have selected the smart contract or EOA that should manage assertions for those contracts.
@@ -28,7 +33,7 @@ interface IOwnable {
}
```
-If your contracts expose this interface, use [Ownership Verification](/credible/ownership-verification). If they are immutable or use a different ownership architecture, continue with manual verification.
+If your contracts expose this interface, use [Ownership Verification](/credible/ownership-verification). If they are rollup contracts that are immutable or use a different ownership architecture, continue with manual verification. Manual verification is not available for Ethereum mainnet contracts.
## Step 2: Choose the Protocol Admin Address
@@ -65,6 +70,7 @@ Phylax reviews manual verification requests in good faith on a case-by-case basi
Manual verification will not be offered if:
+- The target contracts are deployed on Ethereum mainnet.
- The protocol is fully anonymous.
- The team refuses to provide public proofs.
- The submitted evidence is insufficient to verify the rightful protocol maintainer or owner.
diff --git a/credible/network-integration.mdx b/credible/network-integration.mdx
index df1b7e3..d6105a9 100644
--- a/credible/network-integration.mdx
+++ b/credible/network-integration.mdx
@@ -6,7 +6,7 @@ description: 'High-level integration path for networks and sequencers adopting t
Use this page when your goal is to scope a network integration and identify the infrastructure surfaces your team will need.
-If you need concrete implementation details, continue to the [Linea / Besu integration](./network-integrations/architecture-linea) or [OP Stack implementation](./network-integrations/architecture-op-stack). If you need background first, read the [Architecture Overview](./architecture-overview).
+This page describes the shared integration model. Network-specific runbooks can add client, sequencer, builder, or validator details without changing the guarantees described here. If you need background first, read the [Architecture Overview](./architecture-overview).
This page explains how networks integrate the Credible Layer at a high level. It focuses on the
@@ -26,7 +26,9 @@ title: Network Integration Flow
---
flowchart LR
Users[Users + Applications] --> RPC[Network RPC]
- RPC --> Builder[Block Builder]
+ System[Bridge, System, or Delayed Queues] --> Policy[Integration Policy]
+ RPC --> Policy
+ Policy --> Builder[Block Builder or Sequencer]
Builder --> Enforcer[Assertion Enforcer]
Enforcer -->|valid| Block[Block]
Enforcer -->|invalid| Drop[Dropped]
@@ -38,56 +40,76 @@ flowchart LR
Networks provide the following integration surfaces:
-- **Block-building hook**: the block builder queries the Assertion Enforcer before including a
- transaction
+- **Block-building hook**: the block builder or sequencer queries the Assertion Enforcer before including a transaction
+- **Transaction-source policy**: the integration defines how user-submitted, system-originated, bridge-originated, delayed, or forced-inclusion-style transaction paths are validated
+- **Result routing**: validation results are routed back into the block-building or sequencing policy that decides whether a candidate transaction can be included
- **Registry access**: the enforcer consumes registry data (indexed from on-chain events) to discover which assertions apply
- **Assertion data access**: the enforcer fetches assertion bytecode from Assertion DA
-- **Operational monitoring**: incidents and status are surfaced via the Phylax platform
+- **Operational monitoring**: invalidations, assertion status, alerting, and audit-log events are surfaced via the Phylax platform
## Integration Policy Decisions
Network integrations should define how enforcement is applied across the network's transaction paths and traffic management layers.
-### L1-originated transaction paths
+### Transaction Source Coverage
-Some rollups include L1-originated transaction paths, deposits, or delayed inboxes alongside ordinary sequencer-selected transactions. The integration policy should specify how assertion validation fits into each path.
+Some networks include transaction paths beyond ordinary user RPC flow. Examples include bridge-originated actions, delayed queues, scheduled system transactions, or forced-inclusion-style paths. The integration policy should specify how assertion validation fits into each path.
Before production rollout, define:
-- Which L1-originated, deposit, or delayed inbox paths the network supports
-- Where assertion validation runs for those transactions
-- How validation results are routed into sequencing or block-building policy
-- Which application-layer response options protocols can use during the validation window
-- What incident metadata is sent to affected protocols
+- Which transaction sources the integration covers
+- Where assertion validation runs for each source
+- Whether validation happens before admission, before inclusion, during block building, or at another documented boundary
+- How validation results are routed into sequencing, block-building, or preflight policy
+- Which application-layer response options protocols can use when the integration provides a response window
+- Timeout and fallback behavior when validation cannot classify a transaction in time
+- What invalidation metadata is sent to affected protocols
-L1-originated transaction policy is network-specific and should be documented as part of the integration.
+Transaction-source policy is integration-specific and should be documented before production enforcement.
+
+### Bounded Response Windows
+
+Some architectures can create a bounded window between detecting an unsafe transaction and the point where network rules require a final inclusion decision. If the integration uses such a window, document:
+
+- The maximum delay or response budget
+- What happens when the budget expires
+- Whether the transaction is retried, released, rejected, or escalated
+- Which protocol mitigations can be used, such as pausing a contract path, changing a risk parameter, quarantining a known unsafe origin, or invalidating off-chain orders or intents
+- What observability is required for every delayed, retried, or released transaction
+
+The goal is bounded risk management before settlement, not an unbounded halt condition.
### Ingress traffic management
Networks can pair assertion validation with ingress-level caching and rate-limit policies for repeated invalid submissions.
-Common controls include exact invalid-transaction caching, broader short-lived fingerprints for repeated attempts against the same assertion and target surface, peer or sender budgets, and clear TTLs for any broad match.
+Common controls include exact invalid-transaction caching, broader short-lived fingerprints for repeated attempts against the same assertion and target contract or function, peer or sender budgets, and clear TTLs for any broad match. Exact matches can usually be blocked aggressively; broader fingerprints should use thresholds and short expiration windows to avoid suppressing legitimate traffic.
## Operational Expectations
- The enforcer runs alongside the block builder and does not change consensus rules
- Enforcement is deterministic and only depends on on-chain state and assertion code
- Protocol teams choose whether assertions are staged or enforced; networks honor the registry status during validation
+- Network operators define continuity behavior for maintenance windows, degraded dependencies, and validation timeouts
+- Production integrations keep assertion work bounded through admission review, trigger scoping, runtime limits, and operational monitoring
## Integration Checklist (High Level)
- Identify the block-building hook for transaction validation
- Configure access to registry data and assertion bytecode
- Ensure the enforcer respects staged vs enforced assertions as set by protocol teams
-- Define validation policy for L1-originated transactions and repeated invalid submissions
-- Set up monitoring and incident review workflows
+- Define validation policy for every supported transaction source
+- Define timeout, fallback, and bounded response-window behavior where applicable
+- Configure ingress controls for repeated invalid submissions
+- Set up monitoring and invalidation review workflows
## Integration Requirements (Public)
- **Block-building hook** that can query the enforcer before inclusion
+- **Transaction-source policy** that describes where validation runs for each supported path
- **Registry access** for assertion discovery (on-chain events indexed locally)
- **DA access** for assertion bytecode retrieval
-- **Incident visibility** through the Phylax platform
+- **Invalidation visibility** through the Phylax platform
## Next Steps
@@ -95,13 +117,13 @@ Common controls include exact invalid-transaction caching, broader short-lived f
Detailed system architecture and transaction flow
-
- Plugin-based integration pattern for Besu
-
Sidecar validation flow and enforcement role
-
- OP Stack integration notes
+
+ Guarantees, trust boundaries, and operational assumptions
+
+
+ Review transactions that violated assertions
diff --git a/credible/ownership-verification.mdx b/credible/ownership-verification.mdx
index 8df8ff9..901897c 100644
--- a/credible/ownership-verification.mdx
+++ b/credible/ownership-verification.mdx
@@ -6,7 +6,7 @@ description: 'Understand how the Credible Layer determines who is allowed to man
The Credible Layer uses admin verifier modules to determine who can deploy assertions for a contract. Most deployments use owner-based verification by default. This design will continue to expand with additional ownership patterns.
-This page explains the ownership model. If your contracts do not fit the default verifier and you need the process for getting approved, use [How to Request Manual Verification](./manual-verification).
+This page explains the ownership model. If your rollup contracts do not fit the default verifier and you need the process for getting approved, use [How to Request Manual Verification](./manual-verification). Manual verification is not available for Ethereum mainnet contracts.
## Current Implementation
@@ -27,7 +27,9 @@ Managing assertions is a sensitive role. We recommend using hardware wallets and
## Manual Verification (Overview)
-If your contracts are immutable or don't expose an admin interface, you may be able to request manual verification. In this path, Phylax validates that the requesting team controls the protocol and then registers a protocol admin (manager) address for the specific contracts in the State Oracle registry.
+If your contracts are deployed on a supported rollup and are immutable or don't expose an admin interface, you may be able to request manual verification. In this path, Phylax validates that the requesting team controls the protocol and then registers a protocol admin (manager) address for the specific contracts in the State Oracle registry.
+
+Manual verification is not available for Ethereum mainnet contracts because enforcement works differently on L1 and L2 blockchains.
High-level requirements and signals include:
- Demonstrated control over the protocol codebase (e.g., ability to merge to the official repo and manage collaborators)
diff --git a/credible/testing-strategy.mdx b/credible/testing-strategy.mdx
index 2c1206d..ba86633 100644
--- a/credible/testing-strategy.mdx
+++ b/credible/testing-strategy.mdx
@@ -114,7 +114,7 @@ Once local tests pass and backtesting shows no obvious issues, [deploy to stagin
### Monitor Staging Behavior
-Check the [platform dashboard](https://app.phylax.systems) regularly for assertion execution status and enable [incident notifications](/credible/dapp-integrations) to get alerted via Slack or PagerDuty. Look for:
+Check the [platform dashboard](https://app.phylax.systems) regularly for assertion execution status and enable [invalidation notifications](/credible/dapp-integrations) to get alerted via Slack or PagerDuty. Look for:
- Unexpected invalidations on legitimate operations
- Assertion behavior that needs tuning before production
@@ -164,7 +164,7 @@ Moving to production means assertion results can affect transaction inclusion ac
**Deploying directly to production:** Always validate in staging first. Production should only use assertions that have passed staging review.
-**Expecting immediate feedback:** Edge cases may take weeks to surface in staging. Be patient and let real usage patterns emerge.
+**Expecting immediate feedback:** Edge cases may take weeks to appear in staging. Be patient and let real usage patterns emerge.
## Next Steps
diff --git a/credible/trust-model.mdx b/credible/trust-model.mdx
index 23975e1..c730745 100644
--- a/credible/trust-model.mdx
+++ b/credible/trust-model.mdx
@@ -12,6 +12,8 @@ This page summarizes the Credible Layer trust model in plain language.
- **Pre-execution validation**: the enforcer reports assertion failures before block inclusion;
enforcing network integrations can exclude those transactions
- **Transparent rules**: assertions are public Solidity code and can be audited by anyone
+- **Observable outcomes**: invalidations, release activity, and project changes are recorded for project review and public reporting where appropriate
+- **Bounded execution**: production assertions are admitted with trigger scope and resource limits so enforcement remains predictable
## Scope of Guarantees
@@ -19,6 +21,7 @@ This page summarizes the Credible Layer trust model in plain language.
- **Protocol-authored rules**: protocol teams define and maintain the rules that protect their contracts
- **Integrated environments**: enforcement applies on networks and environments where the enforcer is integrated and the assertion is active
- **On-chain coordination**: the State Oracle contracts remain the source of truth for assertion lifecycle state and timelocks
+- **Documented transaction paths**: each integration must define how ordinary, bridge-originated, system-originated, delayed, or forced-inclusion-style paths are validated
## Operational Model
@@ -28,6 +31,30 @@ This page summarizes the Credible Layer trust model in plain language.
- Production assertions are admitted with bounded triggers and resource limits before they become part of the active execution set
- Network integrations define continuity behavior for maintenance windows and degraded components
+## Trust Boundaries
+
+The Credible Layer adds protocol-defined validation to an integrated network's transaction inclusion process. It does not remove the trust users already place in that network for ordering, liveness, and ordinary transaction validity.
+
+The main trust boundaries are:
+
+- Protocol teams are responsible for writing and maintaining assertions that express the risks they want to prevent
+- Project manager wallets control assertion releases, staging, production promotion, rollback, and collaborator access
+- Network operators are responsible for running the integration, honoring active registry state, and documenting timeout or degraded-component behavior
+- Assertion DA and local enforcer caches make assertion bytecode available before production execution; hot-path validation should not depend on live network fetches
+- Private invalidation payloads and traces are visible only to project members unless the project opts in to share them with support or network security teams
+
+## Failure and Continuity Policies
+
+Each production integration should define what happens when a dependency is unavailable, assertion workers fall behind, or validation cannot complete before the publication boundary. Those policies are integration-specific, but they should be explicit before production rollout.
+
+Useful policy questions include:
+
+- Does the integration fail open, fail closed, or apply a bounded fallback for a specific transaction source?
+- What timeout applies to assertion execution?
+- What happens to transactions that cannot be classified in time?
+- How are delayed, retried, released, or rejected transactions reported?
+- What rollback path exists if a production assertion creates false positives?
+
## Assurance Practices
Teams build confidence by validating assertions locally, backtesting against historical transactions, running assertions in staging, and promoting to production only after sufficient review. See [How to Plan Assertion Testing](/credible/testing-strategy) for the recommended workflow.
diff --git a/docs.json b/docs.json
index 8963bbd..0c47dc0 100644
--- a/docs.json
+++ b/docs.json
@@ -13,6 +13,14 @@
"source": "/credible/store-submit-assertions",
"destination": "/credible/apply-assertions"
},
+ {
+ "source": "/credible/dapp-transparency-dashboard",
+ "destination": "/credible/dapp-explorer"
+ },
+ {
+ "source": "/credible/dapp-incidents",
+ "destination": "/credible/dapp-invalidations"
+ },
{
"source": "/credible/accelerate-with-ai",
"destination": "/credible/agentic-pcl"
@@ -132,9 +140,10 @@
"group": "Platform",
"pages": [
"credible/dapp-overview",
- "credible/dapp-transparency-dashboard",
+ "credible/dapp-explorer",
+ "credible/explorer-security-posture",
"credible/dapp-projects",
- "credible/dapp-incidents",
+ "credible/dapp-invalidations",
"credible/faq"
]
},
@@ -200,6 +209,8 @@
"group": "Hack Case Studies",
"pages": [
"assertions-book/previous-hacks/prev-hacks-index",
+ "assertions-book/previous-hacks/kelpdao-rseth-layerzero-configuration",
+ "assertions-book/previous-hacks/drift-security-council-takeover",
"assertions-book/previous-hacks/balancer-v2-stable-rate-exploit",
"assertions-book/previous-hacks/bybit-safe-ui",
"assertions-book/previous-hacks/gma-aum-jul25-hack",
diff --git a/images/all-invalidations.png b/images/all-invalidations.png
new file mode 100644
index 0000000..b9cf907
Binary files /dev/null and b/images/all-invalidations.png differ
diff --git a/images/invalidation-event.png b/images/invalidation-event.png
new file mode 100644
index 0000000..636af02
Binary files /dev/null and b/images/invalidation-event.png differ
diff --git a/images/invalidations.mp4 b/images/invalidations.mp4
new file mode 100644
index 0000000..0239623
Binary files /dev/null and b/images/invalidations.mp4 differ
diff --git a/images/lagoon-op-risk.mp4 b/images/lagoon-op-risk.mp4
new file mode 100644
index 0000000..406c435
Binary files /dev/null and b/images/lagoon-op-risk.mp4 differ
diff --git a/images/phylax-explorer-projects.png b/images/phylax-explorer-projects.png
new file mode 100644
index 0000000..300fece
Binary files /dev/null and b/images/phylax-explorer-projects.png differ
diff --git a/images/phylax-operational-risk.mp4 b/images/phylax-operational-risk.mp4
new file mode 100644
index 0000000..9bd2650
Binary files /dev/null and b/images/phylax-operational-risk.mp4 differ
diff --git a/images/phylax-project-overview.png b/images/phylax-project-overview.png
new file mode 100644
index 0000000..9b02a7c
Binary files /dev/null and b/images/phylax-project-overview.png differ
diff --git a/images/release-review-backtesting.png b/images/release-review-backtesting.png
new file mode 100644
index 0000000..6f74c7d
Binary files /dev/null and b/images/release-review-backtesting.png differ
diff --git a/images/release-review-overview.png b/images/release-review-overview.png
new file mode 100644
index 0000000..d50b84b
Binary files /dev/null and b/images/release-review-overview.png differ
diff --git a/images/release-review-verification.png b/images/release-review-verification.png
new file mode 100644
index 0000000..5e74f9c
Binary files /dev/null and b/images/release-review-verification.png differ
diff --git a/images/release-review.mp4 b/images/release-review.mp4
new file mode 100644
index 0000000..268031a
Binary files /dev/null and b/images/release-review.mp4 differ
-
-
-
-### Incidents
-
-The incidents list shows recent incidents for the project, ordered by most recent.
-
-Each row includes:
-
-- **Timestamp**
-- **Contract Affected**
-- **Assertion Triggered**
-- **Invalid Transactions** count
-- **Environment** (staging or production)
-
-Click a row to open the incident detail view.
-
-
- 
-
-
-### Incident Detail and Invalidating Transactions
-
-The incident detail page summarizes the incident and lists invalidating transactions.
-It includes:
-
-- **Incident detail card** with date, contract affected, assertion triggered, assertion group, invalid transaction count, and environment
-- **Critical warning banner** if any invalidating transaction landed on-chain
-- **Invalid Transactions** list with expandable rows and action buttons
-
-Each invalidating transaction includes:
-
-- Transaction hash, to/from, value, calldata, and block number (if available)
-- **Open Debug View** to inspect the trace
-- **Copy Data as JSON** to export the transaction
-
-
- 
-
-
-### Debug Trace View
-
-The debug trace view opens from an invalidating transaction.
-
-- Route: `/projects/{project_id}/trace/{incident_id}/{transaction_id}`
-- **Transaction Attributes** panel with copy-all action
-- **Execution Context** panel (block environment + previous transactions)
-- **Transaction Trace** panel with status: pending, in progress, completed, failed, or skipped
-
-
- 
-
-
-
- 
-
-
-### Real-Time Updates and Alerts
-
-When a project manager is viewing the incidents list, new incidents stream into the list in real time.
-You can also set up external alerts via webhooks:
-
-- **Slack Integration**: Configure Slack webhooks to receive incident notifications
-- **PagerDuty Integration**: Configure PagerDuty webhooks to receive incident notifications
-
-See [Integrations](/credible/dapp-integrations) for setup instructions.
-
-## Public Transparency Incidents
-
-The public explorer includes a limited invalidations view for transparency. Detailed transaction payloads, traces, and project-specific incident evidence are only available to project managers and collaborators with access.
-
-Detailed invalidation evidence is scoped to the project team so they can triage with full payloads and traces while public views remain concise.
-
-### Staging vs. Production
-
-| Environment | What an invalidation means | User impact |
-| --- | --- | --- |
-| Staging | The transaction would have violated an assertion under production enforcement | The transaction is recorded for review but is not dropped |
-| Production | The transaction violated an enforced assertion | The transaction is dropped before settlement |
-
-## Use Cases
-
-- Monitor when assertions prevent violations for your projects
-- Review attempted invalid transactions targeting your protocol
-- Tune assertions based on staging invalidations before production promotion
-- Add or refine assertions based on incident data
-
-
+
+
+### Invalidation event
+
+The invalidation event page summarizes the event and lists its invalidating transactions.
+
+Event details include:
+
+- **Date occurred**
+- **Invalidation ID**
+- **Public Ref ID**, when available
+- **Assertion affected**
+- **Contract affected**
+- **Environment**
+
+The **Invalid Transactions** table lists the date, transaction hash, sender, and recipient for each transaction in the event. Select a transaction to open its replay.
+
+
+ 
+
+
+### Invalidating transaction replay
+
+The transaction replay explains what the transaction attempted, how the protocol call executed, and why the assertion rejected it.
+
+The replay includes:
+
+- **Replay overview**: transaction status, hash, sender, recipient, transaction type, nonce, gas, and network
+- **Assertion result**: assertion name, selector, adopter, and revert reason
+- **What changed**: confirmed token, vault, Safe, and administrative events shown in execution order
+- **Execution evidence**: separate views of transaction execution and assertion evaluation
+- **Developer data**: raw transaction and assertion traces, including hidden internal calls when expanded
+- **Execution context**: block state, prior transactions, and block environment used for the replay
+
+The replay shows two separate results:
+
+1. **Transaction execution:** Did the protocol call run successfully?
+2. **Assertion evaluation:** Did the resulting state satisfy the assertion?
+
+A call can pass the first check and fail the second. In that case, the assertion rejects the transaction.
+
+
+
+
+
+### Real-time updates and alerts
+
+Project teams can configure external notifications:
+
+- **Slack**: receive invalidation notifications through a Slack integration
+- **PagerDuty**: send invalidation notifications to an incident-response workflow
+
+Invalidation alerts can represent an active exploit attempt, a false positive affecting legitimate protocol activity, or an assertion that needs tuning. See [Integrations](/credible/dapp-integrations) for setup instructions.
+
+## Invalidations in The Phylax Explorer
+
+The Phylax Explorer can show redacted aggregate invalidation history, such as a reference ID and timestamp, when that data is public. Full transaction payloads, replay evidence, traces, staging records, notification settings, and project-specific evidence remain available only to project managers and approved collaborators.
+
+## Staging vs. production
+
+| Environment | What an invalidation means | User impact |
+| --- | --- | --- |
+| Staging | The transaction would have violated an assertion under production enforcement | The transaction is recorded for review but is not rejected |
+| Production | The transaction violated an enforced assertion | The transaction is rejected before settlement on enforced paths, or handled according to the documented integration policy |
+
+## Use cases
+
+- Monitor assertion violations across production and staging
+- Review the state change and assertion result for an invalidating transaction
+- Inspect transaction execution, assertion evaluation, traces, and replay context
+- Tune assertions using staging evidence before production promotion
+
+
+
-The [Incidents](/credible/dapp-incidents) page tracks invalidations: transactions that violated assertions in production, or would have violated assertions in staging. Production invalidations correspond to transactions that were dropped before settlement. Staging invalidations are observe-only records that help teams tune assertions before promotion.
+### Invalidations
-
- 
-
+The [Invalidations](/credible/dapp-invalidations) page tracks transactions that violated assertions in production, or would have violated assertions in staging. Production invalidations correspond to transactions that were dropped before settlement. Staging invalidations are observe-only records that help teams tune assertions before promotion.
## Authentication
@@ -37,17 +52,24 @@ Authentication is required to create and manage projects. Open the platform at [
## Key Features
-- **Public transparency**: Browse public projects, protected contracts, and assertion posture
+- **Public project review**: Browse public projects, protected contracts, and assertion posture
+- **Protection summaries**: Review release-generated summaries of protected actions, circuit breakers, assertion behavior, and failure modes
+- **Operational risk cards**: Inspect verifiable properties such as admin roles, signer thresholds, timelocks, role segregation, and upgradeability when available
+- **Deployed-vs-audited code context**: See whether current deployed implementation code appears to differ from the most recent known audited code when metadata is available
+- **Evidence links**: Review project-provided GitHub, audit, and formal verification links
- **Release review**: Inspect assertion changes before signing on-chain deployment transactions
- **Unified management**: Manage assertion releases, project metadata, and notification settings from one interface
- **Invalidation monitoring**: Track assertion failures in staging and production
-- **Verifiable security**: Users can verify protection before interacting with protocols
+- **Verifiable posture**: Users can review protection before interacting with protocols
## Getting Started
+
+ 
-For detailed instructions on deploying assertions, see the [Deploy Assertions guide](/credible/deploy-assertions-dapp#step-4-deploy-the-assertion).
+
+ 
+
+
+
+ 
+
+
+For detailed instructions, see the [Deploy Assertions guide](/credible/deploy-assertions-dapp#step-4-deploy-the-assertion).
### Project Settings
@@ -84,14 +91,14 @@ Here you can update the project name, description, and delete the project.
You can transfer projects and contracts (including their associated assertions) to other wallets. This allows you to transfer project ownership while maintaining all linked assertions and contracts.
**Protocol admin / manager wallet:**
-The wallet that signs assertion lifecycle transactions can be separate from the day-to-day platform account. Use this separation when your team wants project collaborators to review releases and incidents without requiring routine access to the multisig or governance wallet that controls deployment.
+The wallet that signs assertion lifecycle transactions can be separate from the day-to-day platform account. Use this separation when your team wants project collaborators to review releases and invalidations without requiring routine access to the multisig or governance wallet that controls deployment.
**Access controls:**
Admins can invite collaborators by email or wallet address. Use roles to separate review work from deployment authority:
| Role | Typical permissions |
| --- | --- |
-| Viewer | View incidents and project information without making changes |
+| Viewer | View invalidations and project information without making changes |
| Editor | Create releases and configure notifications |
| Admin | Manage members, settings, and the protocol manager wallet |
@@ -99,26 +106,40 @@ Admins can invite collaborators by email or wallet address. Use roles to separat
Detailed invalidation evidence is scoped to project members. Admins can opt in to share invalidations or transactions dropped by the node operator with Phylax support and network teams for customer support and debugging.
**Integrations:**
-Set up integrations to receive notifications when incidents occur, including Slack and PagerDuty where available.
+Set up integrations to receive notifications when invalidations occur, including Slack and PagerDuty where available.
+### Security Evidence Links
+
+Protocol teams can keep project evidence up to date so The Phylax Explorer can show a more complete public project page.
+
+Useful evidence includes:
+
+- public repository links
+- audit report links
+- audit scope or commit references, where available
+- formal verification links, where applicable
+- protected-contract labels
+- assertion names and descriptions
+
+This metadata helps reviewers understand what is protected, which code was reviewed, and whether deployed code appears to match known audited code.
+
## Project Dashboard
The project dashboard provides a unified view of your project's security:
-- **Active Assertions**: See all assertions currently protecting your contracts
-- **Assertion Deployment**: Deploy or remove assertions for your project
-- **Ready for Deployment**: Assertions submitted via `pcl` that need to be linked and deployed
-- **Assertion Status**: Monitor execution status and any triggered violations. Status shows whether assertions are marked for enforcement/staging or enforced/staged
-- **Recent Incidents**: View detailed incidents for your project (see [Incidents](/credible/dapp-incidents#project-incidents-manager-view))
-- **Audit Log**: Review project changes, assertion lifecycle events, collaborator changes, release activity, and invalidations over time
-- **Project Settings**: Update project details and manage contracts
+- **Assertions**: View active and pending assertions
+- **Releases**: Review and deploy changes
+- **Operational Risk**: Review authority and change paths
+- **Evidence**: Review audits and deployed-code context
+- **Invalidations**: Inspect assertion violations
+- **Audit Log and Settings**: Review activity and manage the project
- 
+ 
### Audit Log
@@ -133,7 +154,7 @@ Audit log entries can include:
- Production and staging release events
- Protocol manager changes
- Collaborator role changes
-- Invalidations and incident-related activity
+- Invalidation-related activity
diff --git a/credible/dapp-transparency-dashboard.mdx b/credible/dapp-transparency-dashboard.mdx
deleted file mode 100644
index 4ca39a4..0000000
--- a/credible/dapp-transparency-dashboard.mdx
+++ /dev/null
@@ -1,90 +0,0 @@
----
-title: 'Transparency Dashboard'
-description: 'Browse and analyze public projects and their active assertions'
----
-
-The Transparency Dashboard is a public interface that displays projects registered on the Credible Layer, their linked contracts, and the assertions protecting them.
-
-