Skip to main content

dApp Onboarding

Last updated on June 17, 2024 · Jean-Loïc M.

Adopting IPSProtocol does not require modifying existing dApp code. Hack prevention is layered on top through three steps:

1. Author the Firewall Contracts​

Each business-logic smart contract that needs hack prevention is paired with one Firewall Contract. The Firewall Contract declares the intended behavior of the contract it protects — invariants, allowed call patterns, balance-change bounds, and any other behavioral constraints the dApp wants enforced.

Because Firewall Contracts run in the IPS EVM and have read access to the global state, they can express stateful, contract-aware checks that traditional on-chain wrappers and proxies cannot.

2. Deposit gas tokens into the Firewall Deposit Contract​

Hack prevention is a metered service. Before deployment, the dApp deposits gas tokens into the IPSProtocol Firewall Deposit Contract on mainnet. The deposit balance pays node operators that run the Firewall Client and execute the Firewall Contracts during block building and consensus.

The deposit account also stores the on-chain mapping between business-logic contracts and their Firewall Contracts. Mapping updates are controlled — only the Firewall Layer can settle balance changes after consensus, and only the dApp owner can rotate or upgrade Firewall Contracts.

3. Deploy​

Deploy the business-logic contract to the EVM as usual. Deploy the Firewall Contract to the IPS EVM. Register the mapping in the Deposit Contract. From the next block onward, every transaction touching the protected business-logic contract will be validated against its Firewall Contract before being committed.

dApps that do not opt in continue to operate normally. The Firewall Client only runs Firewall Contracts for dApps that have a deposit and a registered mapping.

Upgrades and rotation​

Firewall Contracts are upgradeable independently of the business-logic contracts they protect. To deploy a new Firewall Contract version:

  1. Deploy the new Firewall Contract to the IPS EVM.
  2. Update the mapping in the Deposit Contract to point at the new address.
  3. The next block uses the new contract.

This decoupling lets dApps tighten their security invariants without re-auditing or redeploying business-logic code, and supports staged rollout (alpha-tier Firewall Contracts gated to a subset of users, for example).

Getting full integration documentation​

The above is the high-level adoption shape. Complete integration documentation — Firewall Contract authoring patterns, IPS EVM differences, deposit-contract APIs, node-operator participation — is available on request.

Contact us to obtain the full integration package.

Last updated on by Jean-Loïc M.