Firewall Documentation
Home
  • Overview
  • Quick Start
    • Using Function Modifiers
    • Using Proxy Patterb
  • Concepts
  • Configuration
    • Governance
    • Firewall Configuration
    • Policy Administration
  • How It Works
  • Smart Contracts
    • Firewall.sol
    • FirewallConsumer.sol
    • FirewallProxyAdmin.sol
    • FirewallTransparentUpgradableProxy.sol
  • Policies
    • Admin Notary
    • Whitelist
    • Approved Calls
    • Approved Patterns
    • Balance Guard
    • EOA Only
    • Method Block
    • Custom Protector
    • Non Reentrant
    • Combined Policies
  • Addresses
  • Glossary
  • Support
  • FAQ
Powered by GitBook
On this page
  • Allowing Valid Transactions
  • Reverting Invalid Transactions - Pre Execution
  • Reverting Invalid Transactions - Post Execution

How It Works

PreviousPolicy AdministrationNextSmart Contracts

Last updated 1 year ago

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 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 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 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).

  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.

  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.

The Firewall's validation process begins.

The Firewall's validation process begins.

Pre Execution
Post Execution
Pre Execution
Pre Execution
Post Execution