> ## Documentation Index
> Fetch the complete documentation index at: https://docs.phylax.systems/llms.txt
> Use this file to discover all available pages before exploring further.

# Writing Your Own Policies

> Define, implement, and test Solidity assertions for your protocol.

Write your policies as Solidity assertions with `credible-std`, then test them with `pcl` before deployment. You can develop them independently or work with our [forward deployed engineers](./work-with-phylax) to define and implement the policies.

## Set Up Your Project

Start with [Installation](https://docs.phylax.systems/credible/credible-install.md). To try a working project, follow [Run an Example Policy Locally](https://docs.phylax.systems/credible/pcl-quickstart.md), then [Test a Policy's Allowed and Rejected Cases](https://docs.phylax.systems/credible/test-policy-behavior.md).

Keep assertion contracts in `assertions/src/` and their tests in `assertions/test/`. Pin the `credible-std` version used by your project and confirm that your target deployment supports the assertion specification you choose. See the [library reference](https://docs.phylax.systems/credible/credible-std-overview.md) and [published releases](https://github.com/phylaxsystems/credible-std/releases).

## Define the Policy and Its Exceptions

Describe the behavior your policy should reject and the legitimate operations it must allow. Identify:

* The protected contracts, assets, and execution paths.
* The property being checked, including units, thresholds, and any measurement window.
* Approved exceptions, such as migrations, ownership transfers, or large withdrawals.

For example, rejecting every ownership change also rejects an approved transfer. The policy needs enough context to distinguish those cases. The [Use Cases Book](https://docs.phylax.systems/assertions-book/assertions-book-intro.md) provides patterns to adapt to your protocol.

## Implement the Assertion

Inherit from `Assertion` and register the assertion functions in `triggers()`. For Reshiram assertions, call `registerAssertionSpec(AssertionSpec.Reshiram)` in the constructor.

Match the trigger to the property:

* Use `registerTxEndTrigger` for a property that must hold after the complete transaction.
* Use `registerFnCallTrigger` for a check around each matching function call. Its call context is available through `ph.context()`.
* Use the supported token-change or cumulative-flow triggers when the policy concerns token movements or rolling limits.

Use explicit snapshots when comparing state. `_preTx()` and `_postTx()` identify transaction boundaries; `_preCall()` and `_postCall()` identify call boundaries. Read values through `ph.loadStateAt` or `ph.staticcallAt`, and derive storage slots from the actual contract layout.

Keep each assertion focused on one property. Check helper mutability when calling it from a `view` function, and decode events and calldata according to the protocol's interfaces. Use [Triggers](https://docs.phylax.systems/credible/triggers.md), the [Cheatcodes Reference](https://docs.phylax.systems/credible/cheatcodes-reference.md), and your pinned library source for exact signatures.

## Test Allowed and Rejected Transactions

Use `CredibleTest` and register the assertion with `cl.assertion(...)` immediately before the monitored external call. Run the assertion tests with:

```bash theme={null}
pcl test
```

Cover ordinary activity, intended violations, approved exceptions, and threshold boundaries. Confirm that a rejected transaction rolls back its changes, and include a violating transaction that the protocol would otherwise allow. Test batching and alternative entry points where they affect coverage.

See [Testing Assertions](https://docs.phylax.systems/credible/testing-assertions.md) for the test harness and [Testing Strategy](https://docs.phylax.systems/credible/testing-strategy.md) for backtests, fork tests, and recovery checks.

## Review and Deploy

Follow [Review and Deploy Policies](https://docs.phylax.systems/credible/deploy-assertions-dapp.md) to create a release, review its checks, and observe the policy in alerting mode. Investigate unexpected rejections and retest changes before production.

Your team controls policy deployment through its authorized signers. See [Managing Policy Deployments](https://docs.phylax.systems/credible/managing-policy-deployments.md) for authorization. Ethereum protection also requires the agreed [guard and routing integration](https://docs.phylax.systems/credible/dapp-integration.md).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.