Security

We've built Harpie's security with a great amount of care. Three core principles have guided our design:

1. Avoid custodianship of assets

2. Immutability > mutability

3. Avoid single points of failure

Avoiding custodianship

Harpie avoids custodianship by never allowing ourselves to withdraw users' stored tokens from our Vault. Users must explicitly designate a wallet address that's able to withdraw their stored assets. This layer of security makes sure that the most vulnerable side of smart contracts--token transfers--are airtight. Read more.

Immutability

A large issue in smart contract security is the usage of mutable (changeable) variables. Harpie's contracts have immutable code and immutable address parameters (with the exception being the feeController). This ensures that users know exactly where their assets are being sent at all times.

Avoiding single points of failure

Because Harpie is not a decentralized protocol, we utilize admin addresses to handle essential functions, like calling frontrunning functions and reducing user fees. We've designed the system to have multiple admin roles, with each of these admin roles designed to be controlled by different parties and check-and-balance one another. Emergency roles exist to further augment this set of checks-and-balances. By doing so, we reduce the possibility and nullify the damages of any admin address hijacking.