Skip to main content
Phylax helps DeFi protocols enforce custom security policies before settlement. Policies are implemented as Solidity assertions, checked by participating builders, and paired with guards on protected operations. Enforcement is made available network-wide via a block builder or sequencer integration. Phylax can support a variety of blockchains, and is currently live on Ethereum and Linea. You can write assertions yourself. We highly recommend working with Phylax sales engineering to find the policies and integration approach that best fit your protocol. This support is included in your Phylax subscription at no additional cost. You can bring existing assertion code or start with a discussion of your protection needs.

Should you use Phylax?

Work through the questions your team will have, from the first call to live protection.

Explore an Example Policy

Optionally run a local example to see how assertions behave.

​
What You Can Protect

Policies can constrain asset outflows, administrative changes, collateralization, oracle deviations, and relationships between balances or positions. The appropriate rules depend on your protocol and its normal operations. For example, a rule that rejects every ownership change would also reject a planned transfer to a new governance contract. Policy design must account for legitimate exceptions as well as harmful behavior. Check out the Use Cases Book, it has patterns and logic for this.

​
How Ethereum Enforcement Works

Builders that agree to run the Phylax enforcement engine evaluate transactions against your circuit breakers and exclude violating transactions from the blocks they build. Your team defines and approves the rules, which are deployed onchain under a signer set that only you control. No other party can activate or change your rules without your authorization. Once you protect functions with Phylax circuit breakers, an onchain guard checks that each protected call executes in a credible block. Calls included in a non-participating builder’s block revert while the guard’s enforcement gate is active. If a transaction interacting with your smart contract and it’s routed to a builder that does not evaluate it, the transaction will revert. This ensures that incoming transactions can only settle if it’s evaluated by the enforcement engine. Protection depends on the agreed policies, covered execution paths, deployed guards, and operational configuration. Learn about Ethereum enforcement and its trust and recovery assumptions.

​
From Evaluation to Operation

Our forward deployed engineers (FDEs) work closely with your team to define, implement, and thoroughly test your circuit breakers. We study your protocol and existing mitigations, then work through the failure scenarios, legitimate exceptions, and thresholds that matter to you. Within the agreed integration scope, we write assertions, prepare contract and transaction-routing changes for your review, and test a replica of your protocol on a fork of Ethereum. We run backtests, test legitimate and violating transactions, investigate false positives, and rehearse recovery. Your team reviews the policies and evidence, approves protocol changes, and controls production signing. We prepare and simulate activation transactions for your signers to authorize and execute, then verify the live protection. Monitoring, incident response, and ongoing policy changes follow the operating plan agreed with your team. Use Prepare for Your Integration to gather the information for that discussion. The Enforcement FAQ covers builder behavior, routing, transaction rejection, and recovery.

​
Technical Documentation

The technical guides remain available throughout evaluation and integration: Ethereum builders can use the builder integration guide. Earlier sequencer designs and workflows live in L2 and Sequencer Integrations.