Cryptography-backed digital identities

Digital identities on Bitrated are backed by a public/private key pair. Every user has a public SIN identifier attached to them (representing their public key), and a matching private key that's managed locally by the user.

We use digital signatures to authenticate actions made by users, such as agreeing to a contract, posting a review or updating the profile. The digital signatures are then made available as part of our API.

Our usage of cryptography achieves three primary goals:

Client-side handling of private keys

The Bitrated web interface provides digital identity and smart contracts management using in-browser cryptography. Private keys are fully created, managed and processed using client-side code, and never touch our servers (not even in encrypted/hashed form).

This puts the full control over your identity and funds in your hands – where it belongs.

Protected client-side environment

Since private keys are managed in-browser and are accessible to client-side scripts, we take great care to protecting the integrity of our client-side environment:

Open Source

The source code for our client-side and shared libraries is available for review on our GitHub and can be audited by anyone with a technical background.

Bug Bounty Program

We welcome security audits and offer a bug bounty for responsibly disclosing security issues or breaches in our client-server model.

Our bug bounty program is managed by Crowdcurity. Please refer here for more details.


Email Authenticity

To prevent email spoofing and phishing attacks, our domains are configured with a strict DKIM and SPF policies.

Please note that even with these measures in place, we will never ask for your passwords over email, and it is still important to verify you're on the correct domain and under SSL (look for the green padlock in the address bar) when providing passwords to our web interface.

Private Keys & Passwords Schema

The security schema we use aims to strike a balance between usability and security. Specifically, these are our design motivations and goals:

To achieve that, our passwords and private keys schema involves two separate private keys with varying security properties:

Trustless Server Model

We strive for a security model that requires as little trust as possible on our servers. While we're not there yet, our goal is to have the server-side environment operate as a simple public repository of signed user messages, where the client always considers the server to be potentially hostile and verifies everything locally.

Our current security model ensures that:

In the future, we also plan to:

Public key verification

To authenticate messages from the Bitrated staff, we will provide a digital signature from our Bitcoin address 19AENxshHjdjsQrJfawCaudxaTAaNHxqbd.

To prevent an attacker from modifying our published Bitcoin address, we have permanently embedded it into the Bitcoin blockchain in a way that is nearly impossible to modify, and becomes exponentially more difficult as time goes by.

The public key can be verified by taking the following procedure:

  1. Take the SHA256 of our domain name ("").
  2. Create a Bitcoin address using that hash as the private key (both compressed or uncompressed).
  3. Find the first transaction with that address as its input address.
  4. The output address of that transaction is our public key.

If its ever required to change the public key, the announcement will be signed with the old public key.