Keeping your assets safe.

Security is a critically important component of our service. Friendowment employs (a growing) suite of key controls to protect you and your information.


All public-facing resources (e.g., our primary application and our marketing site) are published only via HTTPS with well-configured TLS certificates. You can verify the effectiveness of this control by visiting Qualys SSL Labs and entering our sites there. We target a configuration that results in (at minimum) an 'A' rating according to that assessment.

Password Hashing

User passwords are hashed using the scrypt key derivation function. This ensures that even in the event of a database compromise (which we also protect heavily against), user passwords will not be revealed.

Service Architecture

Services are deployed in a multi-tier server environment. We rely heavily on micro-services that minimize our potential attack surface (e.g., by including only the minimum required components for the services to operate securely). Services that interact with Ethereum private keys are separated by multiple layers from external components. Additionally, our applications are designed to ensure that private keys never transit directly public-facing infrastructure (e.g., keys are generated, stored, and processed on applications deployed on servers that are multiple tiers away from the Internet).

Data Encryption

Particularly sensitive data (e.g., Ethereum private keys) is encrypted by the application (i.e., not using just database or file system encryption) using AES with 256 bit keys. It would be accurate to call this "bank-level" encryption, although we tend to dislike that description as it implies a standard which does not necessarily provide the highest level of security. Friendowment is committed to providing the most relevant and effective level of security available.

Development Philosophy

Friendowment intentionally favors programming languages and frameworks that promote responsible security design decisions (e.g., prepared statements and strong/static types). We also prefer solutions that are open source with dynamic and dedicated communities over closed source solutions that by their nature are less scrutinized and potentially more susceptible to shallow (and/or obscure) flaws.