Safe{Core} Infrastructure
The Safe{Core} Infrastructure consists of the following services:
Architecture
Safe{Wallet} uses these services to offer functionality to end customers via the web and mobile applications. The Safe Client Gateway (opens in a new tab) acts as a facade between the end customer and the Safe{Core} services and the Safe Config Service (opens in a new tab) stores all supported networks and chain-specific variables.
Safe's production setup consists of several instances of the Transaction Service orchestrated by the Config Service, which are later consumed by the Safe Client Gateway. The Events Service notifies the Safe Client Gateway when new events are indexed, helping to improve the user experience.
Integration Flow for Safe{Wallet} and Safe{Core}
- The Client Gateway leverages the Config Service to find the Transaction Service instance required for a specific request.
- The Client Gateway forwards the request to the specified Transaction Service instance for the supported networks (determined by the Config Service).
- The Client Gateway transforms, aggregates, and caches information from the Config and Transaction Services, optimizing data for Safe's web and mobile clients.
- The Event Service provides information to the Client Gateway when the Transaction Service indexes an event using webhooks. The Client Gateway is then responsible for providing this information to the end clients.
Even though the Config Service and Transaction Service instances are reachable by clients that aren't the Client Gateway, this may change in the future. The Client Gateway is the outermost component of the Safe infrastructure and should be the single point of communication with any front-end client.
Rate limits
All Safe{Core} Infrastructure services have a rate limit of 5 requests per second.
Running locally
Safe Infrastructure (opens in a new tab) repository and the running services locally (opens in a new tab) guide show how to run Safe's infrastructure (Safe{Wallet} (opens in a new tab) and Safe{Core}). Note that these documents are examples of how these services run, and the configuration should adapt to the needs of a specific use case.