Welcome to the Harpie docs!
  • About
    • Whitepaper
    • What attacks can Harpie prevent?
  • Tech & Security
    • Harpie's Anti-Theft Tech
    • About the Transaction Firewall
    • About the Harpie Vault
    • Security
    • Contracts
      • Deployments
      • Transferer
      • Noncustodial Vault
      • Audit
    • Disclosures & Risks
  • Help
    • Getting Started
      • Get Protected
        • Protecting a token or NFT
        • Setting a withdrawal address
    • My NFTs are stuck in the Harpie Vault, how do I recover them?
    • My Vault is saying I only have 1 NFT recovered, but there should be more
    • FAQ
      • Is Harpie audited?
      • What is Harpie?
      • What is a Trusted Network?
      • What happens when I "Protect" something?
      • What is a Withdrawal Address?
  • Harpie For Enterprise
    • Harpie For Enterprise
      • Background Check API
      • Methods
        • Validate Address
        • Validate Transaction
        • Get Contract Name
Powered by GitBook
On this page
  • Avoiding custodianship
  • Immutability
  • Avoiding single points of failure
  1. Tech & Security

Security

PreviousAbout the Harpie VaultNextContracts

Last updated 1 year ago

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

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.

Read more