How It Works

Allowing Valid Transactions

1. A user sends a transaction to your protocol (either through your DApp's frontend, or directly to your protocol's smart contract).

2. The Firewall's Pre Execution validation process begins.

3. The Firewall validates the transaction against each of your configured security policies.

4. Once all the policies have cleared the transaction, the Firewall allows the transaction to proceed to your protocol.

5. Your protocol executes the transaction as normal.

6. The Firewall's Post Execution validation process begins.

7. The Firewall validates the transaction against each of your configured security policies.

8. Once all the policies have cleared the changes made by the transaction (such as balance changes etc), execution ends and the transaction is completed.

Reverting Invalid Transactions - Pre Execution

1. A user sends a transaction to your protocol (either through your DApp's frontend, or directly to your protocol's smart contract).

2. The Firewall's Pre Execution validation process begins.

3. The Firewall validates the transaction against each of your configured security policies.

4. One of the policies detects a malicious transaction and reverts it.

5. The transaction is reverted and your protocol remains unharmed.

Reverting Invalid Transactions - Post Execution

1. A user sends a transaction to your protocol (either through your DApp's frontend, or directly to your protocol's smart contract).

2. The Firewall's Pre Execution validation process begins.

3. The Firewall validates the transaction against each of your configured security policies.

4. Once all the policies have cleared the transaction, the Firewall allows the transaction to proceed to your protocol.

5. Your protocol executes the transaction as normal.

6. The Firewall's Post Execution validation process begins.

7. The Firewall validates the transaction against each of your configured security policies.

8. One of the policies detects a malicious change done by the transaction and reverts it.

9. The transaction is reverted and your protocol remains unharmed.