Glossary
Last updated
Last updated
A collection of smart contracts that work together to provide on-chain security by applying pre/post execution policies on incoming transactions. For more details, see .
A smart contract that protects against specific attack vectors by performing various checks on incoming transactions. For more details, see .
On-chain protocols (i.e. smart contracts) that use the Firewall to protect their assets and community for malicious actors.
The principal (person, people, or organization) that administers the Firewall. This principal is allowed to perform administrative tasks on the Firewall Consumer - such as changing the Firewall Admin or setting a new Firewall.
A method on a Firewall Consumer smart contract that is protected by the Firewall.
A transaction security life-cycle phase that takes place before a transaction is allowed to reach a protected method on Firewall Consumer smart contract. For most use cases, policies use this phase to examine access control to a Protected Method.
A transaction security life-cycle phase that takes place after a transaction is allowed to reach a protected method on Firewall Consumer smart contract. For most use cases, policies use this phase to inspect and validate state changes on a Firewall Consumer.
The principal (person, people, or organization) that governs the Firewall. Only the Firewall Owner can set which Policies are the Firewall can execute. See for more details.
A smart contract that is both a Firewall Consumer, and a proxy that implements the Transparent Upgradable Proxy pattern. For more details, see .
A smart contract that acts as the administrator of the Firewall Proxy. This is similar to smart contract - with additional methods for administration of a Firewall Proxy.
Each Firewall holds a list of policies that Firewall Consumers can use based on their individual needs. From time to time, Firewall owners may choose to update certain policies, and disable others. This mechanism is provided via approving or disapproving policies. For more details, see .
Some transactions can call multiple contracts, or trigger multiple functions on the same contract - in any order. Each such sequence of calls is considered a vector. Some policies work with a list of approved vectors to only allow specific business logic to take place on the protocol. See for one such use case.