diff --git a/content/chainlink-cre/index.mdx b/content/chainlink-cre/index.mdx
new file mode 100644
index 00000000..a8d0e56d
--- /dev/null
+++ b/content/chainlink-cre/index.mdx
@@ -0,0 +1,304 @@
+---
+title: Mapping Your Defender Setup
+description: Map each kind of Defender Monitor, Action, and Relayer setup to a Chainlink CRE pattern, and see what changes when you move it
+---
+
+This guide has two parts. Part 1, defined in this page, maps each kind of Defender Setup to Chainlink CRE and explains what changes when you move it. [Part 2](/chainlink-cre/worked-example) walks through a complete port of OpenZeppelin's Defender governance alert that you simulate, deploy, and verify on Sepolia.
+
+
+## 01 What This Guide Covers
+
+Defender has been shut down. This guide is for teams that ran Defender Monitors, Actions, and Relayers and want to move supported workflows to [Chainlink Runtime Environment (CRE)](https://docs.chain.link/cre). Each section explains what moves into CRE and what you need to adapt, so start with the routing table and then follow the sections relevant to your workflow:
+
+- [**Section 02**](#assessing-whether-your-use-case-transfers) maps each kind of Defender setup to a CRE pattern, or flags it for more assessment.
+- [**Section 03**](#how-a-cre-workflow-runs) explains the CRE model that [sections 04–08](#scheduled-jobs) build on.
+- [**Sections 04–08**](#scheduled-jobs) cover what changes for scheduled jobs, webhooks and notifications, event monitoring, onchain writes, and your existing Action code.
+- [**Section 09**](#additional-migration-considerations) covers requirements these patterns do not handle.
+
+**This is a manual port, which means that you keep your application logic but adapt triggers, runtime dependencies, and permissions. Some Defender configurations have no direct equivalent in the patterns covered here.**
+
+```mermaid
+flowchart TB
+ subgraph Before["Defender"]
+ direction LR
+ DT["Monitor / schedule / webhook"] --> DA["Action"]
+ DA --> DN["Notification channel"]
+ DA --> DR["Relayer"] --> DC["Your contract"]
+ end
+ subgraph After["Chainlink CRE"]
+ direction LR
+ CT["Trigger"] --> CH["Handler, runs on every DON node"]
+ CH -->|"HTTP"| CE["Your endpoint"]
+ CH -->|"signed report"| CF["Forwarder"] --> CR["Your Receiver"]
+ end
+ Before ~~~ After
+```
+
+*Before and after: in Defender, a Monitor, schedule, or webhook started an Action, which notified through a managed channel or had a Relayer submit a transaction. In CRE, a trigger starts a handler on every DON node, which calls your endpoint over HTTP or writes a signed report that the Forwarder verifies and delivers to your Receiver.*
+
+
+## 02 Assessing Whether Your Use Case Transfers
+
+**Review how your workflow starts, what its code does, and what it changes.** Check every row that applies. If a Monitor invoked an Action, assess the Monitor's conditions and the Action's code together.
+
+| **Your Defender setup** | **CRE approach** | **Read** |
+| --- | --- | --- |
+| Runs on a schedule (Action) | Cron trigger with your workflow logic. | [04](#scheduled-jobs) |
+| Starts from a webhook (Action) | HTTP trigger; adapt the caller's authentication and payload. | [05](#offchain-actions) |
+| Reacts to contract events (Monitor → Action) | EVM Log trigger; conditions become filtering logic in the handler. | [06](#monitoring-triggered-responses) |
+| Sends notifications or calls an API (Monitor → Action) | HTTP requests from your code, with your own credentials and delivery handling. | [05](#offchain-actions) |
+| Sends transactions (Action → Relayer) | Report-based writes through a Receiver contract. | [07](#onchain-actions) |
+| Runs custom Action code (Actions) | Adapt the code and its dependencies to the CRE runtime. | [08](#porting-your-existing-code) |
+
+These patterns are starting points. Other monitoring conditions, state across executions, and timing requirements may need additional parts or a different approach. Details on what to evaluate are in [section 09](#additional-migration-considerations) (Additional Migration Considerations). Check [supported networks](https://docs.chain.link/cre/supported-networks-ts) and [service quotas](https://docs.chain.link/cre/service-quotas) before implementing your port.
+
+
+## 03 How a CRE Workflow Runs
+
+[Sections 04–08](#scheduled-jobs) all build on one model: a trigger, a handler, and one of two outputs, an HTTP request or a signed report.
+
+
+
+*A notification-only workflow needs no Receiver. For onchain writes, your Receiver can perform the operation itself or call another contract.*
+
+A CRE workflow has three parts. A trigger starts it: a schedule, a contract event, or an HTTP request. A handler runs your logic. The handler calls capabilities: read a chain, call an API, write a report. You write the workflow in TypeScript or Go and compile it to WebAssembly. Our examples use TypeScript.
+
+A deployed workflow runs on a [Decentralized Oracle Network (DON)](https://docs.chain.link/cre/key-terms#decentralized-oracle-network-don). CRE coordinates execution across that network and uses consensus to combine results. Running on the DON also constrains how you write the handler; [section 08](#porting-your-existing-code) covers how.
+
+In Defender, your Action asked a Relayer to sign and submit a transaction. For onchain writes, the CRE workflow prepares a **report**: encoded data signed by the oracle network. Chainlink's [Forwarder](https://docs.chain.link/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts#1-core-concepts-the-onchain-data-flow) is an onchain contract that verifies those signatures and delivers the report to your **Receiver** through a function called `onReport`. The Receiver interprets the data and performs the permitted operation.
+
+Chainlink deploys and operates the Forwarder. **The Receiver is yours: either your existing contract extended to accept reports, or a small contract in front of it.** [Section 07](#onchain-actions) covers what you write and what you configure.
+
+
+## 04 Scheduled Jobs
+
+A scheduled Action becomes a [Cron trigger](https://docs.chain.link/cre/guides/workflow/using-triggers/cron-trigger-ts) and a handler. The expression takes the usual five fields, or six when you need seconds, and runs in UTC unless you prefix a zone, for example `TZ=America/New_York 0 9 * * 1-5`. The shortest interval is 30 seconds, per [Chainlink's quotas](https://docs.chain.link/cre/service-quotas#cron-trigger).
+
+Inside the handler, take the time from `runtime.now()` rather than `Date.now()`. It returns [DON Time](https://docs.chain.link/cre/guides/workflow/time-in-workflows-ts), a timestamp every node agrees on.
+
+Registering the trigger is one call:
+
+```typescript
+export function initWorkflow(config: Config) {
+ const cron = new cre.capabilities.CronCapability()
+ return [cre.handler(cron.trigger({ schedule: config.schedule }), onCronTrigger)]
+}
+```
+
+The `schedule` value belongs in configuration; `onCronTrigger` contains the business logic. Chainlink's [keeper-bot starter template](https://github.com/smartcontractkit/cre-templates/tree/d0223f31182c76bc36b1cc9d47b13b18efcf2bf6/starter-templates/keeper-bot/keeper-bot-ts) follows a common Defender pattern, a scheduled Action that checked a contract and sent a transaction only when work was due: its handler reads the contract, checks the condition, then either skips or writes.
+
+
+Show the handler excerpt (adapted, with client setup and logging removed)
+
+```typescript
+// excerpt: onCronTrigger in the keeper example
+const upkeepNeeded = keeper.needsUpkeep(runtime) // read the contract
+
+if (!upkeepNeeded) { // check the condition
+ return 'Skipped: no upkeep needed'
+}
+
+const reportData = encodeAbiParameters(parseAbiParameters('bool shouldExecute'), [true])
+const writeResult = keeper.writeReport(runtime, reportData) // write
+```
+
+
+
+[Section 07](#onchain-actions) covers what happens after `writeReport` and how to check its result; the full handler is [`my-workflow/workflow.ts`](https://github.com/smartcontractkit/cre-templates/blob/d0223f31182c76bc36b1cc9d47b13b18efcf2bf6/starter-templates/keeper-bot/keeper-bot-ts/my-workflow/workflow.ts) in that template.
+
+**Keep the schedule and the execution condition separate when you port your Action, the way the template does.** Exercise both outcomes, skip and write, in simulation before you deploy.
+
+Know where that condition is enforced. The workflow decides whether to write by reading `needsUpkeep()` on the contract, but the template's Receiver does not recheck the interval when it processes the report, so nothing onchain enforces the interval on each write. If you need that guarantee, the Receiver has to implement it.
+
+
+## 05 Offchain Actions
+
+**Incoming requests.** A webhook Action becomes an [HTTP trigger](https://docs.chain.link/cre/guides/workflow/using-triggers/http-trigger/overview-ts). A deployed workflow only accepts requests signed by keys you list in `authorizedKeys`, so the caller changes along with the URL.
+
+**Outgoing requests.** Replace managed notification settings with an HTTP integration. Define the destination, payload, credentials, and response handling. The `HTTPClient` capability coordinates requests and response aggregation across nodes.
+
+Use Chainlink's [cacheSettings pattern](https://docs.chain.link/cre/guides/workflow/using-http-client/post-request-ts) to reduce duplicate requests across nodes. **Caching is best effort, so the destination must still enforce idempotency, including when multiple requests originate from the same workflow execution.** Treat unsuccessful HTTP responses as explicit failures. Chainlink's guide shows the fields `readFromCache` and `maxAgeMs`, while the SDK 1.19.1 `CacheSettings` type uses `store` and `maxAge`, as in this request from OpenZeppelin's `gov-alert` example, the governance alert ported in Part 2.
+
+
+Show the request excerpt from `gov-alert/workflow.ts`
+
+`sender`, `input`, and the encoded body are supplied by the surrounding implementation:
+
+```typescript
+const response = sender.sendRequest({
+ method: 'POST',
+ url: input.url,
+ body: bytesToBase64(bodyBytes),
+ headers: { 'Content-Type': 'application/json', 'Idempotency-Key': input.idempotencyKey },
+ cacheSettings: { store: true, maxAge: '60s' }, // field names as of SDK 1.19.1
+}).result()
+if (!ok(response)) throw new Error(`HTTP request failed with status: ${response.statusCode}`)
+```
+
+
+
+The `gov-alert` example sends an `Idempotency-Key` header built from the network, the transaction hash, and the event log index supplied by CRE, so the same event always produces the same key. Many APIs support this convention for recognizing a repeated request, but HTTP does not require it and CRE does not handle it for you. The key prevents duplicate notifications only if the destination refuses a key it has already seen; if your provider does not, add your own deduplication layer or accept that limit. It also does not recover missed deliveries: if missed notifications must be recovered, define and test a retry or reconciliation process.
+
+Whichever destination you use, you now integrate with its provider directly. Most of the channels Defender managed for you expose a webhook or an API you can call this way; email normally needs a mail provider in front of it.
+
+**Credentials.** Secrets belong in [CRE's secrets store](https://docs.chain.link/cre/guides/workflow/secrets/using-secrets-deployed), outside your source and your config file. You create the secret once with the CLI, and the deployed workflow reads it at runtime. Follow the [`cre secrets` CLI reference](https://docs.chain.link/cre/reference/cli/secrets#authorization-flow) for the commands and the authorization step.
+
+
+## 06 Monitoring-Triggered Responses
+
+A Monitor with an event condition maps to the [EVM Log trigger](https://docs.chain.link/cre/guides/workflow/using-triggers/evm-log-trigger-ts). The trigger filters by contract address and event topics, within [Chainlink's limits](https://docs.chain.link/cre/service-quotas#evm-log-trigger) on both. **Anything Defender expressed as a condition on the decoded fields moves into the handler as plain TypeScript.** Defender evaluated those conditions with [math.js](https://mathjs.org/docs/expressions/syntax.html#differences-from-javascript), a JavaScript library for evaluating mathematical expressions, so when you translate a condition, review its operators and how it treats numbers rather than assuming TypeScript will behave the same way.
+
+For a condition on decoded fields, evaluate the predicate before calling the notification logic. Preserve the original units, numeric precision and boundary comparisons. Test a matching event and a non-matching event, including values exactly at the threshold.
+
+Suppose your Defender Monitor watched a [Governor](/contracts/5.x/governance) contract for new proposals. A successful proposal transaction causes that contract to emit `ProposalCreated`. In CRE you select the network and the Governor address, then register a handler for that event. The sequence runs end to end like this: the Governor emits the event onchain, a filter on address and event selects it, your handler receives it decoded, and your code turns it into a message.
+
+The `gov-alert` example, ported in full in Part 2, ships a generated TypeScript **binding**: a helper built from the contract's ABI. The binding supplies the event filter and the decoding code, so you do not hand-write either. `logTriggerProposalCreated()` *creates the filter*; it does not create a proposal or emit an event. The event comes from the contract, and the workflow only listens for it.
+
+Two lines from the example's `initWorkflow` in `gov-alert/workflow.ts` carry the whole mechanism: `evmClient` selects the configured network, and the address is the Governor you want to watch. The handler then receives the decoded event and passes the fields it cares about to the formatter.
+
+
+Show the trigger registration and the handler (excerpts from `gov-alert/workflow.ts`)
+
+```typescript
+const governor = new GovernorEvents(evmClient, config.governorAddress as Address)
+
+return [
+ cre.handler(governor.logTriggerProposalCreated(), onProposalCreated),
+]
+```
+
+```typescript
+export const onProposalCreated = (
+ runtime: Runtime,
+ payload: DecodedLog,
+): string =>
+ handleEvent(runtime, payload, {
+ type: 'ProposalCreated',
+ proposalId: payload.data.proposalId,
+ proposer: payload.data.proposer,
+ description: payload.data.description,
+ })
+```
+
+
+
+The full example registers four more Governor events the same way, each with its own small handler and all sharing one formatter.
+
+In this design, two matching events in the same transaction arrive as two executions, where Defender delivered one payload with both. If your Action relied on that batching, restructure it. For conditions on function calls or transaction status, see the options in [section 09](#additional-migration-considerations).
+
+
+## 07 Onchain Actions
+
+Porting an Action that sent transactions through a Relayer mostly means work on the receiving end. Your application logic and your contracts still exist. What changes is delivery: a Relayer simply submitted the transaction your Action had already composed, while CRE delivers a signed report, so you may need to add a contract able to accept that report and act on it. Depending on what you own, that can mean extending a contract you already have rather than deploying a new one.
+
+To accept a report, a contract has to say so. That is all the [IReceiver standard](https://docs.chain.link/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts#2-the-ireceiver-standard) is: `onReport`, plus [ERC-165 interface detection](/contracts/5.x/utilities#introspection) so the Forwarder can check compatibility before calling. You can implement it directly, or inherit Chainlink's [`ReceiverTemplate`](https://docs.chain.link/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts#3-using-receivertemplate), which handles report reception and configured source-identity checks and leaves you `_processReport` to fill in; your implementation defines which operations and arguments are allowed.
+
+Then you choose where it sits, and Chainlink's guide gives [a worked example of each shape](https://docs.chain.link/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts#6-complete-examples). Either your target contract becomes the Receiver itself, [the simple consumer](https://docs.chain.link/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts#example-1-simple-consumer-contract), or a **receiver adapter** sits in front, accepts the report and calls the target, which Chainlink documents as [the proxy pattern](https://docs.chain.link/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts#example-2-the-proxy-pattern). It forwards calls and has nothing to do with an [upgradeability proxy](/contracts/5.x/api/proxy). The adapter is what you want when the target already exposes the operation you need and can authorize another caller.
+
+
+
+*The receiving design determines which address your contract must authorize.*
+
+| **Receiving design** | **Caller seen by the contract** |
+| --- | --- |
+| Target implements `IReceiver` | The target's `onReport` sees the Forwarder |
+| A receiver adapter receives the report and calls the target | The adapter sees the Forwarder; the target sees the adapter |
+
+This matters because a target that checks `msg.sender` will see a different address than it used to. For a protected target behind an adapter, grant the adapter the required permission (see [Access Control](/contracts/5.x/access-control) for `Ownable` and `AccessControl` targets). Review the permissions wherever a contract accepted calls from your old Relayer address: some can be updated in place, and a contract locked to that address may need a replacement or a different integration.
+
+Then configure who may deliver, and configure both halves. One is the Forwarder address your Receiver trusts. The other is the identity of the workflow whose reports you accept, because trusting a Forwarder on its own accepts every CRE workflow that can deliver through it, not only yours. In `ReceiverTemplate` those are the [permission setters](https://docs.chain.link/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts#34-configuring-permissions): `setExpectedWorkflowId`, or `setExpectedAuthor` together with `setExpectedWorkflowName`. Take the Forwarder address from the [directory and its instructions](https://docs.chain.link/cre/guides/workflow/using-evm-client/forwarder-directory-ts) for the network and environment you are targeting, rather than assuming one address per chain; after logging in, `cre workflow supported-chains` lists the addresses available to you.
+
+
+
+A Receiver that trusts the right Forwarder but no workflow identity is open to anyone else's workflow.
+
+
+
+Configure these checks before accepting deployed reports. For mock-Forwarder simulation, use an isolated test Receiver and follow the [documented metadata limitations](https://docs.chain.link/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts#4-working-with-simulation); do not weaken the permissions on your deployed Receiver to make a simulation pass.
+
+The Forwarder does not redeliver a report that already succeeded. Some failed attempts can be retried, but not all: a transmission recorded as having an invalid receiver is also treated as already attempted. And two reports with the same content are still two calls. Keep the operation idempotent in the Receiver rather than relying on delivery behavior, and follow Chainlink's guidance on [binding reports to the intended chain](https://docs.chain.link/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts#replay-attacks).
+
+On the workflow side, the write is one call on the generated `KeeperConsumer` binding in Chainlink's keeper-bot starter template ([section 04](#scheduled-jobs)). The report encodes a boolean execution signal, and the Receiver decodes it and increments a counter. This example illustrates the write path only; the governance walkthrough in Part 2 is a separate, notification-only workflow.
+
+
+Show the write and its two status checks (adapted from the template's `workflow.ts`, with shorter error messages)
+
+```typescript
+const writeResult = keeper.writeReport(runtime, reportData)
+if (writeResult.txStatus !== TxStatus.SUCCESS) {
+ throw new Error(writeResult.errorMessage || String(writeResult.txStatus))
+}
+if (
+ writeResult.receiverContractExecutionStatus !== undefined &&
+ writeResult.receiverContractExecutionStatus !== 0
+) {
+ throw new Error('Receiver contract execution failed')
+}
+```
+
+
+
+The above code checks the transaction status and the reported Receiver execution status. Neither proves the operation did what you meant. After a deployed write or an explicitly broadcast simulation, read the contract to verify the intended state change; a normal dry-run simulation does not change onchain state.
+
+One deployment detail catches people out: if a read of a Receiver you just deployed fails to decode empty data, the read probably targeted a finalized block from before the deployment, so wait for finality to advance. Check the network, the address and the ABI too, since they cause the same error.
+
+
+## 08 Porting Your Existing Code
+
+Three things change for the Action code itself: the runtime it runs in, the contract bindings you generate, and the requirement that every node reach the same result.
+
+### Runtime and Dependencies
+
+Action code ran on Node.js. CRE packages the JavaScript generated from your TypeScript together with [QuickJS](https://docs.chain.link/cre/concepts/typescript-wasm-runtime) into a WebAssembly binary, so Node.js APIs may need replacements. Check both the language features and the platform APIs your code uses, because the gap is not obvious from reading it. With CRE CLI 1.34.0 and `@chainlink/cre-sdk` 1.19.1, `Intl` was unavailable and `structuredClone` was undefined, which is enough to break number or date formatting that worked fine in an Action. For hex conversion, use the SDK's `bytesToHex`. Availability is a property of the runtime version, so check it against the one you deploy on rather than trusting this list.
+
+### Generated Bindings
+
+Generated bindings have one sharp edge worth checking early. In CRE CLI 1.34.0, a contract with overloaded functions produced bindings that do not compile, and OpenZeppelin's Governor is such a contract. The `gov-alert` example sidesteps it by generating from an events-only ABI; reducing an ABI does not help if the functions you keep are still overloaded.
+
+### Deterministic Execution and Simulation
+
+[Determinism](https://docs.chain.link/cre/concepts/non-determinism-ts) is the largest of the three changes, and it has no Defender equivalent because an Action ran once, on one machine. **Here every node runs your handler and they have to arrive at the same answer.** Anything that can differ per node breaks that when it influences execution: `Math.random()`, `Date.now()`, and any branch, record selection, call or loop count that depends on them. Take time from `runtime.now()` instead.
+
+Work that genuinely cannot agree by itself, such as calling a third-party API, goes in a different execution mode. The SDK names the two after its runtime types: your handler receives a `Runtime`, [which the reference calls DON mode](https://docs.chain.link/cre/reference/sdk/core-ts#runtime-and-noderuntime), and you drop into Node mode inside `runtime.runInNodeMode()`, where each node produces its own answer and you supply the [rule that combines them](https://docs.chain.link/cre/reference/sdk/consensus-ts).
+
+Be careful with what local simulation proves. It runs on a [single node](https://docs.chain.link/cre/guides/operations/simulating-workflows#limitations), so by construction it cannot detect disagreement between nodes: a workflow can pass local simulation even when node-dependent values affect decisions or outputs that must agree across the DON. A green local run tells you the code executes; whether the DON will agree on the result is a separate question, so review the decision logic for determinism by reading it.
+
+A practical starting point is to separate pure formatting and calculations from network calls. Test the pure functions with the same inputs used by the Defender Action. Then adapt network access to CRE capabilities and review every value that controls a branch or an operation.
+
+Finally, keep credentials in CRE's secrets store, as set up in [section 05](#offchain-actions), rather than in committed configuration or source code.
+
+
+## 09 Additional Migration Considerations
+
+Some requirements need more than the patterns in [sections 04–08](#scheduled-jobs). **Assess the behavior you need to preserve before adding parts.**
+
+- **Conditions on function calls or transaction status**: an EVM Log trigger covers emitted events. For other signals, consider an external event source that invokes the HTTP trigger. Periodic chain reads may suit state-based checks, but can miss intermediate activity and do not reproduce every transaction condition.
+- **State across executions**: alert thresholds and cooldowns depend on history. External storage may hold that history, but the design must account for concurrent executions, retries and duplicate updates. A read followed by a write is not automatically sufficient.
+- **Schedules under 30 seconds**: the current [Cron quota](https://docs.chain.link/cre/service-quotas#cron-trigger) has a 30-second floor. Check whether the task tolerates that interval or can react to an event instead. An HTTP trigger has its own rate limit, so it cannot work around that floor.
+
+Treat these as options to evaluate; this guide has not validated them as implementations. Event-driven execution also has quotas and does not promise a particular response time. If the original timing or monitoring behavior is essential, confirm that the chosen design preserves it before porting the remaining logic.
+
+For managed notification channels, use the HTTP integration described in [section 05](#offchain-actions). Other configurations not covered here need individual assessments. Send questions to Defender support: [defender-support@openzeppelin.com](mailto:defender-support@openzeppelin.com).
+
+
+## Next: Try It End to End
+
+By now you should know which CRE pattern each of your Defender setups maps to, what to adapt in each, and which ones need their own assessment. Part 2 puts sections [03](#how-a-cre-workflow-runs), [05](#offchain-actions), [06](#monitoring-triggered-responses) and [08](#porting-your-existing-code) into practice with a notification-only workflow: it ports OpenZeppelin's Defender governance alert to CRE, replays a real proposal through local simulation, deploys the workflow on Sepolia, and checks both a successful delivery and a failed one. It has no Cron trigger or Receiver, so sections [04](#scheduled-jobs) and [07](#onchain-actions) stay your reference for those.
+
+**Continue to Part 2:** [Worked Example](/chainlink-cre/worked-example)
+
+
+## Glossary
+
+
+Show the glossary
+
+- [**Trigger**](https://docs.chain.link/cre/guides/workflow/using-triggers/overview)**.** What starts a workflow: a cron schedule, an EVM log, or an HTTP request.
+- [**Handler**](https://docs.chain.link/cre/reference/sdk/core-ts#handler)**.** The function that runs when a trigger fires.
+- [**DON**](https://docs.chain.link/cre/key-terms#decentralized-oracle-network-don)**.** Decentralized Oracle Network. The nodes that run your workflow and agree on the result.
+- [**DON mode and Node mode**](https://docs.chain.link/cre/reference/sdk/core-ts#runtime-and-noderuntime)**.** Two execution modes, named in the SDK reference after the two runtime types. DON mode is the `Runtime` your handler receives, for operations the network already guarantees. Node mode is the `NodeRuntime` you get inside `runtime.runInNodeMode()`, where nodes may differ and you supply the [aggregation rule](https://docs.chain.link/cre/reference/sdk/consensus-ts).
+- [**Report**](https://docs.chain.link/cre/guides/workflow/using-evm-client/onchain-write/overview-ts)**.** Data prepared by a workflow and signed by the DON for delivery to your Receiver.
+- [**Forwarder**](https://docs.chain.link/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts#1-core-concepts-the-onchain-data-flow)**.** The Chainlink contract that verifies a report's signatures and calls your Receiver. Which address applies depends on your network and environment.
+- [**Receiver**](https://docs.chain.link/cre/guides/workflow/using-evm-client/onchain-write/building-consumer-contracts)**.** Your contract. It implements `onReport` and holds the logic a report may trigger.
+
+
diff --git a/content/chainlink-cre/worked-example.mdx b/content/chainlink-cre/worked-example.mdx
new file mode 100644
index 00000000..5e0a20f6
--- /dev/null
+++ b/content/chainlink-cre/worked-example.mdx
@@ -0,0 +1,307 @@
+---
+title: Worked Example
+description: Port OpenZeppelin's Defender governance alert to Chainlink CRE, then simulate, deploy, and verify it on Sepolia
+---
+
+This is Part 2. [Mapping Your Defender Setup](/chainlink-cre) maps each kind of Defender setup to CRE and explains what changes; this part puts that into practice with one complete port you can run yourself.
+
+
+## What You'll Build
+
+Let's follow one event from a Governor contract to a notification. The starting point is OpenZeppelin's original [Defender governance alert template](https://github.com/OpenZeppelin/defender-templates/tree/main/defender/governance_alert), a Monitor plus an Action. The CRE example is a separate project that ports the template's five event handlers; this walkthrough follows `ProposalCreated`, then shows how to check the result.
+
+**The goal is to preserve the notification's content while changing how the event reaches the code and how the message is delivered.** [Steps 1 and 2](#step-1) set up the example; [Steps 3 to 5](#step-3) replay an existing Sepolia receipt through local simulation, against your own Governor. [Steps 6 to 9](#step-6) deploy the same workflow and watch a real execution.
+
+
+
+*Both designs respond to ProposalCreated. With CRE, the workflow handles the event, formats the message and sends it to the notification endpoint.*
+
+By the end, you will have replayed a real proposal through local simulation, deployed the workflow, watched a real execution deliver a notification, and confirmed that a failed delivery shows up where you can see it.
+
+
+## Concepts From Part 1 You'll Use
+
+This walkthrough relies on a few ideas from Part 1. If any of them is new, read that section first:
+
+- **Triggers and handlers**: a trigger starts the workflow and a handler runs your logic ([section 03](/chainlink-cre#how-a-cre-workflow-runs)).
+- **The EVM Log trigger and generated bindings**: how a Monitor's event condition becomes a filter plus handler code (sections [06](/chainlink-cre#monitoring-triggered-responses) and [08](/chainlink-cre#porting-your-existing-code)).
+- **HTTP delivery and idempotency keys**: you own delivery now, including duplicates and failures ([section 05](/chainlink-cre#offchain-actions)).
+- **Determinism and single-node simulation**: why a passing local run does not prove the DON will agree ([section 08](/chainlink-cre#porting-your-existing-code)).
+- **No Receiver needed here**: this workflow only sends notifications. For onchain writes, see [section 07](/chainlink-cre#onchain-actions).
+
+
+## Before You Start
+
+**Tested with** CRE CLI 1.34.0, `@chainlink/cre-sdk` 1.19.1, and Bun 1.4.0. **Bun 1.4 or later is required:** on Bun 1.3.x, `bun install --frozen-lockfile` in Step 1 fails with `UnknownLockfileVersion`. Check with `bun --version`. Have these ready:
+
+- The example project, [`gov-alert` in OpenZeppelin/defender-to-cre-examples](https://github.com/OpenZeppelin/defender-to-cre-examples/tree/v1.0.2/gov-alert), plus [Bun](https://bun.sh/docs/installation) 1.4 or later, [Foundry](https://www.getfoundry.sh/introduction/installation) (for the fixture and [Step 7](#step-7)'s `cast send`), and the [CRE CLI](https://docs.chain.link/cre/getting-started/cli-installation), [logged in](https://docs.chain.link/cre/account/cli-login).
+- A Sepolia RPC endpoint.
+- A Governor on Sepolia that emits the standard `ProposalCreated` event, and an existing transaction from it to replay. Your own is best, because [Step 7](#step-7) needs you to create a new proposal on it. The repo's [`fixture`](https://github.com/OpenZeppelin/defender-to-cre-examples/tree/v1.0.2/gov-alert/fixture) folder deploys one with Foundry.
+- An HTTP endpoint you control that accepts a POST, lets you read the incoming headers and body, and can be switched to return a non-2xx status ([Step 8](#step-8)), plus a second URL that returns non-2xx ([Step 5](#step-5)).
+- [`jq`](https://jqlang.org/download/), to read a transaction receipt in [Step 3](#step-3).
+- For [Steps 6 to 9](#step-6) only: [CRE deploy access](https://docs.chain.link/cre/account/deploy-access) (`cre account access` shows your status) **and** an enabled private registry, the Chainlink-hosted service that stores workflow registrations, which you can confirm with `cre registry list`.
+- For [Steps 6 to 9](#step-6) only: a test wallet with Sepolia ETH, able to meet your Governor's proposal requirements.
+
+
+## How the Port Maps to the Defender Template
+
+The Defender template connects a Monitor to an Action that formats governance notifications. The CRE port separates event handling, message formatting and HTTP delivery:
+
+| **Responsibility** | **Defender template** | **CRE example** |
+| --- | --- | --- |
+| Select Governor events | Monitor event conditions | Generated event bindings and trigger registrations |
+| Decode and route a match | Action inspects the Monitor payload | Typed event handler in `workflow.ts` |
+| Format the notification | Message logic inside the Action | Pure formatter in `messages.ts` |
+| Deliver the message | Configured notification channel | HTTP request from the workflow |
+
+The port preserves the five event types and notification format, including the transaction link. It replaces runtime-dependent number formatting (Part 1, [section 08](/chainlink-cre#porting-your-existing-code)) and handles each event separately, so two matching events in one transaction arrive as two executions where Defender delivered one payload (Part 1, [section 06](/chainlink-cre#monitoring-triggered-responses)). Part 1, [section 05](/chainlink-cre#offchain-actions), covers HTTP delivery. In the code, `onProposalCreated` passes the decoded fields to `handleEvent`, which adds the transaction hash, calls `formatGovernanceAlert`, and forwards the message to `sendNotification`.
+
+
+## Walkthrough: Simulate, Deploy, and Verify the Governance Alert
+
+Each step below is collapsible. Open a step to see its commands and what to check before moving on. Command names and flags follow CRE CLI 1.34.0; if you install a newer version, check `--help` on each.
+
+
+
+Step 1: Prepare the Example
+
+Clone [OpenZeppelin/defender-to-cre-examples](https://github.com/OpenZeppelin/defender-to-cre-examples/tree/v1.0.2) and move into its [`gov-alert`](https://github.com/OpenZeppelin/defender-to-cre-examples/tree/v1.0.2/gov-alert) folder:
+
+```bash
+git clone --branch v1.0.2 https://github.com/OpenZeppelin/defender-to-cre-examples.git
+cd defender-to-cre-examples/gov-alert
+```
+
+All commands in Steps 1–9 run from the **project root**, `defender-to-cre-examples/gov-alert/`. The **workflow folder** inside it is also named `gov-alert/`. The relevant files are:
+
+```text
+project.yaml # Sepolia RPC settings
+contracts/
+ package.json # Dependencies of the generated bindings
+ bun.lock
+ evm/ts/generated/
+ GovernorEvents.ts # Event decoding and trigger bindings
+gov-alert/
+ workflow.yaml # Workflow path and named settings
+ main.ts # Entry point; starts the CRE runner
+ workflow.ts # Triggers, handlers and HTTP delivery
+ messages.ts # Notification formatting
+ package.json # Pinned dependencies and test scripts
+ bun.lock
+```
+
+The example includes the generated binding, produced from an events-only ABI, which keeps it clear of a CRE CLI 1.34.0 limitation: bindings generated from a contract with overloaded functions, such as Governor, do not compile (Part 1, [section 08](/chainlink-cre#porting-your-existing-code)).
+
+The bindings are their own package, so install in both folders. Installing only inside `gov-alert` leaves the binding's imports unresolved and the typecheck fails:
+
+```bash
+(cd contracts && bun install --frozen-lockfile)
+(cd gov-alert && bun install --frozen-lockfile && bun test && bun run typecheck)
+```
+
+Expected: `bun test` passes and `bun run typecheck` exits without errors. Nothing here touches the chain, so you can run it before you have an endpoint or a Governor picked out.
+
+
+
+
+
+Step 2: Configure Your Governor and Notification Destination
+
+Copy `gov-alert/config.example.json` to `gov-alert/config.simulation-local.json`, then fill in the Governor address and your test endpoint:
+
+```json
+{
+ "chainSelectorName": "ethereum-testnet-sepolia",
+ "governorAddress": "",
+ "blockExplorerBaseUrl": "https://sepolia.etherscan.io/tx",
+ "notifyWebhookUrl": ""
+}
+```
+
+The example sends a JSON body with a `text` field; it does not automatically translate that body into every provider's notification format.
+
+Set your Sepolia RPC URL in `project.yaml` at the project root, under `staging-settings`:
+
+```yaml
+staging-settings:
+ rpcs:
+ - chain-name: ethereum-testnet-sepolia
+ url:
+```
+
+The Governor you choose must emit the standard [`ProposalCreated`](/contracts/5.x/api/governance#IGovernor-ProposalCreated-uint256-address-address---uint256---string---bytes---uint256-uint256-string-) signature, which is what the included binding filters on. Keep the local configuration out of version control if its endpoint is private.
+
+
+
+
+
+Step 3: Replay a Proposal Event
+
+You need a Sepolia transaction that already contains a `ProposalCreated` event from your configured Governor. Any past one works, since this is a replay and nothing new goes onchain.
+
+To find one, open your Governor's address on a block explorer and look through its events for `ProposalCreated`. Then find the event's **zero-based position among that transaction's logs**, which is what the simulator wants. Do not use the log index the explorer displays: that is the block-level log index described in [Step 4](#step-4), a different number. This command reads the receipt from your RPC and prints the position:
+
+```bash
+curl -s -X POST -H 'Content-Type: application/json' \
+ -d '{"jsonrpc":"2.0","id":1,"method":"eth_getTransactionReceipt","params":[""]}' \
+| jq --arg gov '' '.result.logs | to_entries[]
+ | select((.value.address | ascii_downcase) == ($gov | ascii_downcase)
+ and .value.topics[0] == "0x7d84a6263ae0d98d3329bd7b46bb4e8d6f98cd35a7adb45c274c8b7fd5ebd5e0")
+ | .key'
+```
+
+Expected: a single number, the position to use as `EVENT_POSITION` below. The long hex value is the `ProposalCreated` event signature hash.
+
+Build the workflow from the project root:
+
+```bash
+cre workflow build ./gov-alert
+```
+
+Then replay the receipt. Set both variables to your selected values before running the command:
+
+```bash
+SEPOLIA_TX_HASH=''
+EVENT_POSITION=''
+
+cre workflow simulate ./gov-alert --non-interactive \
+ --trigger-index 0 \
+ --evm-tx-hash "$SEPOLIA_TX_HASH" \
+ --evm-event-index "$EVENT_POSITION" \
+ --config config.simulation-local.json \
+ --target staging-settings
+```
+
+The `--config` path is relative to the workflow folder; all flags are in the [`cre workflow simulate` reference](https://docs.chain.link/cre/reference/cli/workflow#cre-workflow-simulate). `ProposalCreated` is the first handler `initWorkflow` returns, so `--trigger-index 0` selects it; `--evm-event-index` selects the log within the receipt. They are different indexes.
+
+The simulator fetches and decodes the event, runs the handler locally, and makes an HTTP request to your configured endpoint. That POST is real even though the workflow execution is simulated.
+
+
+
+
+
+Step 4: Inspect the Notification
+
+At your endpoint, inspect the `text` field. For a proposal titled "Upgrade the treasury" and a proposer beginning with `0x1234`, it follows this form:
+
+```json
+{
+ "text": "**New Proposal** Upgrade the treasury by 0x1234 [TX]()"
+}
+```
+
+*Illustrative output. Your title, proposer and transaction hash come from the selected event.*
+
+Check the following against your receipt:
+
+- The title comes from the first description line, with heading markers removed.
+- The proposer is shortened to the first six characters, including `0x`.
+- The transaction link points to the receipt you replayed.
+- The `Idempotency-Key` header combines the chain selector name, the transaction hash and the event log index.
+
+The log index in that header is the one CRE supplies with the decoded event, which counts logs **within the block**, not the receipt-relative position you passed as `--evm-event-index`, so the two numbers usually differ.
+
+
+
+
+
+Step 5: Check the Failure Path
+
+Point `notifyWebhookUrl` in `gov-alert/config.simulation-local.json` at a fresh test endpoint URL that returns a non-2xx response (the example's request caches responses for up to 60 seconds via `cacheSettings`, so a fresh URL avoids reusing the cached success from [Step 3](#step-3)). Rerun the [Step 3](#step-3) `cre workflow simulate` command and confirm the run fails and its output includes `HTTP request failed with status: `, the error thrown by the request code covered in Part 1, [section 05](/chainlink-cre#offchain-actions). Then restore the working URL.
+
+
+
+
+
+Step 6: Deploy the Workflow
+
+Replaying a receipt exercises your code; deploying proves CRE registers, triggers, and executes it. The simulator's `--config` override does not carry over to deployment. `cre workflow deploy` reads the workflow name and config file from the target in `gov-alert/workflow.yaml` (its own `--config` option can override the config file). Set that target before deploying:
+
+```yaml
+staging-settings:
+ user-workflow:
+ workflow-name: "gov-alert-staging"
+ deployment-registry: "private"
+ workflow-artifacts:
+ workflow-path: "./main.ts"
+ config-path: "./config.staging.json"
+ secrets-path: ""
+```
+
+Create `gov-alert/config.staging.json` from `config.example.json` with the same four fields as [Step 2](#step-2), and set `notifyWebhookUrl` to an endpoint you can inspect. Then deploy from the project root and confirm the registration:
+
+```bash
+cre workflow deploy ./gov-alert --target staging-settings
+cre workflow list --target staging-settings
+```
+
+Expected: `cre workflow list` includes `gov-alert-staging`.
+
+
+
+
+
+Step 7: Trigger a Real Execution
+
+Once the workflow is active, create a fresh proposal and wait for the trigger's [confirmation level](https://docs.chain.link/cre/concepts/finality-ts) before looking for its execution. The [EVM Log trigger reference](https://docs.chain.link/cre/reference/sdk/triggers/evm-log-trigger-ts) documents SAFE as the default. This is where replay and deployment differ: the receipt you replayed earlier will not trigger a deployed workflow.
+
+Open a real proposal by calling `propose()` on the Governor with targets, values, calldatas, and a description (see [Create a proposal](/contracts/5.x/governance#create-a-proposal)). A Governor identifies a proposal by hashing those actions together with the description, so use a fresh description when you repeat the same actions, or the proposal ID collides with the earlier one and the call reverts. Most Governors also require the caller to meet a proposal threshold, so use one where you hold or have been delegated enough voting power. On a test Governor of your own, a harmless proposal is enough: a call whose target is the Governor itself and whose calldata is a view function. For example, with Foundry's `cast`, using `0x06fdde03` (the Governor's `name()`) as the calldata:
+
+```bash
+cast send 'propose(address[],uint256[],bytes[],string)' \
+ "[]" "[0]" "[0x06fdde03]" "Test proposal " \
+ --account --rpc-url
+```
+
+`` is the Foundry keystore account for your test wallet (see [`cast wallet`](https://www.getfoundry.sh/reference/cast/wallet)); `` is any text not used in an earlier proposal description.
+
+Then check the deployment. This command takes the workflow folder and reads the name from its target:
+
+```bash
+cre workflow get ./gov-alert --target staging-settings
+```
+
+It prints deployment health and the most recent execution. To inspect a single execution, look it up by workflow ID or name, not by folder path, and read its status and logs (see the [`cre execution` reference](https://docs.chain.link/cre/reference/cli/execution#cre-execution-list)):
+
+```bash
+cre execution list --target staging-settings
+cre execution status --target staging-settings
+cre execution logs --target staging-settings
+```
+
+Take `` from the `cre execution list` output. A lookup may briefly lag registration. If nothing resolves at first, recheck the workflow identity and its registry status before retrying; errors that persist need investigation rather than another deploy. When the execution succeeds, check your endpoint for the notification and compare its message and `Idempotency-Key` against the new event's receipt, exactly as in [Step 4](#step-4).
+
+By this point you should have seen three things, one per phase: a real POST at your endpoint from the replay, an active workflow after the deploy, and then an execution you can find by ID whose notification matches the new proposal's receipt. If an execution exists without a notification, inspect its status and logs to determine whether it is still running or failed before or during the HTTP request.
+
+
+
+
+
+Step 8: Break and Restore Delivery
+
+Before deleting the test workflow in [Step 9](#step-9), deliberately break HTTP delivery, the last link in the chain and the part you now own. The simplest way is to configure the same test endpoint to answer with a server error, since that needs no change on the CRE side. Editing `config.staging.json` locally would not do it: a deployed workflow keeps the config it was deployed with, so pointing it at a different URL means deploying again. With the endpoint failing, create another proposal (rerun the [Step 7](#step-7) `cast send` with a new description) and confirm you can see the failure in `cre execution status` and `cre execution logs`, rather than finding out from a message that never arrived. Then let the endpoint answer normally again, create a third proposal, and confirm its notification arrives.
+
+That recovers delivery for new events only. This walkthrough doesn't retry the failed delivery, and nothing here makes delivery exactly-once, which is why the idempotency key only helps if your destination enforces it.
+
+
+
+
+
+Step 9: Delete the Test Workflow
+
+Delete the test workflow, or it keeps running:
+
+```bash
+cre workflow delete ./gov-alert --target staging-settings
+```
+
+Confirm with `cre workflow list --target staging-settings` that `gov-alert-staging` is no longer active. If instead you want to keep one running, first move it to a real destination, with its credentials in the secrets store rather than in a config file.
+
+
+
+
+## What You Verified
+
+You replayed a real `ProposalCreated` receipt through local simulation and inspected the notification it produced, confirmed that a failing endpoint surfaces as an explicit error, deployed the workflow and watched a real execution deliver its notification, and saw a delivery failure appear in the execution's status and logs. This walkthrough doesn't retry that failed notification; if you need missed deliveries recovered, that's yours to design (Part 1, [section 05](/chainlink-cre#offchain-actions)). The same pattern (an EVM Log trigger, a pure formatter, and HTTP delivery you own) carries over to the other four governance events the example handles.
+
+For requirements this example does not cover, such as conditions on function calls, state across executions, or schedules under 30 seconds, see Part 1, [section 09](/chainlink-cre#additional-migration-considerations) (Additional Migration Considerations). For workflows that write onchain, see Part 1, [section 07](/chainlink-cre#onchain-actions) (Onchain Actions). Questions: [defender-support@openzeppelin.com](mailto:defender-support@openzeppelin.com).
diff --git a/public/chainlink-cre/cre-execution-flow.png b/public/chainlink-cre/cre-execution-flow.png
new file mode 100644
index 00000000..0ac0bbc4
Binary files /dev/null and b/public/chainlink-cre/cre-execution-flow.png differ
diff --git a/public/chainlink-cre/governance-alert-migration.png b/public/chainlink-cre/governance-alert-migration.png
new file mode 100644
index 00000000..14a8501f
Binary files /dev/null and b/public/chainlink-cre/governance-alert-migration.png differ
diff --git a/public/chainlink-cre/receiver-patterns.png b/public/chainlink-cre/receiver-patterns.png
new file mode 100644
index 00000000..0ceebcb1
Binary files /dev/null and b/public/chainlink-cre/receiver-patterns.png differ
diff --git a/public/llms.txt b/public/llms.txt
index ed1e5f81..4e4f94f4 100644
--- a/public/llms.txt
+++ b/public/llms.txt
@@ -539,16 +539,6 @@ Each ecosystem section lists the smart-contract libraries and language-specific
## Open Source Tools
-- [Symbiotic Templates — Overview](https://docs.openzeppelin.com/symbiotic)
-- [Symbiotic Templates — Setup](https://docs.openzeppelin.com/symbiotic/setup)
-- [Symbiotic Templates — Architecture](https://docs.openzeppelin.com/symbiotic/architecture)
-- [Symbiotic Templates — LayerZero](https://docs.openzeppelin.com/symbiotic/layerzero)
-- [Symbiotic Templates — Chainlink CCV](https://docs.openzeppelin.com/symbiotic/chainlink-ccv)
-- [Symbiotic Templates — Acceptance Hooks](https://docs.openzeppelin.com/symbiotic/acceptance-hooks)
-- [Symbiotic Templates — CLI & API Reference](https://docs.openzeppelin.com/symbiotic/cli)
-- [Symbiotic Templates — Deployment](https://docs.openzeppelin.com/symbiotic/deployment)
-- [Symbiotic Templates — Security](https://docs.openzeppelin.com/symbiotic/security)
-- [Symbiotic Templates — Troubleshooting](https://docs.openzeppelin.com/symbiotic/troubleshooting)
- [Relayer — Overview](https://docs.openzeppelin.com/relayer/1.5.x)
- [Relayer — Quickstart](https://docs.openzeppelin.com/relayer/1.5.x/quickstart)
- [Relayer — Configuration — Overview](https://docs.openzeppelin.com/relayer/1.5.x/configuration)
@@ -633,4 +623,16 @@ Each ecosystem section lists the smart-contract libraries and language-specific
- [UI Builder — Building Adapters](https://docs.openzeppelin.com/ui-builder/building-adapters)
- [UI Builder — Changelog](https://docs.openzeppelin.com/ui-builder/changelog)
- [Role Manager](https://docs.openzeppelin.com/role-manager)
+- [Chainlink CRE — Mapping Your Defender Setup](https://docs.openzeppelin.com/chainlink-cre): Map each kind of Defender Monitor, Action, and Relayer setup to a Chainlink CRE pattern, and see what changes when you move it
+- [Chainlink CRE — Worked Example](https://docs.openzeppelin.com/chainlink-cre/worked-example): Port OpenZeppelin's Defender governance alert to Chainlink CRE, then simulate, deploy, and verify it on Sepolia
+- [Symbiotic Templates — Overview](https://docs.openzeppelin.com/symbiotic)
+- [Symbiotic Templates — Setup](https://docs.openzeppelin.com/symbiotic/setup)
+- [Symbiotic Templates — Architecture](https://docs.openzeppelin.com/symbiotic/architecture)
+- [Symbiotic Templates — LayerZero](https://docs.openzeppelin.com/symbiotic/layerzero)
+- [Symbiotic Templates — Chainlink CCV](https://docs.openzeppelin.com/symbiotic/chainlink-ccv)
+- [Symbiotic Templates — Acceptance Hooks](https://docs.openzeppelin.com/symbiotic/acceptance-hooks)
+- [Symbiotic Templates — CLI & API Reference](https://docs.openzeppelin.com/symbiotic/cli)
+- [Symbiotic Templates — Deployment](https://docs.openzeppelin.com/symbiotic/deployment)
+- [Symbiotic Templates — Security](https://docs.openzeppelin.com/symbiotic/security)
+- [Symbiotic Templates — Troubleshooting](https://docs.openzeppelin.com/symbiotic/troubleshooting)
- [RWA Wizard](https://docs.openzeppelin.com/rwa-wizard): A tool for building real-world asset token projects
diff --git a/src/navigation/ethereum-evm.json b/src/navigation/ethereum-evm.json
index b6d10a60..b3c89e67 100644
--- a/src/navigation/ethereum-evm.json
+++ b/src/navigation/ethereum-evm.json
@@ -844,62 +844,6 @@
"type": "separator",
"name": "Open Source Tools"
},
- {
- "type": "folder",
- "name": "Symbiotic Templates",
- "index": {
- "type": "page",
- "name": "Overview",
- "url": "/symbiotic"
- },
- "children": [
- {
- "type": "page",
- "name": "Setup",
- "url": "/symbiotic/setup"
- },
- {
- "type": "page",
- "name": "Architecture",
- "url": "/symbiotic/architecture"
- },
- {
- "type": "page",
- "name": "LayerZero",
- "url": "/symbiotic/layerzero"
- },
- {
- "type": "page",
- "name": "Chainlink CCV",
- "url": "/symbiotic/chainlink-ccv"
- },
- {
- "type": "page",
- "name": "Acceptance Hooks",
- "url": "/symbiotic/acceptance-hooks"
- },
- {
- "type": "page",
- "name": "CLI & API Reference",
- "url": "/symbiotic/cli"
- },
- {
- "type": "page",
- "name": "Deployment",
- "url": "/symbiotic/deployment"
- },
- {
- "type": "page",
- "name": "Security",
- "url": "/symbiotic/security"
- },
- {
- "type": "page",
- "name": "Troubleshooting",
- "url": "/symbiotic/troubleshooting"
- }
- ]
- },
{
"type": "folder",
"name": "Relayer",
@@ -1348,5 +1292,77 @@
"type": "page",
"name": "Role Manager",
"url": "/role-manager"
+ },
+ {
+ "type": "folder",
+ "name": "Chainlink CRE",
+ "index": {
+ "type": "page",
+ "name": "Mapping Your Defender Setup",
+ "url": "/chainlink-cre"
+ },
+ "children": [
+ {
+ "type": "page",
+ "name": "Worked Example",
+ "url": "/chainlink-cre/worked-example"
+ }
+ ]
+ },
+ {
+ "type": "folder",
+ "name": "Symbiotic Templates",
+ "index": {
+ "type": "page",
+ "name": "Overview",
+ "url": "/symbiotic"
+ },
+ "children": [
+ {
+ "type": "page",
+ "name": "Setup",
+ "url": "/symbiotic/setup"
+ },
+ {
+ "type": "page",
+ "name": "Architecture",
+ "url": "/symbiotic/architecture"
+ },
+ {
+ "type": "page",
+ "name": "LayerZero",
+ "url": "/symbiotic/layerzero"
+ },
+ {
+ "type": "page",
+ "name": "Chainlink CCV",
+ "url": "/symbiotic/chainlink-ccv"
+ },
+ {
+ "type": "page",
+ "name": "Acceptance Hooks",
+ "url": "/symbiotic/acceptance-hooks"
+ },
+ {
+ "type": "page",
+ "name": "CLI & API Reference",
+ "url": "/symbiotic/cli"
+ },
+ {
+ "type": "page",
+ "name": "Deployment",
+ "url": "/symbiotic/deployment"
+ },
+ {
+ "type": "page",
+ "name": "Security",
+ "url": "/symbiotic/security"
+ },
+ {
+ "type": "page",
+ "name": "Troubleshooting",
+ "url": "/symbiotic/troubleshooting"
+ }
+ ]
}
]