Overview

The Fireblocks Embedded Wallet (EW), formerly Non-Custodial Wallet (NCW), architecture is designed with a minimalistic approach to provide maximum flexibility and ease of use.

Fireblocks provides Android, iOS, and Web SDKs for easily integrating EW functionality into your mobile and web applications. The mobile and web SDKs focus solely on MPC key provisioning, signing, and backup/recovery.

Integration Components

There are three main components required for integrating the Fireblocks EW feature:

1. Client-side application: A mobile or web app with the EW SDK implemented.
2. Backend server: A proxy backend server hosted by the customer with the Fireblocks SDK implemented.
3. Fireblocks: An EW-enabled workspace.

The mobile and web SDKs send and receive data related to MPC key generation and signing through a backend proxy owned by the customer. This gives you an additional layer of security and allows you to customize the solution to fit the needs of your business.

Backend Proxy Server

Security, control, and efficiency are top priorities in software application development. To address these aspects effectively, the Fireblocks EW requires you to implement a backend proxy architecture. This strategy involves introducing an intermediary server between your client application and Fireblocks services.

Why use a backend proxy architecture?

The backend proxy architecture is designed to strengthen the security, control, and efficiency of your interactions with the Fireblocks platform. By employing an intermediary server, you establish an additional layer of protection against unauthorized access and potential threats. This architecture enables you to control the flow of traffic, monitor usage patterns, and optimize performance. Additionally, it provides a flexible framework that adapts to changes in APIs and SDKs.

Benefits of backend proxy architecture

Enhanced security

• Data validation: The backend server validates incoming requests, ensuring they comply with expected formats and preventing malicious input.
• Authorization: User authentication and authorization can be enforced at the backend server, limiting access to authorized clients only.
• IP whitelisting: By only allowing communication from the backend server's IP, you reduce the risk of attack, potential vulnerabilities, and unnecessary access to your Fireblocks workspace.

Control and monitoring

• Rate limiting: The backend can restrict the rate at which requests are sent to our services, preventing misuse or overloading. Learn more about Fireblocks API rate limits and IP whitelisting.
• Logging: Detailed logs of requests and responses provide insights for debugging, auditing, and performance analysis.

Flexibility and adaptability

• SDK updates: You can update the backend server to accommodate changes in SDKs or APIs without requiring immediate changes in your client application.
• API changes: If Fireblocks EW APIs evolve, the backend server can be modified to handle these changes while protecting your application from immediate impacts.

Implementing backend proxy architecture

1. Establish a backend server that intercepts SDK function calls from your client application.
2. When the client application invokes SDK functions, the backend server forwards these requests to the Fireblocks EW API.
3. The backend server receives responses from Fireblocks and relays them back to your client application.
4. Enforce authentication, authorization, and data validation in the backend to ensure secure communication.

Example of EW creation

• The end user wants to provision a new EW via the customer's mobile or web application.
• The customer's backend calls the POST /v1/wallets API endpoint.
• The Fireblocks platform creates a new EW in the relevant workspace.
• Fireblocks responds with the newly created wallet identifier.
• The customer assigns the newly created EW to its end user in the customer's database.
• The user gets a new EW.