The Safe Transaction Service API is the primary off-chain coordination layer for Safe multisig operations. It enables the collection of ECDSA and EIP-1271 signatures, batches confirmations from multiple owners, and provides a unified view of the transaction queue. While the Safe smart contracts operate entirely on-chain, the Transaction Service is the default backend for the official Safe web interface and many ecosystem tools, making its availability and data consistency critical for day-to-day multisig operations.
Protocols
Safe Transaction Service API and Indexing Dependencies
Technical operations guide to the Transaction Service API, covering its role in collecting off-chain signatures, batching confirmations, and its eventual consistency model. Details rate limits, API versioning, known failure modes like indexer lag, and how to operate a Safe directly via SDKs or CLI when the UI is unavailable.
introduction
TRANSACTION SERVICE API AND INDEXING DEPENDENCIES
Introduction
Operational guide to the Safe Transaction Service API, its role in the off-chain coordination layer, and the indexing infrastructure dependencies that affect multisig operations.
The service relies on an indexing layer that ingests on-chain events—such as ExecutionSuccess, ExecutionFailure, and AddedOwner—and maps them to an off-chain database. This introduces an eventual consistency model where a transaction may be confirmed on-chain but not yet reflected in the API response. Common failure modes include indexer lag during periods of high block demand, incomplete event decoding for non-standard Safe deployments, and rate-limiting that can throttle automated systems querying the API. Teams operating high-frequency Safes or algorithmic treasury operations must account for this latency in their confirmation and execution pipelines.
When the Transaction Service or its indexing backend is degraded, operators can bypass it entirely by using the Safe Core SDK or direct contract interaction via CLI tools. This requires constructing the safeTxHash locally, collecting signatures off-chain through a custom coordination mechanism, packing them into the correct (r, s, v) format, and broadcasting the execTransaction call directly to an RPC endpoint. Chainscore Labs helps institutional teams design these fallback procedures, build self-hosted indexing infrastructure, and audit the signature-collection and broadcasting logic to ensure operational continuity independent of the hosted Transaction Service.
TRANSACTION SERVICE API AND INDEXING DEPENDENCIES
Quick Facts
Operational facts about the Transaction Service API's role, consistency model, and failure modes that affect Safe transaction workflows.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
API Role | Collects off-chain signatures, batches confirmations, and provides transaction history | Wallet integrators, custodians, DAO tooling | Map all UI-dependent workflows to direct contract interactions as a fallback |
Consistency Model | Eventual consistency; indexer lag can cause stale transaction states | Algorithmic traders, automated treasury ops | Implement polling with block-confirmation checks; do not rely on API for execution-finality signals |
Rate Limiting | Public endpoints are rate-limited; burst traffic can trigger 429 responses | High-frequency operators, analytics platforms | Self-host a Transaction Service instance or use SDK/CLI for critical operations |
API Versioning | Versioned endpoints under /api/v1/; breaking changes may deprecate older paths | Backend integrations, alerting systems | Pin to a specific API version and monitor the Safe changelog for deprecation notices |
Indexer Lag | Backend indexer can fall behind chain tip, delaying signature and execution visibility | Custodians, multisig operators, monitoring tools | Cross-reference Safe contract events via RPC; do not treat API as a real-time source |
UI Dependency | Official Safe web interface depends on the Transaction Service; API outage blocks UI flows | All Safe users relying on the web UI | Validate direct execution paths via Safe Core SDK, CLI, or Ethers.js against the canonical contracts |
Self-Hosting | Teams can run their own Transaction Service to remove shared-infrastructure risk | Institutional operators, exchanges, large DAOs | Assess infrastructure requirements and run a staging instance before production migration |
technical-context
TRANSACTION SERVICE INTERNALS
Architecture and Data Flow
How the Safe Transaction Service collects, indexes, and serves multisig transaction data, and where its eventual consistency model creates operational risks.
The Safe Transaction Service is the off-chain indexing and coordination layer that powers the canonical Safe web interface and many ecosystem integrations. It monitors a configurable set of EVM chains for SafeSetup, SignMsg, ExecutionSuccess, and other relevant events emitted by Safe proxy contracts, then stores and serves this data through a REST API. Its primary role is to collect off-chain EIP-712 signatures from multiple owners, batch them into a single execTransaction call, and provide a unified view of a Safe's transaction queue and history. Without this service, multisig coordination would require each owner to manually share signatures and for one party to assemble the final payload.
The system operates on an eventual consistency model. When a Safe owner signs a transaction via the web interface, the signature is posted to the Transaction Service and stored in its database. Other owners querying the same Safe will see the updated confirmation count only after the service has processed the write and subsequent reads hit the updated state. This introduces a window where different owners may see stale confirmation counts, leading to duplicated signing attempts or confusion about whether a threshold has been met. The service also re-indexes on-chain events to detect confirmations made directly through the approvedHashes mapping, but this indexing loop introduces additional latency that can range from seconds to minutes depending on chain congestion and service load.
For operators and integrators, the critical dependency is that the Transaction Service is not a consensus component. A Safe transaction is valid and executable the moment enough signatures are collected, regardless of whether the service has indexed them. Teams that rely exclusively on the API for confirmation tracking risk operational blindness during indexer lag, API rate limiting, or service outages. The /v1/safes/{address}/multisig-transactions/ endpoint is particularly sensitive to this, as it reflects the service's internal state rather than on-chain truth. Chainscore can help teams design fallback procedures that query approvedHashes directly from an RPC node and assemble packed signatures without the Transaction Service, ensuring execution capability even when the indexing layer is degraded.
OPERATIONAL IMPACT
Affected Actors and Systems
Wallet Integrators
Teams building custom UIs or integrating Safe into existing wallets are directly affected by Transaction Service API availability and indexing lag.
Impact:
- UI may show stale transaction queues if the indexer is behind.
- Off-chain signature collection fails if the
/multisig-transactions/endpoint is rate-limited or unavailable. - Users may see incorrect nonce suggestions, leading to stuck transactions.
Action Items:
- Implement a fallback to query
Safe.getTransactionCount()on-chain for nonce management. - Cache confirmed transactions locally to avoid redundant API calls.
- Monitor the
/about/health endpoint for indexer status. - Provide a manual "broadcast packed signature" option using
eth_sendRawTransactionwhen the API is down.
Chainscore can review your wallet's fallback logic and API dependency graph to ensure resilience against Transaction Service outages.
implementation-impact
OPERATIONAL RESILIENCE
Failure Modes and Direct Fallback Procedures
When the Transaction Service API is unavailable, lagging, or returning inconsistent data, teams must be able to execute critical transactions directly against Safe contracts without relying on the web interface or hosted API.
01
Indexer Lag and Eventual Consistency
The Transaction Service API is not a real-time source of truth. It relies on an indexing layer that can lag behind the canonical chain state, especially during network congestion or reorgs. A transaction may appear as 'pending' in the UI long after it has been confirmed on-chain. Teams must not treat the API response as authoritative for execution status. Instead, verify the approvedHashes mapping and nonce state directly on the Safe contract via an RPC node. Chainscore can design monitoring systems that cross-reference API data with on-chain state to detect dangerous inconsistencies.
02
Direct Contract Interaction via Safe SDK
When the hosted Transaction Service is down, the Safe Core SDK (@safe-global/protocol-kit) provides a direct path to build and execute transactions. Initialize the SDK with an RPC provider instead of the API endpoint to bypass the indexing layer entirely. This allows you to construct a SafeTransaction object, collect off-chain signatures, and call executeTransaction() directly on the Safe proxy. This fallback is critical for time-sensitive operations like treasury rotations or emergency pauses. Chainscore can help teams build and test SDK-based fallback scripts that are ready to deploy during an outage.
03
Manual Signature Collection and Packed Encoding
Without the Transaction Service to coordinate off-chain signature collection, teams must manage the process manually. Each owner signs the EIP-712 safeTxHash using eth_signTypedData_v4. The resulting signatures must be concatenated into a packed bytes string in the exact order of the Safe's owner array. An incorrect order or missing signature will cause execTransaction to revert with GS020 (owners count mismatch) or GS021 (invalid owner). Custodians and MPC wallets need a pre-tested procedure for this manual assembly. Chainscore can review and validate your manual signature-collection pipeline.
04
Safe CLI for Headless Operations
The safe-cli tool provides a command-line interface that interacts directly with Safe contracts via an RPC endpoint, completely independent of the Transaction Service. It supports transaction proposal, confirmation, and execution, making it a powerful fallback for automated systems and DevOps workflows. Integrate safe-cli into your operational runbooks so that authorized operators can execute a multisig transaction without any web dependency. Chainscore can assist in hardening CLI-based workflows for institutional environments, including secure key management and audit logging.
05
Rate Limiting and API Unavailability
The hosted Transaction Service enforces rate limits that can throttle automated systems during high-frequency operations or incident response. A 429 response can block transaction proposals or confirmation collection at a critical moment. Teams operating multiple Safes or running automated treasury strategies must implement client-side throttling, exponential backoff, and a circuit breaker that fails over to direct SDK or CLI interaction when the API becomes unresponsive. Chainscore can design a resilient interaction layer that gracefully degrades from API-dependent to direct-contract modes.
06
Self-Hosted Transaction Service
For teams that require full control over availability and latency, running a self-hosted instance of the Transaction Service eliminates the dependency on the public API. This requires deploying the service's backend, configuring a dedicated indexer, and pointing your frontend or SDK to your own endpoint. The operational overhead is significant, but it provides a guaranteed SLA for transaction coordination. This is a common pattern for large custodians and DAOs. Chainscore can plan and review a self-hosted deployment architecture tailored to your security and availability requirements.
TRANSACTION SERVICE API AND INDEXING DEPENDENCIES
Operational Risk Matrix
Operational risks introduced by reliance on the Safe Transaction Service API for off-chain signature collection, transaction indexing, and UI availability, and the actions teams should take to maintain operational continuity.
| Area | Failure Mode | Who is affected | Action |
|---|---|---|---|
Indexer Lag | The Transaction Service's eventual consistency model causes a delay between on-chain confirmation and API visibility, leading to stale transaction states. | Wallets, DAO tooling, and automated treasury systems that poll the API for transaction status. | Implement a direct RPC fallback to verify on-chain execution via the Safe contract's |
API Rate Limiting | Exceeding the Transaction Service's rate limits causes HTTP 429 responses, blocking transaction proposals or signature collection during high-activity periods. | High-frequency traders, algorithmic operators, and DAOs executing batch transactions. | Implement exponential backoff with jitter in API clients. For sustained high throughput, deploy a self-hosted instance of the Transaction Service. |
API Version Deprecation | A breaking change or deprecation of an API endpoint version without sufficient migration window causes integration failures. | Custody platforms, institutional wallets, and any backend system with hardcoded API version paths. | Monitor the Safe infrastructure repository for deprecation notices. Abstract API versioning in integration code to allow for quick endpoint swaps. |
UI Unavailability | The official Safe web interface at app.safe.global becomes unavailable due to an outage, DNS attack, or hosting failure, blocking manual transaction initiation. | DAO signers, multisig operators, and teams that rely exclusively on the web UI for transaction creation. | Train operators on CLI tools (safe-cli) and SDKs (safe-core-sdk) to build, sign, and broadcast transactions without the UI. Maintain a documented fallback procedure. |
Data Inconsistency | A bug in the indexing service causes incorrect or missing transaction history, such as a confirmed transaction showing as pending or a missing delegatecall. | Accounting teams, compliance officers, and any system that relies on the API for an auditable transaction log. | Cross-reference API data with on-chain event logs using an archive node or subgraph. Do not rely solely on the API for financial reporting or audit trails. |
Relayer Dependency | A third-party relayer used for gasless transactions experiences an outage or censors a transaction, preventing execution. | Protocols and DAOs using sponsored transaction flows for user onboarding or treasury operations. | Ensure the Safe's threshold can be met by EOAs with ETH for gas. Implement a fallback execution path that does not depend on the relayer. |
Backend Compromise | The hosted Transaction Service backend is compromised, serving malicious transaction data to users, such as altered destination addresses or calldata. | All users of the official Safe web interface and any application that consumes the hosted API without independent verification. | Integrate client-side transaction simulation (e.g., Tenderly) before signing. For high-value Safes, use a self-hosted Transaction Service instance and verify its integrity. |
TRANSACTION SERVICE DEPENDENCY AUDIT
Operator Readiness Checklist
A practical checklist for teams that rely on the Safe Transaction Service API for transaction proposal, signature collection, and execution. Use this to verify operational readiness, identify single points of failure, and ensure you can operate Safes independently when the service is degraded or unavailable.
Confirm that your team can construct, sign, and execute a Safe transaction without the Transaction Service API.
What to check:
- Can you generate a
safeTxHashlocally using the EIP-712 domain separator and correct contract parameters? - Can you collect signatures off-chain and produce a valid packed signature (
r, s, vconcatenation)? - Can you call
execTransaction()directly on the Safe contract via an RPC endpoint?
Why it matters: The Transaction Service is a convenience layer for coordinating off-chain signatures. If it is rate-limited, lagging, or unavailable, your ability to move funds depends on having a direct path to the contract.
Readiness signal: A successful end-to-end test transaction on mainnet using only a script, SDK, or CLI, with no dependency on the Safe web interface or Transaction Service API.
resource-links
SAFE OPERATIONS
Source Resources
Canonical resources for teams that depend on the Safe Transaction Service API for transaction proposal, off-chain confirmation collection, indexing, and operational fallback planning.
06
Chainscore Operational Review
Chainscore Labs can help teams assess Transaction Service dependency risk, design direct-execution fallback procedures, review self-hosted indexing plans, and test Safe operations during API or UI degradation. The useful output is not a generic integration audit: it should include chain-specific endpoint mapping, confirmation and nonce failure-mode tests, contract-state reconciliation checks, alert thresholds for indexer lag, and a documented procedure for executing critical treasury transactions without the hosted Safe interface.
Chains We Build On
Looking to build on a specific blockchain?
We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.
EVM ecosystems
- Ethereum
- Arbitrum
- Optimism
- Polygon
- Avalanche
- Cronos
Non-EVM ecosystems
- Solana
- Sui
- Aptos
- Hedera
- Stellar
- NEAR
Additional ecosystems
- Polkadot
- Cosmos
- TON
- Cardano
- Algorand
- Tempo
Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.
TRANSACTION SERVICE OPERATIONS
Frequently Asked Questions
Common operational questions about the Safe Transaction Service API, its indexing dependencies, failure modes, and fallback strategies for teams that depend on it for multisig coordination.
The Safe Transaction Service is an off-chain indexing and coordination layer that collects, stores, and serves multisig transaction data. It tracks proposed transactions, off-chain signatures, and execution status, enabling the Safe web interface and many ecosystem tools to display pending transactions and confirmation progress.
Why it matters:
- Without it, users cannot see pending transactions or collect signatures through the standard UI
- It provides the
/v1/safes/{address}/multisig-transactions/endpoint that wallets and dashboards query - It maintains an eventually consistent view of Safe state that can lag behind on-chain reality
Operational dependency: Any team building a custom Safe interface, custodian dashboard, or automated treasury tool likely depends on this API directly or indirectly. Understanding its failure modes is critical for operational resilience.
Trusted by Industry Leaders
Delivering blockchain solutions for 5+ years.
We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.
Selected Partners & Clients
“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”
L
Lee Erswell
CEO, Telos Foundation
how to get started
How to get started?
If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.
01
Exploration & Strategy
Define your product goals and choose the right blockchain architecture for your use case.
02
Architecture & Design
Design the smart contracts, tokenomics, and security parameters of your system.
03
Development & Integration
Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.
04
Security & Launch
Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.
Explore More Solutions
Discover our
blockchain development services.
We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.
Book a Call
Start a build
Need a blockchain engineering team?
Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.