We lost a valued customer last year.
They needed chain abstraction. Managing Safe accounts across multiple chains, and the signing overhead was killing their UX. Every key rotation meant six separate ceremonies. Every guardian update, same thing. Their users were drowning in signatures.
They asked if we had a solution. We said no.
Not because we couldn't build it. Chain abstraction was the 2025 narrative. Everyone was shipping it. We could have done it in weeks. Feature velocity, customer win, done.
But every solution we looked at had the same problem: trusted intermediaries. Relayers you had to trust. Wrapped assets. New points of failure. For infrastructure that secures savings, checking accounts and treasuries? No.
So we told them we didn't have it. They went with someone else.
That one stung.
You second guess it. Maybe we're being too pure. Maybe we're just slow.
But the teams we work with are building neobanks. Real money, real users. If a relayer goes down, if a bridge gets hacked, it's not our problem to solve. It's their users' funds. We can't sell infrastructure we don't control.
Then EIL was announced at Devconnect.
I was skeptical at first. But I read
@yoavw's post on how EIL work under the hood. L1 as source of truth. Voucher system with economic guarantees. No trusted relayers. No new intermediaries.
It clicked.
Suddenly we had a way to build chain abstraction without compromising on what matters.
So we built Safe Unified Account.
Here's what it does:
โข Sign once for operations across multiple L2s (Merkle proof verification)
โข Atomic cross-chain via EIL integration (L1-anchored, not trust-based)
โข No bridges, no relayers, pure cryptographic verification
The flow:
1. Construct UserOps for each chain
2. Arrange in Merkle tree
3. Sign root once
4. Submit with proofs to bundlers
5. Each chain verifies independently
For atomic operations, EIL's voucher system provides economic guarantees through XLP staking/slashing. Same signed voucher that claims funds on source releases funds on destination. Guaranteed by L1, not by trust.
The module is feature complete. Audit pending. We're sharing now to get feedback before we lock it down.
I don't know if we'll get that customer back. Maybe they're happy with what they chose. Maybe the trusted relayer approach works fine for them.
But I know we can finally offer chain abstraction to the teams building on Safe without asking their users to trust what they shouldn't have to trust.
Sometimes saying no is just buying time until you can say yes the right way.