---
# System prepended metadata

title: Decentralized Safe API

---

# Decentralized Safe API 

The objective is to leverage ComposeDB on Ceramic Protocol to configure a decentralized the Safe backend. 

### Problem
Currently Safe uses a centralized server for collecting signatures from Safe owners, rendering it open to attack vectors. Given that it stores all proposal information, signatures, and safe configurations, there is little no real protection from this data being compromised. 

Another avenue of concern is information asymmetry for future transactions. By remaining closed-source, prior knowledge on transactions yet to be executed allow for front-running on certain trades to extract value from them beforehand.



## Our Plan
Our proposed solution utilizes following decentralized tools:
* Ceramic Protocol, a decentralized, composable graph database built on
* ComposeDB, a permissionless data-streaming network. 

Node operators choose which data models to host, then automatically sync data between each other to decentralized extendable storage for web3 applications. Applications connect to Ceramic’s decentralized data network via an open API to store, modify, and retrieve data.

The data models used in ComposeDB are analogous to those in NoSQL or MySQL databases. Leveraging the Ceramic protocol allows for any party interested in a given Decentralized Safe’s information to maintain a fully informal replica of the data, creating a more decentralized open architecture.

We have identified specific models of Safe to be used inside of ComposeDB:
* Safe - this model is required to store SAFE information and data, created simultaneously with the Safe itself, and contains owner information, Safe address, active transactions, etc.
* Transaction - a full description of the transaction, essentially a representation of the Safe’s proposal.
* Confirmation - an approval (EIP-712 signature) of a specific transaction awaiting execution in the Safe.
 
By using GraphQL, it becomes possible to list all signatures for a specific transaction, or a transaction for a specific signature which allows for ComposeDB to build a decentralized API for Safe. 



## Architectural Approach
The idea behind the decentralized Safe API is to completely remove the closed backend architecture from the Safe flow which harbors the aforementioned risks. ComposeDB can be used to create a decentralized and permissionless alternative to create an open infrastructure that allows anyone to access and use Safe’s shared data.

Here’s an overview of the current Safe architecture:

![](https://i.imgur.com/Wjb4eAq.png)

Our solution eliminates the central point vulnerability by completely removing any interactions with the Safe backend, moving all interactions to the user’s frontend. Because the data is stored on a set of permissionless open nodes, and it is visible to everyone, it eliminates all blackboxes in the system.

Proposal data, user information, or similar forms of data will be collected on the frontend and directly connected to the distributed database. It becomes impossible to edit the data of another user in the ComposeDB, which means that after the Safe is created, no one can change information about it except for the Safe owners themselves. The same could be said about the proposals and approvals.

![](https://i.imgur.com/1lrGrxn.png)


