How to Test Replay Safety (Complete Guide)

What replay safety actually means in practice

At a high level, a replay happens when a piece of authorization that was meant to be valid once, or only in one context, is accepted again somewhere it should not be accepted. That “somewhere” can mean many things. It can mean the same contract a second time. It can mean a forked chain. It can mean another contract that interprets the same message. It can mean a different execution path with the same signature. It can mean a delayed submission long after the user thought the permission had expired or been used.

This is why replay safety is not just a cryptography topic. The signature may be perfectly valid. The bug is that the system around it does not pin the signature tightly enough to a single intended context. If the contract does not consume a nonce, if the digest does not include the chain ID, if the verifying domain is too weak, if the recipient contract is not bound into the signed payload, or if the state transition does not make reuse impossible, the same proof of intent can be turned into repeated value extraction.

Developers sometimes think replay risk is only about raw transactions on chain splits. That is only one slice of the problem. Modern replay safety matters across:

• Permit-based approvals
• Meta-transactions
• EIP-712 signed orders and typed data
• Bridge messages and withdrawals
• Off-chain authorization flows
• Account abstraction and user operations
• Multisig or admin signatures
• Backend-issued approvals tied to smart contracts

The practical definition is simple and powerful: a valid authorization must not remain valid outside its exact intended scope. If your tests do not prove that, your system is not replay-safe in any meaningful engineering sense.

Why replay bugs matter more than many teams expect

Replay bugs are dangerous because they often turn legitimate user consent into repeated unauthorized outcomes. A user may have genuinely intended to sign something once. The contract can still betray that intent if it makes the signature reusable. That gap between valid signature and valid usage is where replay vulnerabilities live.

They also hide well in otherwise polished systems. A protocol can have clean UI, strong brand, and good core logic, yet still fail replay safety because its authorization envelope is too weak. This makes replay testing especially important for teams building signature-heavy workflows. As Web3 moves further into typed data, permit systems, aggregators, relayers, intents, and account abstraction, more value flows through signatures rather than direct transactions. That means more chances to get replay scope wrong.

How replay bugs actually happen

Replay failures usually come from one of two root causes. Either the signed payload does not carry enough context, or the contract does not consume and invalidate that context correctly after use. In real systems, both problems often coexist.

Missing context inside the signed message

The most common replay design mistake is under-specifying the signed payload. If a signature only covers “approve X amount” but does not bind that approval to a specific chain, specific contract, specific nonce, and sometimes a deadline, it can travel farther than intended. It becomes a reusable ticket instead of a one-time instruction.

Context that is commonly needed includes:

• Signer address
• Recipient or spender
• Amount or action parameters
• Nonce
• Chain ID
• Verifying contract
• Deadline or valid-after / valid-until window
• Action-specific fields like token address, order ID, route, or bridge domain

If one or more of those pieces is missing, an attacker may be able to reuse the same message in a nearby but harmful context.

Nonce consumption failures

Nonces are the workhorse of replay protection. But having a nonce field in the message is not enough. The nonce must be checked, must correspond to the correct signer or scope, and must be consumed in a way that prevents the same authorization from succeeding again. Teams sometimes hash the nonce correctly but forget to increment it at the right time. Others share a nonce across flows that were meant to be independent. Still others consume a nonce too late, after an external call that creates surprising re-entry or inconsistent failure behavior.

In other words, replay safety is not “we used a nonce somewhere.” It is “the nonce makes reuse impossible along every realistic execution path.”

Cross-contract replay

A signature may be valid on the intended contract and also valid on another contract that uses the same hashing scheme or verifier assumptions. This is a classic outcome when developers forget to bind the verifying contract address into the signed domain or message. The signature becomes portable across contracts that should not share trust boundaries.

Cross-chain replay

If the authorization does not incorporate chain-specific context, it may succeed on more than one network. This is especially important when teams deploy similar contracts across rollups, appchains, L2s, testnets, or forked environments. A signature intended for one domain can leak into another if chain binding is weak or missing.

Replay after the user thinks the action is over

Some of the ugliest replay bugs happen because a user believes a permission has been used up, but the system never actually marks it as spent. The protocol may have partially succeeded, or succeeded on a different route than expected, while leaving the underlying authorization reusable. Attackers love these half-closed doors because they look harmless until the second execution happens.

Where replay risk appears in modern smart contract systems

Replay safety is not only a concern for low-level transaction formats. It appears anywhere a signature or serialized message is accepted as authority.

Permit flows and signature-based approvals

Permit-style flows are convenient because they save users gas and reduce friction. They are also prime replay territory because they move spending authorization into signature land. If the nonce logic is wrong, the domain separator is weak, the deadline is ignored, or the spender field is not checked tightly, the same signed intent can turn into repeated or cross-context approvals.

Meta-transactions and relayer systems

In meta-transaction systems, the user signs an instruction and a relayer submits it. This pattern expands the replay surface because more infrastructure sits between user intent and execution. The relayer may queue, reorder, duplicate, or resubmit. If the contract does not track intent consumption correctly, one signed message can become multiple actions.

Off-chain orders, intents, and matching engines

Protocols that rely on off-chain signed orders need especially careful replay handling. A signed order may be partially fillable, cancelable, replaceable, or one-time-use depending on protocol design. If the fill accounting is weak or the cancellation and nonce model is poorly scoped, replay issues become economic exploits rather than merely formal correctness bugs.

Bridge messages and cross-domain messaging

Bridges and message-passing systems are replay-sensitive because the same message often crosses domains that do not share state directly. Teams must prove that a withdrawal message, relay proof, or message payload cannot be consumed twice, cannot be replayed into another lane, and cannot be reused after finalization assumptions change.

Admin signatures and privileged operations

Some systems use signatures for emergency actions, allowlists, mint permissions, claims, or governance shortcuts. These tend to be high-impact because the authorized action is powerful. A replay bug here can escalate quickly into repeated minting, repeated claims, repeated upgrades, or repeated role grants.

Account abstraction and user operations

Account abstraction increases flexibility but also increases replay surface. Bundlers, paymasters, validation logic, and operation hashes create more moving parts. Teams need to test replay assumptions across validation, simulation, mempool behavior, bundling, and execution, not just inside one happy-path function.

The building blocks of replay-safe design

Good replay testing starts with good replay design. If the design is vague, the test suite becomes vague too. The strongest engineering pattern is to explicitly identify the protections you rely on and then write tests that prove each one matters.

Nonces

A nonce is the most recognizable replay control because it distinguishes one authorization from the next. But nonce design is more nuanced than many teams realize. You need to choose scope carefully:

• Global per-signer nonces are simple and strong, but can be operationally rigid.
• Per-function or per-channel nonces add flexibility, but increase complexity.
• Bitmap or unordered nonce schemes can help order-based systems, but must still close reuse paths.

Your tests should mirror the chosen model. If your nonces are unordered, test replay across multiple bit positions and duplicate consumption attempts. If your nonces are sequential, test skipping, reuse, out-of-order attempts, and stale signatures after increment.

Domain separation

Domain separation binds signatures to a specific protocol context. In typed-data systems, that often includes name, version, chain ID, and verifying contract. The purpose is not cosmetic. It is to stop a valid signature from traveling into a different environment that interprets the same fields.

Developers should test domain separation by intentionally trying to reuse a valid signature on a sibling contract, a forked deployment, or an environment with altered domain data. If it still works, the system is telling you your domain boundary is not real.

Chain binding

Chain IDs matter because similar contracts frequently exist on multiple networks. A signature intended for one chain must fail on another unless the protocol has a deliberate and safe cross-chain design. This is particularly important for L2-heavy deployments and for projects with parallel testnet and mainnet environments where careless tooling can make reuse bugs easier to miss.

Contract binding

The same authorization should not be usable by another contract unless that is explicitly intended. The verifying contract address is one of the simplest and most powerful replay boundaries. Test it as if you expect it to fail, because if it does not, you have portability where you wanted specificity.

Deadlines and validity windows

Deadlines are not a replacement for nonces, but they reduce replay window length. A signature without expiration can float indefinitely until conditions favor the attacker. When deadlines exist, tests should verify strict expiration and should check edge cases around block timestamp assumptions and off-by-one behavior.

State consumption and one-way transitions

The contract must move into a state where reuse is impossible. That may mean incrementing a nonce, marking an order as filled, marking a claim as used, or consuming a message ID. This state transition is often more important than the signature math itself. Many replay bugs are really state-machine bugs disguised as signature bugs.

The developer mindset you need before you write tests

Replay safety is easier to test when you stop thinking like an implementer and start thinking like an adversary. Your job is not to prove the happy path works. Your job is to prove the signed intent dies everywhere it should die.

That means asking questions like:

• Can the same bytes succeed twice?
• Can different bytes with the same semantic meaning bypass the nonce model?
• Can the same signature succeed in another deployment?
• Can a relayer resubmit after timeout or partial failure?
• Can a fork or shadow environment reuse a message?
• Can the user think they canceled while the protocol still accepts the old message?

This mindset matters because replay bugs rarely announce themselves through obvious test failures unless you deliberately build the negative cases.

A step-by-step workflow for testing replay safety

The most effective replay testing strategy is layered. Start by mapping the authorization surface, then build fixtures around each trust boundary, then write targeted negative tests that attack those boundaries one by one.

Step 1: Map every place your system accepts off-chain authority

Begin with an inventory. Many teams only test the one signature path they are thinking about, while missing others nearby. Make a concrete list:

• Permit functions
• Meta-transaction entrypoints
• Typed-data orders
• Admin-signed actions
• Claim authorizations
• Bridge message verifiers
• AA validation hooks

If a component accepts signature-derived authority, it belongs in the replay map.

Step 2: Write down the intended scope of each authorization

For each flow, write the exact intended bounds in plain language. Example:

• This permit is valid once.
• This order is valid for this chain only.
• This bridge message can be consumed only by this receiver contract.
• This meta-transaction is valid only until a specific deadline.
• This admin signature authorizes exactly one role grant to exactly one address.

These plain-language statements become your test oracle. If you cannot state the intended scope clearly, you will struggle to test it clearly.

Step 3: Identify the fields that enforce those boundaries

Once the intended scope is clear, identify the exact fields responsible for enforcing it. That usually means nonce, chain ID, deadline, target contract, signer, recipient, amount, order ID, or message ID. If a boundary exists conceptually but no field enforces it, you just found a design smell before writing a single test.

Step 4: Build fixtures that let you vary one boundary at a time

Good replay tests depend on good fixtures. You want helper functions that can generate a valid signature and then let you mutate one aspect cleanly. For example:

• Same signature, same contract, second execution
• Same payload, different chain context
• Same payload, altered verifying contract
• Same signer, incremented nonce
• Same payload after deadline
• Same payload with altered recipient or amount

Test infrastructure matters here. When simulations become heavier across multi-chain or fork-based scenarios, scalable compute can be relevant for serious development workflows. In that builder context, a tool like Runpod can be useful for larger simulation or CI workloads, especially when your replay suite spans complex environments.

Step 5: Write negative tests before edge-case optimizations

Replay safety lives in negative testing. Your first test should not be “the signature succeeds.” Your first test should be “the exact same signature fails when reused.” Then branch out:

• Fails on second use
• Fails with wrong chain
• Fails with wrong contract
• Fails after deadline
• Fails after cancellation
• Fails after fill or partial fill beyond allowance
• Fails when a key field is mutated

Step 6: Test partial failure and revert paths

Many replay issues hide in unhappy flows. Suppose a call partially succeeds, then reverts externally, or updates state in the wrong order. Does the nonce remain reusable? Did a fill amount update without consuming the authorization fully? Does a relayer retry create a second success? These are subtle but vital questions.

Step 7: Test across deployments, forks, and simulated alternate chains

Replay safety is not complete until you prove the same authorization cannot escape the deployment it belongs to. Use simulated chain contexts, duplicate deployments, or forked environments to validate this. A signature that is safely one-time on one contract but portable to its clone is still a replay problem.

What good replay tests look like

Good replay tests are narrow, explicit, and adversarial. They do not merely assert a revert. They explain why the revert must happen and which boundary was violated. They also make it easy to see what would break if a developer later weakens the hashing logic or nonce model.

Test pattern 1: same signature twice

This is the foundational replay test. A valid authorization succeeds once, and the identical call fails on the second attempt. If this test fails, your replay posture is not mature enough to trust any higher-level assurances.

The important idea is not the exact framework syntax. It is that the test proves one-time use against identical input. From there, you build outward.

Test pattern 2: wrong chain context

Generate a valid signature in one chain context, then attempt to use it in another. In multi-network deployments, this is essential. If the contract uses proper domain separation and chain binding, the signature should fail cleanly.

Test pattern 3: wrong verifying contract

Deploy a second contract with the same interface and attempt to replay the signature there. This is one of the fastest ways to catch missing verifying-contract binding in EIP-712 style flows.

Test pattern 4: boundary around expiry

Test just before the deadline, at the deadline, and just after the deadline according to your protocol’s intended semantics. Off-by-one misunderstandings here are common, especially when teams assume timestamps in slightly different ways across backend signing logic and on-chain checks.

Test pattern 5: mutate one field and reuse the signature

Try changing recipient, amount, spender, token, or target while reusing the original signature. These tests catch under-hashed message formats and missing parameter binding. If a signature authorizing one thing can be transformed into another thing without invalidation, you have a payload integrity issue that is tightly related to replay safety.

Test pattern 6: partial fills, cancellations, and order state

For order-based systems, replay testing must follow the actual business rules. If an order is partially fillable, replay safety means “no fill beyond the intended remaining amount,” not necessarily “no second fill ever.” That means your tests must validate the precise state machine, not merely duplicate-call rejection.

Red flags that often signal replay weakness

You can often detect replay risk early by reading the design critically. Warning signs include:

• Signed messages without nonces
• Global nonces used inconsistently across unrelated flows
• EIP-712 style systems that omit chain ID or verifying contract binding
• Permit or order signatures with no deadline
• Message hashes that omit recipient, target, or critical action parameters
• Cancellation flows that do not touch the underlying replay boundary
• State updates that occur only after risky external calls
• Tests that prove success once but never prove failure on reuse

Simulation tools and testing strategies that actually help

Replay safety benefits from both unit-level tests and system-level simulation. Unit tests catch local mistakes. Simulations catch context mistakes. You need both when the protocol spans multiple contracts, relayers, or networks.

Unit tests for boundary enforcement

Unit tests are the fastest place to prove nonce consumption, deadline checks, signature invalidation, and field binding. They should be dense and adversarial. A good replay unit suite often looks repetitive, and that is a strength. Repetition across boundaries is exactly what closes reuse paths.

Integration tests for realistic flows

Once the local logic is sound, integration tests matter because real protocols compose. A user signs off-chain, a relayer forwards, an execution path touches multiple contracts, and a backend may store state independently. Replay bugs often appear where those boundaries meet.

Fork tests and shadow environments

Fork-based testing is useful when you want to examine how your authorization behaves in a more realistic environment. It is especially relevant for protocols integrating existing tokens, permit flows, bridges, or relayer systems that already live in the wild. Replay assumptions can become more fragile when external components behave differently than your mocks.

Fuzzing around boundary conditions

Replay safety benefits from fuzzing because many bugs live at the edges. Nonce values, deadlines, altered fields, partial fills, and serialized payload shapes all produce combinations that human-written tests can miss. Fuzzing will not replace thoughtful replay design, but it is excellent at surfacing cases where your assumptions are too narrow.

Adopt a property-based mentality even without full formal methods

The key replay property is easy to express: once an authorization is used or invalidated, all future attempts in all unintended contexts must fail. You do not need a full formal verification pipeline to think this way. You can encode these expectations as repeated properties in your test suite and get a lot of the value of formal reasoning through disciplined negative testing.

Developer practices that make replay bugs less likely

Testing is crucial, but development habits matter too. The strongest teams reduce replay risk before the tests even run.

Write scope in specs, comments, and reviews

Before coding a signature flow, write one sentence describing its valid scope. Example: “This authorization is valid once, for this chain, for this contract, for this recipient, until this deadline.” That sentence should show up in design docs, PR review, and tests. It keeps everyone aligned on what replay safety means for that flow.

Prefer standard patterns where possible

Teams get into replay trouble when they invent custom signing formats without a strong reason. Standardized patterns are not automatically safe, but they reduce surprise and make it easier for reviewers and auditors to spot deviations. The more custom your authorization envelope becomes, the more aggressively you need to test it.

Do not mix scopes carelessly

A common design smell is using one nonce space or one signature format for many conceptually different actions just because it seems convenient. Sometimes this is fine. Often it creates confusing coupling that makes replay reasoning harder. Scope simplicity is a real security feature.

Review state update ordering with replay in mind

Ask not only “does this work?” but “when exactly is the authorization consumed?” If state is updated too late, a second path may sneak through. If it is updated too early, failed operations may invalidate legitimate retries unexpectedly. Good replay design is also good state-machine design.

Separate user intent from transport assumptions

Relayers, bundlers, and message carriers are transport layers. They should not be part of the replay trust model unless deliberately designed that way. Your signed intent should remain safe regardless of relayer behavior, duplicate submissions, or network retries.

Practical replay scenarios every serious team should test

Scenario 1: Permit replay on same contract

The user signs a permit to approve spending. The first call succeeds. The second call with the exact same signature should fail. If it does not, the spender has a reusable authorization primitive, which is unacceptable for a one-time permit model.

Scenario 2: Same signature on a cloned deployment

The contract is deployed on two networks or two addresses with similar behavior. A signature intended for Contract A must fail on Contract B unless the system explicitly intends cross-deployment portability. This scenario catches weak domain separation faster than many code reviews do.

Scenario 3: Bridge withdrawal message consumed twice

A bridge message proves a withdrawal or transfer. The protocol must guarantee that once it is consumed, the same proof or message ID cannot be used again through the same path or an alternate receiver path. This is classic high-impact replay territory.

Scenario 4: Relayer retries after timeout

The relayer sees uncertainty and retries the same signed instruction. Your protocol must make that retry harmless if the action already succeeded or was consumed. Duplicate submission is normal in real systems. Safety means duplicates do not become double execution.

Scenario 5: User cancels, old signature still accepted

Some systems let users cancel orders or approvals off-chain or on-chain. Test that the old signed payload truly dies after cancellation. Many replay bugs come from cancellation systems that update UI or backend state but do not actually close the on-chain acceptance path.

Scenario 6: Account abstraction validation mismatch

In AA-style systems, replay assumptions may depend on entry points, operation hashes, validation logic, or paymaster interactions. Test the same operation against alternate bundling or validation contexts. If it succeeds where it should not, your replay boundary is incomplete.

How auditors and strong reviewers think about replay safety

Good reviewers do not ask only “does the signature verify?” They ask “what exact boundary is this signature supposed to respect, and what prevents it from escaping?” They trace the path from user intent to hash to verifier to state update to repeated attempt. Then they attack each assumption.

You can borrow that mindset in internal review:

• What is the trust boundary?
• What fields enforce it?
• Where is one-time use guaranteed?
• What happens after partial completion?
• Can a sibling deployment or alternate context reuse this?
• Can the user revoke or replace the authorization safely?

This mindset is useful even if you later pursue external auditing. Better internal replay reasoning produces better audits because it gives reviewers less ambiguity to untangle.

How to structure your test suite so replay bugs stay hard to reintroduce

Replay regressions often appear after refactors. A team changes hashing structure, swaps a domain separator helper, introduces a new proxy deployment pattern, or modifies nonce scope for UX reasons. Suddenly old guarantees weaken. The best defense is to make replay tests easy to locate, easy to understand, and hard to remove casually.

Group tests by replay boundary, not only by function name

A test suite organized around “nonce tests,” “chain separation tests,” “verifying contract tests,” and “deadline tests” makes replay logic more visible than a suite organized only by entrypoint. Boundary-based grouping also makes review easier because you can immediately see which protections exist and where gaps remain.

Use explicit regression-style test names

Names like “rejects signature reused on sibling contract” or “fails after nonce consumption despite identical calldata” are more valuable than generic names like “replay check.” The clearer the name, the more likely future developers are to understand what real attack path the test is defending against.

Keep signing fixtures readable

If your signing helpers are opaque, replay bugs hide inside the test harness itself. Favor fixtures that expose domain fields, nonce inputs, deadlines, contract targets, and chain context explicitly. You want testers to be able to mutate one thing and understand exactly what changed.

Operational security around replay-sensitive development

Replay testing is a developer practice, but your operational setup still matters. Teams that work across multiple chains, staging environments, forks, and signing devices should keep those environments clean and intentionally separated. Confusing deployment IDs, stale typed-data domains, or accidental reuse of staging assumptions in production can make replay bugs more likely or harder to notice.

For teams handling meaningful production deployment signing, device-backed signing can still be relevant as part of broader operational discipline. In that context, a solution like Ledger can be useful for stronger key isolation. It does not solve replay logic, but it supports better signing hygiene around the systems where replay-sensitive flows are built and operated.

Common mistakes teams make when testing replay safety

Mistake 1: Testing success once and calling it done

Replay bugs live in reuse, not in first success. A green happy-path test says almost nothing about replay safety by itself.

Mistake 2: Never testing cross-context reuse

Teams often test only the intended contract on the intended chain. That misses cross-contract and cross-chain replay, which are exactly the contexts where weak binding shows up.

Mistake 3: Using nonces without thinking through scope

Nonces are not magic. A badly scoped nonce model can still permit surprising reuse, cancellation issues, or cross-flow interference.

Mistake 4: Treating deadlines as optional polish

Long-lived signatures are replay-friendly by default. Deadlines narrow exposure and deserve explicit edge-case tests.

Mistake 5: Forgetting that replay is often a state-machine bug

Many teams focus on hash correctness while ignoring how fills, claims, cancellations, or retries update state. That is where repeated execution often sneaks back in.

Mistake 6: Letting frontend or backend assumptions stand in for on-chain guarantees

A UI saying “order used” or a backend flag saying “message consumed” is not a replay control unless the on-chain acceptance path agrees. Users do not get paid back because the dashboard felt correct.

A practical replay-safety checklist for developers and reviewers

Tools, workflow, and learning path

Replay safety gets easier when you build on strong fundamentals and a disciplined toolchain rather than trying to reason from memory every time.

Build the knowledge base first

If you want to reason well about replay risk, start with the basics of signatures, transaction context, contract state transitions, and access control. The best place to lock those in is Blockchain Technology Guides. Once the fundamentals are steady, move deeper into Blockchain Advance Guides for more complex contract and protocol tradeoffs.

Screen dependencies and unfamiliar contracts

Replay bugs are not only about your code. They can also appear in systems you integrate. Before trusting unfamiliar tokens or contracts in production assumptions, start with a quick screen using the Token Safety Checker. It is not a replay-specific tool, but it helps build the broader contract-discipline mindset that good replay engineering depends on.

Use research workflows when systems get broader

As your protocol surface expands, so does the value of better behavioral research. In contexts where wallet behavior, cross-deployment activity, or multi-chain protocol observation matter, a research platform like Nansen can be relevant for broader investigation. It will not replace contract tests, but it can help teams understand how signed flows are actually used in the wild.

A 30-minute replay-safety review playbook

If you need a fast but serious review before merging or before handing code to an auditor, use this playbook:

Conclusion

The best way to think about replay safety is this: every signed intent should have a sharply defined boundary, and your code should prove that boundary survives reuse attempts, altered context, and operational messiness. If the same authorization can leak across contracts, chains, times, or repeated calls, then the user’s original consent has become larger than intended, and that is the essence of replay risk.

Replay safety also rewards discipline. It is not a flashy feature, but it is the kind of invisible correctness that separates production-ready protocols from brittle ones. Good replay design starts with clean scope, depends on precise context binding, and matures through negative tests that attack every plausible reuse path.

Keep the prerequisite reading on Selective Selling Restrictions Explained in mind because both topics teach the same deeper lesson: safety comes from understanding how control surfaces behave under adversarial pressure, not from trusting the happy path. Strengthen your fundamentals through Blockchain Technology Guides, go deeper with Blockchain Advance Guides, use the Token Safety Checker when unfamiliar contracts enter your workflow, and Subscribe if you want ongoing developer-focused security notes and workflow updates.

FAQs

References

Official documentation and reputable sources for deeper reading:

• EIP-155: Simple replay attack protection
• EIP-712: Typed structured data hashing and signing
• EIP-2612: Permit extension for ERC-20
• OpenZeppelin Contracts Documentation
• TokenToolHub: Selective Selling Restrictions Explained
• TokenToolHub: Token Safety Checker
• TokenToolHub: Blockchain Technology Guides
• TokenToolHub: Blockchain Advance Guides

Final reminder: replay safety is never “done” because you verified a signature once. It is done only when reuse fails everywhere it should fail. Revisit the prerequisite reading on Selective Selling Restrictions Explained, keep strengthening your baseline through Blockchain Technology Guides and Blockchain Advance Guides, use the Token Safety Checker when external contracts enter your workflow, and Subscribe if you want ongoing security notes, checklists, and developer playbooks.