From a35504d009bc7983a90c1602974bb9bc27d45a35 Mon Sep 17 00:00:00 2001 From: Karim <98668332+khadni@users.noreply.github.com> Date: Wed, 12 Nov 2025 19:04:29 -0500 Subject: [PATCH 1/2] MockForwarder override clarifications --- reports/llms-report.json | 16 ++++++++-------- .../building-consumer-contracts.mdx | 14 +++++++++++++- src/content/cre/llms-full-go.txt | 14 +++++++++++++- src/content/cre/llms-full-ts.txt | 14 +++++++++++++- 4 files changed, 47 insertions(+), 11 deletions(-) diff --git a/reports/llms-report.json b/reports/llms-report.json index cf5c37be556..fed29399ffd 100644 --- a/reports/llms-report.json +++ b/reports/llms-report.json @@ -1,22 +1,22 @@ { - "startedAt": "2025-11-12T18:56:10.721Z", + "startedAt": "2025-11-13T00:04:05.799Z", "siteBase": "https://docs.chain.link", "sections": [ { "section": "cre-go", "pagesProcessed": 84, "outputPath": "src/content/cre/llms-full-go.txt", - "bytes": 631240, + "bytes": 631974, "prevBytes": 631240, - "deltaBytes": 0 + "deltaBytes": 734 }, { "section": "cre-ts", "pagesProcessed": 79, "outputPath": "src/content/cre/llms-full-ts.txt", - "bytes": 586661, + "bytes": 587395, "prevBytes": 586661, - "deltaBytes": 0 + "deltaBytes": 734 }, { "section": "vrf", @@ -31,8 +31,8 @@ "pagesProcessed": 243, "outputPath": "src/content/ccip/llms-full.txt", "bytes": 2625022, - "prevBytes": 2639701, - "deltaBytes": -14679 + "prevBytes": 2625022, + "deltaBytes": 0 }, { "section": "data-feeds", @@ -123,5 +123,5 @@ "deltaBytes": 0 } ], - "finishedAt": "2025-11-12T18:56:14.180Z" + "finishedAt": "2025-11-13T00:04:10.542Z" } diff --git a/src/content/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts.mdx b/src/content/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts.mdx index 6a3e505cec9..a88e6d8afa4 100644 --- a/src/content/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts.mdx +++ b/src/content/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts.mdx @@ -65,6 +65,11 @@ While you can implement these standards manually, we provide an abstract contrac - **ERC165 Support**: Includes the necessary `supportsInterface` function - **Metadata Access**: Helper function to decode workflow ID, name, and owner for custom validation logic +{/* prettier-ignore */} + + ### 3.2 Contract Source Code ```solidity @@ -325,6 +330,11 @@ contract MetadataAwareConsumer is IReceiverTemplate { ### 4.3 Working with Simulation +{/* prettier-ignore */} + + When you run `cre workflow simulate`, your workflow interacts with a **`MockForwarder`** contract that does not provide the `workflow_name` or `workflow_owner` metadata. This means consumer contracts with `IReceiverTemplate`'s default validation **will fail during simulation**. **To test your consumer contract with simulation:** @@ -332,6 +342,8 @@ When you run `cre workflow simulate`, your workflow interacts with a **`MockForw Override the `onReport` function to bypass validation checks: ```solidity +// Temporary: For simulation only +// Re-enable validation for production deployment function onReport(bytes calldata, bytes calldata report) external override { _processReport(report); // Skips validation checks } @@ -339,7 +351,7 @@ function onReport(bytes calldata, bytes calldata report) external override { **For deployed workflows:** -Deployed workflows use the real **`KeystoneForwarder`** contract, which provides full metadata. You can enable all permission checks (forwarder address, workflow ID, owner, name) for production deployments. +Deployed workflows use the real **`KeystoneForwarder`** contract, which provides full metadata. Remove this override and enable permission checks for production deployments. See [Configuring Security](#34-configuring-security) for details. ## 5. Complete Examples diff --git a/src/content/cre/llms-full-go.txt b/src/content/cre/llms-full-go.txt index f29069f7526..7f780166219 100644 --- a/src/content/cre/llms-full-go.txt +++ b/src/content/cre/llms-full-go.txt @@ -2382,6 +2382,11 @@ While you can implement these standards manually, we provide an abstract contrac - **ERC165 Support**: Includes the necessary `supportsInterface` function - **Metadata Access**: Helper function to decode workflow ID, name, and owner for custom validation logic + + + ### 3.2 Contract Source Code ```solidity @@ -2642,6 +2647,11 @@ contract MetadataAwareConsumer is IReceiverTemplate { ### 4.3 Working with Simulation + + + When you run `cre workflow simulate`, your workflow interacts with a **`MockForwarder`** contract that does not provide the `workflow_name` or `workflow_owner` metadata. This means consumer contracts with `IReceiverTemplate`'s default validation **will fail during simulation**. **To test your consumer contract with simulation:** @@ -2649,6 +2659,8 @@ When you run `cre workflow simulate`, your workflow interacts with a **`MockForw Override the `onReport` function to bypass validation checks: ```solidity +// Temporary: For simulation only +// Re-enable validation for production deployment function onReport(bytes calldata, bytes calldata report) external override { _processReport(report); // Skips validation checks } @@ -2656,7 +2668,7 @@ function onReport(bytes calldata, bytes calldata report) external override { **For deployed workflows:** -Deployed workflows use the real **`KeystoneForwarder`** contract, which provides full metadata. You can enable all permission checks (forwarder address, workflow ID, owner, name) for production deployments. +Deployed workflows use the real **`KeystoneForwarder`** contract, which provides full metadata. Remove this override and enable permission checks for production deployments. See [Configuring Security](#34-configuring-security) for details. ## 5. Complete Examples diff --git a/src/content/cre/llms-full-ts.txt b/src/content/cre/llms-full-ts.txt index 24a61344ecb..78909c1b5e3 100644 --- a/src/content/cre/llms-full-ts.txt +++ b/src/content/cre/llms-full-ts.txt @@ -1971,6 +1971,11 @@ While you can implement these standards manually, we provide an abstract contrac - **ERC165 Support**: Includes the necessary `supportsInterface` function - **Metadata Access**: Helper function to decode workflow ID, name, and owner for custom validation logic + + + ### 3.2 Contract Source Code ```solidity @@ -2231,6 +2236,11 @@ contract MetadataAwareConsumer is IReceiverTemplate { ### 4.3 Working with Simulation + + + When you run `cre workflow simulate`, your workflow interacts with a **`MockForwarder`** contract that does not provide the `workflow_name` or `workflow_owner` metadata. This means consumer contracts with `IReceiverTemplate`'s default validation **will fail during simulation**. **To test your consumer contract with simulation:** @@ -2238,6 +2248,8 @@ When you run `cre workflow simulate`, your workflow interacts with a **`MockForw Override the `onReport` function to bypass validation checks: ```solidity +// Temporary: For simulation only +// Re-enable validation for production deployment function onReport(bytes calldata, bytes calldata report) external override { _processReport(report); // Skips validation checks } @@ -2245,7 +2257,7 @@ function onReport(bytes calldata, bytes calldata report) external override { **For deployed workflows:** -Deployed workflows use the real **`KeystoneForwarder`** contract, which provides full metadata. You can enable all permission checks (forwarder address, workflow ID, owner, name) for production deployments. +Deployed workflows use the real **`KeystoneForwarder`** contract, which provides full metadata. Remove this override and enable permission checks for production deployments. See [Configuring Security](#34-configuring-security) for details. ## 5. Complete Examples From ad0bfeea8a07d83c4256477d6f927041732aadd3 Mon Sep 17 00:00:00 2001 From: Karim <98668332+khadni@users.noreply.github.com> Date: Thu, 13 Nov 2025 08:45:52 -0500 Subject: [PATCH 2/2] clarifications --- reports/llms-report.json | 16 +-- .../building-consumer-contracts.mdx | 103 ++++++++++------- .../supported-networks-go.mdx | 2 +- .../supported-networks-ts.mdx | 2 +- src/content/cre/llms-full-go.txt | 105 +++++++++++------- src/content/cre/llms-full-ts.txt | 105 +++++++++++------- 6 files changed, 198 insertions(+), 135 deletions(-) diff --git a/reports/llms-report.json b/reports/llms-report.json index fed29399ffd..be640ba90ba 100644 --- a/reports/llms-report.json +++ b/reports/llms-report.json @@ -1,22 +1,22 @@ { - "startedAt": "2025-11-13T00:04:05.799Z", + "startedAt": "2025-11-13T13:44:50.973Z", "siteBase": "https://docs.chain.link", "sections": [ { "section": "cre-go", "pagesProcessed": 84, "outputPath": "src/content/cre/llms-full-go.txt", - "bytes": 631974, - "prevBytes": 631240, - "deltaBytes": 734 + "bytes": 632740, + "prevBytes": 631974, + "deltaBytes": 766 }, { "section": "cre-ts", "pagesProcessed": 79, "outputPath": "src/content/cre/llms-full-ts.txt", - "bytes": 587395, - "prevBytes": 586661, - "deltaBytes": 734 + "bytes": 588161, + "prevBytes": 587395, + "deltaBytes": 766 }, { "section": "vrf", @@ -123,5 +123,5 @@ "deltaBytes": 0 } ], - "finishedAt": "2025-11-13T00:04:10.542Z" + "finishedAt": "2025-11-13T13:44:55.838Z" } diff --git a/src/content/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts.mdx b/src/content/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts.mdx index a88e6d8afa4..d8bb99d656a 100644 --- a/src/content/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts.mdx +++ b/src/content/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts.mdx @@ -19,8 +19,9 @@ This guide explains how to build a consumer contract that can securely receive a - [Core Concepts: The Onchain Data Flow](#1-core-concepts-the-onchain-data-flow) - [The IReceiver Standard](#2-the-ireceiver-standard) - [Using IReceiverTemplate](#3-using-ireceivertemplate) -- [Advanced Usage](#4-advanced-usage-optional) -- [Complete Examples](#5-complete-examples) +- [Working with Simulation](#4-working-with-simulation) +- [Advanced Usage](#5-advanced-usage-optional) +- [Complete Examples](#6-complete-examples) ## 1. Core Concepts: The Onchain Data Flow @@ -65,11 +66,6 @@ While you can implement these standards manually, we provide an abstract contrac - **ERC165 Support**: Includes the necessary `supportsInterface` function - **Metadata Access**: Helper function to decode workflow ID, name, and owner for custom validation logic -{/* prettier-ignore */} - - ### 3.2 Contract Source Code ```solidity @@ -186,8 +182,6 @@ abstract contract IReceiverTemplate is IReceiver, Ownable { ### 3.3 Quick Start -**Step 1: Inherit and implement your business logic** - The simplest way to use `IReceiverTemplate` is to inherit from it and implement the `_processReport` function: ```solidity @@ -211,12 +205,15 @@ contract MyConsumer is IReceiverTemplate { } ``` -### 3.4 Configuring Security - -**Step 2: Configure permissions (optional)** +### 3.4 Configuring Permissions After deploying your contract, the owner can enable any combination of security checks using the setter functions. +{/* prettier-ignore */} + + {/* prettier-ignore */} -### 4.3 Working with Simulation - -{/* prettier-ignore */} - - -When you run `cre workflow simulate`, your workflow interacts with a **`MockForwarder`** contract that does not provide the `workflow_name` or `workflow_owner` metadata. This means consumer contracts with `IReceiverTemplate`'s default validation **will fail during simulation**. - -**To test your consumer contract with simulation:** - -Override the `onReport` function to bypass validation checks: - -```solidity -// Temporary: For simulation only -// Re-enable validation for production deployment -function onReport(bytes calldata, bytes calldata report) external override { - _processReport(report); // Skips validation checks -} -``` - -**For deployed workflows:** - -Deployed workflows use the real **`KeystoneForwarder`** contract, which provides full metadata. Remove this override and enable permission checks for production deployments. See [Configuring Security](#34-configuring-security) for details. - -## 5. Complete Examples +## 6. Complete Examples ### Example 1: Simple Consumer Contract diff --git a/src/content/cre/guides/workflow/using-evm-client/supported-networks-go.mdx b/src/content/cre/guides/workflow/using-evm-client/supported-networks-go.mdx index 383ebe28eb7..d6f9c359465 100644 --- a/src/content/cre/guides/workflow/using-evm-client/supported-networks-go.mdx +++ b/src/content/cre/guides/workflow/using-evm-client/supported-networks-go.mdx @@ -33,7 +33,7 @@ CRE workflows support EVM read and write operations on the following blockchain Learn more: [Onchain Write Overview](/cre/guides/workflow/using-evm-client/onchain-write/overview) -**Permissioning with the Forwarder address**: You can optionally use the forwarder address to add an extra security layer to your consumer contracts by restricting the `onReport()` function to only accept calls from the trusted forwarder. See [Permissioning by Forwarder Address](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts#permissioning-by-forwarder-address) for implementation details. +**Permissioning with the Forwarder address**: You can optionally use the forwarder address to add an extra security layer to your consumer contracts by restricting the `onReport()` function to only accept calls from the trusted forwarder. See [Configuring Permissions](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts#34-configuring-permissions) for implementation details. diff --git a/src/content/cre/guides/workflow/using-evm-client/supported-networks-ts.mdx b/src/content/cre/guides/workflow/using-evm-client/supported-networks-ts.mdx index d8299d7b718..222c3dbc16c 100644 --- a/src/content/cre/guides/workflow/using-evm-client/supported-networks-ts.mdx +++ b/src/content/cre/guides/workflow/using-evm-client/supported-networks-ts.mdx @@ -33,7 +33,7 @@ CRE workflows support EVM read and write operations on the following blockchain Learn more: [Onchain Write Overview](/cre/guides/workflow/using-evm-client/onchain-write/overview) -**Permissioning with the Forwarder address**: You can optionally use the forwarder address to add an extra security layer to your consumer contracts by restricting the `onReport()` function to only accept calls from the trusted forwarder. See [Permissioning by Forwarder Address](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts#permissioning-by-forwarder-address) for implementation details. +**Permissioning with the Forwarder address**: You can optionally use the forwarder address to add an extra security layer to your consumer contracts by restricting the `onReport()` function to only accept calls from the trusted forwarder. See [Configuring Permissions](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts#34-configuring-permissions) for implementation details. diff --git a/src/content/cre/llms-full-go.txt b/src/content/cre/llms-full-go.txt index 7f780166219..0f345443742 100644 --- a/src/content/cre/llms-full-go.txt +++ b/src/content/cre/llms-full-go.txt @@ -2336,8 +2336,9 @@ This guide explains how to build a consumer contract that can securely receive a - [Core Concepts: The Onchain Data Flow](#1-core-concepts-the-onchain-data-flow) - [The IReceiver Standard](#2-the-ireceiver-standard) - [Using IReceiverTemplate](#3-using-ireceivertemplate) -- [Advanced Usage](#4-advanced-usage-optional) -- [Complete Examples](#5-complete-examples) +- [Working with Simulation](#4-working-with-simulation) +- [Advanced Usage](#5-advanced-usage-optional) +- [Complete Examples](#6-complete-examples) ## 1. Core Concepts: The Onchain Data Flow @@ -2382,11 +2383,6 @@ While you can implement these standards manually, we provide an abstract contrac - **ERC165 Support**: Includes the necessary `supportsInterface` function - **Metadata Access**: Helper function to decode workflow ID, name, and owner for custom validation logic - - - ### 3.2 Contract Source Code ```solidity @@ -2503,8 +2499,6 @@ abstract contract IReceiverTemplate is IReceiver, Ownable { ### 3.3 Quick Start -**Step 1: Inherit and implement your business logic** - The simplest way to use `IReceiverTemplate` is to inherit from it and implement the `_processReport` function: ```solidity @@ -2528,13 +2522,16 @@ contract MyConsumer is IReceiverTemplate { } ``` -### 3.4 Configuring Security - -**Step 2: Configure permissions (optional)** +### 3.4 Configuring Permissions After deploying your contract, the owner can enable any combination of security checks using the setter functions. + + + @@ -2576,9 +2573,58 @@ myConsumer.setExpectedWorkflowName(bytes10(0)); - Your business logic in `_processReport` - (Optional) Configure permissions after deployment using setter functions -## 4. Advanced Usage (Optional) +## 4. Working with Simulation + +When you run `cre workflow simulate`, your workflow interacts with a **`MockKeystoneForwarder`** contract that does not provide workflow metadata (`workflow_name`, `workflow_owner`). + + + +### Forwarder address validation + +You **can** configure the forwarder address check during simulation: + +```solidity +// Optional: Validate the MockKeystoneForwarder address during simulation +myConsumer.setForwarderAddress(0xMockForwarderAddress); +``` + + + + +### Metadata-based validation + +**Do not configure these validation checks** during simulation - they require metadata that `MockKeystoneForwarder` doesn't provide: + +- `setExpectedWorkflowId()` +- `setExpectedAuthor()` +- `setExpectedWorkflowName()` + +Setting any of these will cause your simulation to fail. -### 4.1 Custom Validation Logic +### After deployment + +Once you deploy your workflow: + +1. Update the forwarder address to the real `KeystoneForwarder` (if you configured it for simulation) +2. Configure additional metadata-based validation as needed + +```solidity +// Update to production KeystoneForwarder address +myConsumer.setForwarderAddress(0xF8344CFd5c43616a4366C34E3EEE75af79a74482); // Example: Ethereum Sepolia + +// Now you can enable metadata-based validation +myConsumer.setExpectedWorkflowId(0xYourWorkflowId); +``` + +See [Configuring Permissions](#34-configuring-permissions) for complete details. + +## 5. Advanced Usage (Optional) + +### 5.1 Custom Validation Logic You can override `onReport` to add your own validation logic before or after the standard checks: @@ -2617,7 +2663,7 @@ contract AdvancedConsumer is IReceiverTemplate { } ``` -### 4.2 Using Metadata Fields in Your Logic +### 5.2 Using Metadata Fields in Your Logic The `_decodeMetadata` helper function is available for use in your `_processReport` implementation. This allows you to access workflow metadata for custom business logic: @@ -2645,32 +2691,7 @@ contract MetadataAwareConsumer is IReceiverTemplate { For production systems requiring even more sophisticated access control (such as role-based permissions or two-step ownership transfer), consider extending the template to use OpenZeppelin's `AccessControl` instead of `Ownable`, or implementing a custom ownership transfer pattern. -### 4.3 Working with Simulation - - - - -When you run `cre workflow simulate`, your workflow interacts with a **`MockForwarder`** contract that does not provide the `workflow_name` or `workflow_owner` metadata. This means consumer contracts with `IReceiverTemplate`'s default validation **will fail during simulation**. - -**To test your consumer contract with simulation:** - -Override the `onReport` function to bypass validation checks: - -```solidity -// Temporary: For simulation only -// Re-enable validation for production deployment -function onReport(bytes calldata, bytes calldata report) external override { - _processReport(report); // Skips validation checks -} -``` - -**For deployed workflows:** - -Deployed workflows use the real **`KeystoneForwarder`** contract, which provides full metadata. Remove this override and enable permission checks for production deployments. See [Configuring Security](#34-configuring-security) for details. - -## 5. Complete Examples +## 6. Complete Examples ### Example 1: Simple Consumer Contract @@ -10146,7 +10167,7 @@ CRE workflows support EVM read and write operations on the following blockchain Learn more: [Onchain Write Overview](/cre/guides/workflow/using-evm-client/onchain-write/overview) - **Permissioning with the Forwarder address**: You can optionally use the forwarder address to add an extra security layer to your consumer contracts by restricting the `onReport()` function to only accept calls from the trusted forwarder. See [Permissioning by Forwarder Address](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts#permissioning-by-forwarder-address) for implementation details. + **Permissioning with the Forwarder address**: You can optionally use the forwarder address to add an extra security layer to your consumer contracts by restricting the `onReport()` function to only accept calls from the trusted forwarder. See [Configuring Permissions](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts#34-configuring-permissions) for implementation details. ## Testnets diff --git a/src/content/cre/llms-full-ts.txt b/src/content/cre/llms-full-ts.txt index 78909c1b5e3..b944434e1aa 100644 --- a/src/content/cre/llms-full-ts.txt +++ b/src/content/cre/llms-full-ts.txt @@ -1925,8 +1925,9 @@ This guide explains how to build a consumer contract that can securely receive a - [Core Concepts: The Onchain Data Flow](#1-core-concepts-the-onchain-data-flow) - [The IReceiver Standard](#2-the-ireceiver-standard) - [Using IReceiverTemplate](#3-using-ireceivertemplate) -- [Advanced Usage](#4-advanced-usage-optional) -- [Complete Examples](#5-complete-examples) +- [Working with Simulation](#4-working-with-simulation) +- [Advanced Usage](#5-advanced-usage-optional) +- [Complete Examples](#6-complete-examples) ## 1. Core Concepts: The Onchain Data Flow @@ -1971,11 +1972,6 @@ While you can implement these standards manually, we provide an abstract contrac - **ERC165 Support**: Includes the necessary `supportsInterface` function - **Metadata Access**: Helper function to decode workflow ID, name, and owner for custom validation logic - - - ### 3.2 Contract Source Code ```solidity @@ -2092,8 +2088,6 @@ abstract contract IReceiverTemplate is IReceiver, Ownable { ### 3.3 Quick Start -**Step 1: Inherit and implement your business logic** - The simplest way to use `IReceiverTemplate` is to inherit from it and implement the `_processReport` function: ```solidity @@ -2117,13 +2111,16 @@ contract MyConsumer is IReceiverTemplate { } ``` -### 3.4 Configuring Security - -**Step 2: Configure permissions (optional)** +### 3.4 Configuring Permissions After deploying your contract, the owner can enable any combination of security checks using the setter functions. + + + @@ -2165,9 +2162,58 @@ myConsumer.setExpectedWorkflowName(bytes10(0)); - Your business logic in `_processReport` - (Optional) Configure permissions after deployment using setter functions -## 4. Advanced Usage (Optional) +## 4. Working with Simulation + +When you run `cre workflow simulate`, your workflow interacts with a **`MockKeystoneForwarder`** contract that does not provide workflow metadata (`workflow_name`, `workflow_owner`). + + + +### Forwarder address validation + +You **can** configure the forwarder address check during simulation: + +```solidity +// Optional: Validate the MockKeystoneForwarder address during simulation +myConsumer.setForwarderAddress(0xMockForwarderAddress); +``` + + + + +### Metadata-based validation + +**Do not configure these validation checks** during simulation - they require metadata that `MockKeystoneForwarder` doesn't provide: + +- `setExpectedWorkflowId()` +- `setExpectedAuthor()` +- `setExpectedWorkflowName()` + +Setting any of these will cause your simulation to fail. -### 4.1 Custom Validation Logic +### After deployment + +Once you deploy your workflow: + +1. Update the forwarder address to the real `KeystoneForwarder` (if you configured it for simulation) +2. Configure additional metadata-based validation as needed + +```solidity +// Update to production KeystoneForwarder address +myConsumer.setForwarderAddress(0xF8344CFd5c43616a4366C34E3EEE75af79a74482); // Example: Ethereum Sepolia + +// Now you can enable metadata-based validation +myConsumer.setExpectedWorkflowId(0xYourWorkflowId); +``` + +See [Configuring Permissions](#34-configuring-permissions) for complete details. + +## 5. Advanced Usage (Optional) + +### 5.1 Custom Validation Logic You can override `onReport` to add your own validation logic before or after the standard checks: @@ -2206,7 +2252,7 @@ contract AdvancedConsumer is IReceiverTemplate { } ``` -### 4.2 Using Metadata Fields in Your Logic +### 5.2 Using Metadata Fields in Your Logic The `_decodeMetadata` helper function is available for use in your `_processReport` implementation. This allows you to access workflow metadata for custom business logic: @@ -2234,32 +2280,7 @@ contract MetadataAwareConsumer is IReceiverTemplate { For production systems requiring even more sophisticated access control (such as role-based permissions or two-step ownership transfer), consider extending the template to use OpenZeppelin's `AccessControl` instead of `Ownable`, or implementing a custom ownership transfer pattern. -### 4.3 Working with Simulation - - - - -When you run `cre workflow simulate`, your workflow interacts with a **`MockForwarder`** contract that does not provide the `workflow_name` or `workflow_owner` metadata. This means consumer contracts with `IReceiverTemplate`'s default validation **will fail during simulation**. - -**To test your consumer contract with simulation:** - -Override the `onReport` function to bypass validation checks: - -```solidity -// Temporary: For simulation only -// Re-enable validation for production deployment -function onReport(bytes calldata, bytes calldata report) external override { - _processReport(report); // Skips validation checks -} -``` - -**For deployed workflows:** - -Deployed workflows use the real **`KeystoneForwarder`** contract, which provides full metadata. Remove this override and enable permission checks for production deployments. See [Configuring Security](#34-configuring-security) for details. - -## 5. Complete Examples +## 6. Complete Examples ### Example 1: Simple Consumer Contract @@ -8888,7 +8909,7 @@ CRE workflows support EVM read and write operations on the following blockchain Learn more: [Onchain Write Overview](/cre/guides/workflow/using-evm-client/onchain-write/overview) - **Permissioning with the Forwarder address**: You can optionally use the forwarder address to add an extra security layer to your consumer contracts by restricting the `onReport()` function to only accept calls from the trusted forwarder. See [Permissioning by Forwarder Address](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts#permissioning-by-forwarder-address) for implementation details. + **Permissioning with the Forwarder address**: You can optionally use the forwarder address to add an extra security layer to your consumer contracts by restricting the `onReport()` function to only accept calls from the trusted forwarder. See [Configuring Permissions](/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts#34-configuring-permissions) for implementation details. ## Testnets