Update backtesting

assertions-book/assertions/aave-v3-suite.mdx

@@ -23,7 +23,7 @@ We have mocked parts of the protocol in order to properly test the assertions an
 
 The Aave V3 assertion suite has been tested quite thoroughly given the early stage of the Credible Layer testing capabilities. We feel confident that the production assertions could be added to an Aave V3 deployment and add value to the security and robustness of the protocol.
 
-We recommend running the assertions in a test environment against historical transactions to validate behavior before production promotion. This is standard best practice for protocol upgrades and does not just apply to assertions.
+Before production promotion, create a release in the Phylax platform and review its automatic backtesting result. The platform tests the release against transactions from the last 20,000 blocks so you can identify benign activity that the assertion would have invalidated. See [How to Review Backtesting Results](/credible/backtesting).
 
 ## Here Be Dragons 🐲
 

assertions-book/previous-hacks/balancer-v2-stable-rate-exploit.mdx

@@ -183,94 +183,11 @@ We chose **3x (300%)** as the threshold based on the following analysis:
 **Disclaimer:** This assertion is conceptual. Based on our analysis of the protocol mechanics, we have not discovered any legitimate operations that would cause rate changes exceeding 3x in a single transaction. However, we cannot guarantee that such edge cases do not exist.
 Thorough testing and analysis of real-world scenarios and edge cases is required before using this assertion in production.
 
-## Backtesting Results
+## Review the release backtest
 
-We have built a custom backtesting framework that allows for running assertions against real-world historical transactions.
+After adding this assertion to a project, create a release with `pcl apply`. The platform automatically tests the release against transactions from the last 20,000 blocks. Review every finding to confirm whether the assertion detected behavior you intend to prevent or would block a benign operation.
 
-This tool is excellent for testing assertions we develop against known exploits and it's also what we used to verify the assertion's accuracy.
-
-We backtested the assertion against the actual exploit transaction on Ethereum mainnet:
-
-```bash
-FOUNDRY_PROFILE=assertions pcl test --match-contract BatchSwapBacktest --ffi -vvv
-```
-
-### Test Configuration
-
-```solidity
-contract BatchSwapBacktest is CredibleTestWithBacktesting {
-    address constant BALANCERV2_VAULT = 0xBA12222222228d8Ba445958a75a0704d566BF2C8;
-    uint256 constant END_BLOCK = 23717632;  // Mainnet exploit block
-    uint256 constant BLOCK_RANGE = 1;
-
-    function testBacktest_Balancer_BatchSwapOperations() public {
-        executeBacktest({
-            targetContract: BALANCERV2_VAULT,
-            endBlock: END_BLOCK,
-            blockRange: BLOCK_RANGE,
-            assertionCreationCode: type(BatchSwapDeltaAssertion).creationCode,
-            assertionSelector: BatchSwapDeltaAssertion.assertionBatchSwapRateManipulation.selector,
-            rpcUrl: vm.envString("MAINNET_RPC_URL")
-        });
-    }
-}
-```
-
-### Results
-
-```text
-==========================================
-         BACKTESTING CONFIGURATION
-==========================================
-Target Contract: 0xba12222222228d8ba445958a75a0704d566bf2c8
-Block Range: 23717632 to 23717632
-Assertion Selector: 0x5f3ce91c
-==========================================
-
-Total transactions found: 3
-
-=== TRANSACTION 1 ===
-Hash: 0x3e173ab0ba9183efa8a42caa783bdb5ec75daffcc8505cc1302009d11daf1ccf
-Function: 0x60e087db
----
-Transaction gas cost: 14297996
-Assertion gas cost: 299665
-
-Assertion function reverted: BatchSwap: Extreme pool rate manipulation detected
-[ASSERTION_FAIL] VALIDATION FAILED
----
-
-=== TRANSACTION 2 ===
-Hash: 0x6341ec5db92cab0cfd8c17bffab7b7194a591e20de8d14e6f5c5f0d338627a35
----
-[SKIP] Assertion not triggered on this transaction
----
-
-=== TRANSACTION 3 ===
-Hash: 0xac5837a3b4c17893725c0155b6c0ee24590b1e504487400a7aa4bd927606b24c
----
-[SKIP] Assertion not triggered on this transaction
----
-
-==========================================
-           BACKTESTING SUMMARY
-==========================================
-Block Range: 23717632 - 23717632
-Total Transactions: 3
-Processed Transactions: 3
-Successful Validations: 2
-Failed Validations: 1
-
-=== ERROR BREAKDOWN ===
-Protocol Violations (Assertion Failures): 1
-Unknown Errors: 0
-
-Success Rate: 66%
-!!! PROTOCOL VIOLATIONS DETECTED: 1
-================================
-```
-
-**Result:** The assertion detected the exploit transaction, demonstrating how invariant-based protection can catch complex attacks, without requiring knowledge of the specific exploit mechanism.
+The platform window moves with the chain, so an older exploit transaction may fall outside the release backtest. Keep a focused regression test for the known exploit and use the platform result to evaluate the release against recent protocol activity. See [How to Review Backtesting Results](/credible/backtesting) for the review workflow.
 
 ## Key Takeaways
 

credible/agentic-pcl.mdx

@@ -44,7 +44,7 @@ npx github:phylaxsystems/agent-skills#851cd274972efa6047393eaa61a935ed56f66b3b i
 
 The commit pin ensures that both commands install the reviewed skill versions shown in this guide.
 
-The [agent-skills repository](https://github.com/phylaxsystems/agent-skills) also includes focused skills for invariant design, assertion implementation, testing, backtesting, trigger optimization, and troubleshooting.
+The [agent-skills repository](https://github.com/phylaxsystems/agent-skills) also includes focused skills for invariant design, assertion implementation, testing, trigger optimization, and troubleshooting.
 
 <Note>
 Restart your agent after installation if it does not discover the new skills in the current session.

credible/apply-assertions.mdx

@@ -108,11 +108,12 @@ pcl apply --yes
 After applying, complete deployment in the [Phylax platform](https://app.phylax.systems) using the [Deploy Assertions guide](/credible/deploy-assertions-dapp#step-4-deploy-the-assertion):
 
 1. Navigate to your project
-2. Click "Deployment" tab
-3. Find your assertion and click "Proceed to Review"
+2. Select **Releases**
+3. Choose the release created by `pcl apply`
 4. Review the release diff and selected target contracts
-5. Select the target environment (Staging or Production)
-6. Click "Deploy" and sign the transaction
+5. Review **Assertion verification**, **Source code**, and **Backtesting**. See [Release Review Checks](./release-review-checks) for details.
+6. Confirm the target environment declared in `credible.toml`
+7. Connect the protocol manager wallet, select **Deploy to Staging** or **Deploy to Production**, and sign the transaction
 
 <Note>
 Creating a release through `pcl apply` does not make the assertion active by itself. The release is pending until an authorized protocol admin, also called a manager, signs the deployment transaction in the platform. The assertion becomes active only after that transaction is accepted on-chain and the configured timelock in the State Oracle contracts expires. Removals follow the same State Oracle timelock flow.

credible/assertion-enforcer.mdx

@@ -141,7 +141,7 @@ Production assertion admission should account for:
 - Maximum gas or runtime budget
 - Expected read footprint
 - Deterministic behavior and read-only execution
-- Historical backtesting and staging behavior
+- Platform release-backtesting and staging behavior
 - Suitability for common acceleration paths, such as compact trace summaries or native helper functions
 
 These controls keep block-building resources predictable and help protocol teams understand which assertions are ready to promote from staging to production.
@@ -157,7 +157,7 @@ Common controls include:
 - 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
+- Staging and platform release-review 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.