Ramper Architecture

Scalable & user-friendly non-custodial wallet infrastructure

At Ramper, it is our paramount priority to enable our users with wallet signing operations at scale while guaranteeing the security of the private wallet keys. We have designed and implemented our data management system described below according to those parameters.

Data management

When a Ramper user is created, a number of things happen on the user’s local device (mobile/web browser):

1. A new wallet (public address + private key) is created
2. The private key is encrypted with a machine generated high entropy Data Encryption Key (DEK), and an envelope encryption is performed (detailed in #3 and #4)
3. DEK is sent to a third party (currently AWS KMS) to be encrypted with a Customer Master Key (CMK)
4. The encrypted private key (encrypted by DEK) and the encrypted DEK (encrypted by CMK) are then stored in Ramper’s cloud infrastructure (GCP/Firebase)

Signing transactions

When a Ramper user needs to sign a transaction, the following operations are performed on the user’s local device to facilitate it:

1. User is authenticated by Ramper
2. User retrieves the encrypted DEK and private key pair from Ramper DB
3. User sends the encrypted DEK to the KMS, which verifies the user’s credential against Ramper’s infrastructure via AWS Cognito + Firebase Auth before using the CMK assigned to the user to decrypt and send back the DEK
4. The private key is decrypted by DEK
5. A transaction is signed with the private key

Third-party KMS

The involvement of the third party (KMS run on a separate AWS account) introduces the following characteristics:

1. There is a clear separation of encrypted user information and the method to decrypt it. It would take both of the industry leading cloud infrastructures (AWS and GCP) to be compromised, as well as our authentication system, for a user’s data to be exposed.
2. KMS is configured in a way that only the authenticated user is able to decrypt a given private key. This means Ramper, or anyone at the company, never has the ability to reconstruct a user’s private key, therefore being able to sign transactions on a user’s behalf. This makes our wallets “non-custodial”
3. There is no private key information stored on a user’s local device (such as Metamask or Terra Extension) or a piece of paper (mnemonic key) that need to be “recovered” in a loss event. If a user has forgotten their auth credential, one would be able to recover their account access through a familiar method, and as long as a user can authenticate their identity against Ramper, their private key will be there in the cloud.

Performance

One of our core areas of focus in implementing this design was performance. Our system supports up to 15+ million (signing) transactions per day with plans to rapidly scale this further.