Executive Summary
Pipes is an encrypted coordination layer for Gnosis Safe signers. It replaces Telegram, Discord, and Signal with a communication channel that is operator-blind (the relay cannot read messages), and automatically rotates when signer sets change on-chain.
The encryption relay is already running on bare metal, processing real user traffic. The consumer proof-of-concept, NFTFAX CHAIN, a collaborative art relay game (see: nftfax.app), launched on Base with live contract at 0xcC121BF9E3a13d03EACd55E15495e3E8De61fac5. This GIP asks for $65,000 to audit the relay, build the Safe module integration, add Gnosis VPN transport, and release Pipes as open-source infrastructure for every DAO on Gnosis Chain.
The timing is right: GIP-153 (EEZ) is in vote, GIP-154 ($15m/year core funding) is in Phase 2, and the Gnosis forum is actively discussing what infrastructure the ecosystem needs. Pipes answers that question with working code: not a roadmap, not a whitepaper, but a live protocol that needs hardening to serve the DAOs that already depend on Gnosis Safe.
The Problem
Gnosis Safe is the gold standard for on-chain execution. Thousands of DAOs use it to secure tens of billions in treasury value. But the coordination that precedes execution, which includes discussing the payload, confirming who will sign, and tracking quorum readiness, happens over Discord, Telegram, and Signal.
These channels:
- Leak metadata: who is coordinating, when, how frequently, and with whom.
- Are not cryptographically bound to signer identity. A compromised Discord account can impersonate a signer.
- Require manual offboarding. When a signer rotates out, someone must manually remove them from the group chat. In practice, this rarely happens.
- Introduce a third-party dependency. The DAO does not control the infrastructure. The platform operator is a witness and a potential point of failure, subpoena, or deplatforming.
The gap between Safe’s execution security and the coordination layer’s ad-hoc vulnerability is the most significant unsolved problem in DAO operations. We secure the vault with titanium. We leave the blueprints in a public coffee shop.
The Solution
Pipes is a coordination channel with six properties:
-
Access is cryptographically gated, with no new NFT required. For DAO Safe signers, identity is verified directly against the Safe contract:
getOwners()returns the current signer set, and only those wallets can read or write tosafe.42@pipe. No separate token, no mint, no additional onboarding. Membership is the intersection of two things: the Safe’s currentgetOwners()set, and a SIWE-style signed acceptance from that signer naming that specific Safe. Being listed as an owner is necessary but not sufficient, because Safe owner assignment is permissionless at creation: anyone can name any address as an owner without consent. The signer can revoke acceptance unilaterally at any time, regardless of Safe threshold, since it is their signature rather than the Safe state. This gives a signer an exit that Safe itself does not provide. If you are removed, access drops automatically. For communities that already use governance NFTs, the NFT itself becomes the identity key:ownerOf(tokenId)is verified at send time. The ERC-8004 / ghostagent.ninja integration adds optional reputation scoring (notapaperclip.red swarm trust) and composability with agent frameworks, but is not required for basic signer coordination. No passwords, no invite links, no admin adding or removing users. -
Signer rotation is automatic. Pipes reads the Safe contract directly. When the signer set changes on-chain, whether via
swapOwner()or governance NFT transfer, access updates automatically. The departing signer loses access instantly. The new signer gains it. No admin action, no forgotten permissions, no manual offboarding. The Safe contract state is the single source of truth. -
The relay is operator-blind. All messages are encrypted with ECIES (Elliptic Curve Integrated Encryption Scheme). The relay stores and serves ciphertext only. Even with root access to the machine, the operator cannot read the payload. A warrant produces noise.
-
Quorum tracking is built in. The sender sees “3 of 5 signers have acknowledged” without knowing which specific signers: preventing collusion pressure while confirming readiness. “Acknowledged” means “I have read the coordination payload,” not “I approve the transaction.” The Safe signing is separate and on-chain.
-
The namespace is sovereign.
safe.42@pipeis an internal protocol namespace. No DNS, no SMTP, no ICANN. The address resolves entirely within the Pipes protocol on Gnosis Chain. The protocol cannot be deplatformed because there is no platform: just a relay that anyone can run. -
Network-level metadata protection. Pipes supports a Sovereign Transport Mode that routes encrypted traffic through Gnosis VPN, powered by the HOPR mixnet. In this mode, the relay cannot observe either the message content or the sender’s network identity. Payload privacy (ECIES) plus connection privacy (HOPR) equals total amnesia.
Competitive Landscape & Differentiation
Pipes doesn’t compete with general-purpose messengers. It is purpose-built for DAO coordination where identity must be provable, and the infrastructure must not be a witness.
| Solution | Identity Model | Server Can Read? | Signer Rotation | Quorum Tracking | Infrastructure Control |
|---|---|---|---|---|---|
| Signal | Phone number | Metadata only | Manual | No | Signal’s servers |
| Telegram | Phone number | Yes (not E2E by default) | Manual | No | Telegram’s servers |
| Discord | Email/account | Yes | Manual | No | Discord’s servers |
| Keybase | Social proofs | No (E2E) | Manual | No | Keybase servers (Zoom-owned) |
| XMTP | Wallet address | Metadata | Manual | No | XMTP network |
| Pipes | Safe contract / NFT | No (ECIES, operator-blind) | Automatic (reads Safe state) | Yes (aggregated) | DAO runs its own relay |
The moat: no other coordination tool combines on-chain identity verification, operator-blind encryption, automatic signer rotation, and quorum tracking in a single protocol where the DAO controls the infrastructure.
Synergy with Funded Gnosis Projects
Pipes is designed to complement, not compete with, existing Gnosis ecosystem investments:
| Project | Funding | Pipes Integration |
|---|---|---|
| ProbeLab | $105k (GIP, network metrics) | Pipes relay performance and P2P health can be monitored by ProbeLab’s existing dashboards. The relay uses standard libp2p/devp2p transports, which ProbeLab’s tooling already covers. Integration is zero-effort: the relay exposes standard metrics endpoints. |
| Gnosis VPN / HOPR | Core infra (GIP-154) | Sovereign Transport Mode routes Pipes traffic through HOPR mixnet. This creates immediate utility for Gnosis VPN by giving it a production use case: encrypted Safe coordination. |
| Gnosis Safe | Core product (spinout) | The Safe module integrates directly. Every Safe on Gnosis Chain becomes a potential Pipes user. |
| EEZ (GIP-153) | $15m/year (GIP-154) | Pipes runs on Gnosis Chain regardless of L1/L2 architecture. If EEZ passes, Pipes benefits from synchronous Ethereum composability for NFT ownership verification. |
| Circles | $0.7m (GIP-154) | Community currencies need community coordination. Pipes provides the coordination layer for Circles-based local economies. |
What Already Exists
Pipes is not a whitepaper. The core infrastructure is running today:
| Component | Status | Details |
|---|---|---|
| ECIES relay | Live | Hetzner bare metal. Processes encrypted envelopes. Operator-blind. Stateless, amnesiac, disposable. |
| nftmail.box | Live | Encrypted messaging with PGP interop. Wallet-derived key management. WKD key discovery. ERC-8004 on-chain identity binding. |
| @fax protocol namespace | Live | DFZ.1234@fax identities resolve off-chain via the relay. No DNS dependency. Four NFT communities onboarded (DeadFellaz, Chonks, Normies, POW NFT). |
| NFTFAX CHAIN game | Live on Base | Consumer proof-of-concept. Contract: 0xcC121BF9E3a13d03EACd55E15495e3E8De61fac5. 2,222 mint supply. On-chain commit-reveal prize draw. 48 API routes serving identity, messaging, coordination, and minting. |
| ghostagent.ninja | Live | ERC-8004 agent identity platform. NFT-bound sovereign identity with Gnosis Safe integration. Cross-chain binding. |
| notapaperclip.red | Live | Swarm trust oracle. Diversity-scored agent reputation. Four analysers: ERC-8004 verifier, A2A validator, MCP inspector, swarm trust scorer. |
| nftfax.app API | Live | 48 documented routes. Public resolution, inbox management, fax composition, minting, telegraph leaderboard. |
| On-chain identity authorisation | Live | Per-request ownerOf() verification on Base and Ethereum, fail-closed, across all read and destructive endpoints. Replaced registry-based authorisation after live testing surfaced a bypass. |
| Consented membership | Designed | Signed acceptance + unilateral revocation, replacing getOwners()-only membership. Prompted by a real Safe owner-set poisoning incident. Part of the Safe module deliverable. |
Key Metrics (Current)
-
NFT communities onboarded: 4 (DeadFellaz, Chonks, Normies, POW NFT)
-
Registered
@faxidentities: 64 (Chonks 35, POW NFT 26, DeadFellaz 2, Normies 1) — from an addressable base of ~21,000 holders across ~103,000 NFTs; addressable is not active -
Public transmissions: 45, from 21 senders to 26 recipients
-
Collectibles minted on Base: 23, by 13 distinct wallets; prize pool 0.046 ETH
-
Live on-chain contract:
0xcC121BF9E3a13d03EACd55E15495e3E8De61fac5(Base), ownerghostagent.eth -
API routes: 48 (identity, messaging, coordination, minting)
-
Standards implemented: ERC-8004, ERC-8312 (contributed), ERC-8048, EIP-4361 (SIWE), ERC-8217 (referenced)
-
Availability: one self-inflicted outage (2026-09-22, ~30 min, build on the production host); cause removed
-
Encryption: ECIES (ephemeral secp256k1 ECDH → HKDF-SHA256 → AES-256-GCM) in the reference implementation; deployed relay still on the v1 P-256 path. No forward secrecy in either.
-
Identity authorisation: resolved on-chain per request, fail-closed, on Base and Ethereum (migrated off registry-based lookup, September 2026)
-
Findings from live operation: 2 authorisation defects found and fixed pre-audit (one read + destructive, one unauthenticated endpoint that spent funds); 1 protocol assumption invalidated by a real attack, resulting in the consented-membership design change; 4 further reliability defects fixed
Technical Architecture
[ SAFE SIGNER CLIENT ]
│
├─► 1. PAYLOAD PRIVACY (ECIES)
│ Message encrypted to recipient's ERC-8048 public key.
│ Relay stores ciphertext only. Cannot decrypt.
│ PGP interop for legacy email compatibility.
│
├─► 2. IDENTITY (Safe contract + optional NFT)
│ SIWE authentication. getOwners() verified on-chain.
│ Signer set resolved from Safe contract at send time.
│ Optional: ERC-8004 reputation + NFT-gating for communities.
│
└─► 3. NETWORK PRIVACY (HOPR via Gnosis VPN)
IP & connection metadata obfuscated through HOPR mixnet.
Relay receives encrypted blobs with no source address.
Configurable transport mode per Safe.
│
▼
[ AMNESIAC PIPES RELAY ]
Stateless. Stores encrypted envelopes in KV.
Multi-jurisdiction deployment (DE + US + SG).
No session state. No message history. No group metadata.
Standard metrics endpoints for ProbeLab monitoring.
Group Addressing & Quorum
safe.42@pipe resolves dynamically to the current signer set of Safe #42 via on-chain getOwners() at send time. Each signer receives an individually encrypted copy. The relay sees N encrypted blobs, not a group chat.
Per-message acknowledgement: each recipient signs a lightweight SIWE attestation. Aggregated into quorum status. “Acknowledged” means “I have read the coordination payload,” not “I approve the transaction.” Safe signing is separate.
Standards
| Standard | Role | Status |
|---|---|---|
| EIP-4361 (SIWE) | Authentication | Published, deployed |
| ERC-8004 | Agent identity registry | Published |
| ERC-8217 | NFT-to-agent binding | Published (nxt3d) |
| ERC-8312 | Bounded agent actions | Draft (GhostAgent contributed) |
| ERC-8048 | On-chain metadata for tokens | Draft |
Performance & Gas
| Operation | Gas (Gnosis Chain) | Notes |
|---|---|---|
| SIWE verification | 0 (off-chain) | Signature verified client-side and by relay |
Safe getOwners() resolution |
~800 gas + 500/signer | Standard Safe read |
| ERC-8312 cursor advance | ~21,000 gas | Stateful write, per transaction |
| Acknowledgment attestation | 0 (off-chain) | SIWE-signed, stored in relay KV |
| Message send (ECIES encrypt) | 0 (client-side) | Encryption in browser, ciphertext to relay |
| Transport mode switch | 0 (config) | Standard vs HOPR selected per-Safe, no gas |
A typical multisig coordination round on Pipes consumes under 4,000 gas (two getOwners reads). Traditional on-chain governance with proposal submission and voting can consume 200,000–500,000 gas. Pipes moves coordination off-chain while keeping identity verification on-chain: reducing gas costs by 98%+ for the coordination phase.
Budget
| # | Deliverable | Cost |
|---|---|---|
| 1 | Security audit: independent audit of ECIES relay, group coordination protocol, and Safe module by a Gnosis DAO-approved firm (Consensys Diligence, Trail of Bits, or equivalent). | $25,000 |
| 2 | Lead developer: Safe module development, Gnosis VPN transport integration, SDK, documentation, project management. Operator-Blind Webhook Notification System + Open-Source Discord/Telegram Adapter, project management. 8+ weeks of work. | $22,000 |
| 3 | Relay hardening: multi-jurisdiction deployment (DE + US + SG), rate limiting, API key system for third-party integrations, ProbeLab metrics endpoint. | $5,000 |
| 4 | Existing infrastructure contribution: ECIES rela@fax@fa@f@faxfax@fa@fa@fax @fax namespace, PGP interop, ERC-8004 identity integration. 6+ months of prior development now being open-sourced and hardened for the Gnosis ecosystem. | $8,000 |
| 5 | Contingency: unforeseen technical complexity, audit remediation, extended timeline. | $5,000 |
| Total | $65,000 |
Payment: $65,000 in stablecoins (EURe or USDC on Gnosis Chain) to a Gnosis Safe controlled by the author. Two tranches:
- Tranche 1 (50%, $32,500): On proposal approval, to initiate audit engagement and begin Safe module development.
- Tranche 2 (50%, $32,500): On completion of the independent audit, publication of the remediation report, and public open-sourcing of the Safe module repository.
Budget context: GIP-154 allocates $3.572m to Core and Infra (including $0.1m for audits, $0.2m for Safe, and $0.68m for hosting). This GIP is 1.8% of that line item, and delivers infrastructure that serves the entire Safe ecosystem, not just Gnosis Ltd.
Note on scope and budget
Consented membership extends deliverable 2 (Safe module development) rather than adding a line item. If reviewers consider the acceptance/revocation registry and its verification tooling to warrant separate costing, say so and I will revise. I would rather adjust the budget than under-scope a security-critical component.
12-Month Roadmap
| Phase | Timeline | Milestones |
|---|---|---|
| Phase 0: Pre-GIP | Completed | ECIES relay live. nftmail.box with PGP interop. NFTFAX CHAIN game on Base. 48 API routes. 4 communities onboarded. |
| Phase 1: Audit & Harden | Sep–Nov 2026 | Security audit complete. Safe module developed. Gnosis VPN transport integrated. Relay hardened (multi-jurisdiction, rate limiting). |
| Phase 2: Release | Nov 2026 | Open-source release. Documentation + SDK. Reference UI. Pipes relay available for any DAO to deploy. |
| Phase 3: Adoption | Dec 2026–Feb 2027 | First 5 DAO pilots. Gnosis DAO treasury coordination on Pipes. Feedback loop for improvements. |
| Phase 4: Scale | Mar–Aug 2027 | Signer ping notifications. B2B invoicing. OTC authentication. Agent-to-agent coordination. 50+ DAOs. |
| Phase 5: Ecosystem | Sep 2027–Aug 2028 | Pipes as default Safe coordination layer. Marketplace for integrations. Agentic DAO tooling. 500+ DAOs. |
5-Year Vision
Pipes becomes the default coordination layer for every Gnosis Safe: the encrypted, identity-gated communication primitive that DAOs, working groups, and autonomous agents use to coordinate before execution. The same way Safe became the default for custody, Pipes becomes the default for coordination.
By Year 5:
- 5,000+ DAOs using Pipes for Safe coordination
- Native integration in Safe{Wallet} UI (“Coordinate” tab next to “Transactions”)
- Agent-to-agent coordination via ERC-8312 bounded authority
- Gnosis VPN transport as default for enterprise Safes
- Pipes protocol adopted beyond Gnosis: any EVM chain, any multisig
- Revenue model: enterprise tiers, hosted relay options, audit services
Risks & Mitigation
| Risk | Severity | Mitigation |
|---|---|---|
| Owner-set poisoning / membership without consent | High | Observed in production against the author’s own address. Safe owner assignment is permissionless at creation and Safe has no unilateral exit, so any address can be conscripted into a hostile owner set and cannot leave. Mitigation: membership requires a signed acceptance naming the Safe, revocable unilaterally by the signer. getOwners() alone is never sufficient. |
| Registry-based identity drift | High | Observed in production. A cached signer/key registry consulted for authorisation fails open for unregistered identities and closed for legitimate ones once stale. Mitigation: authorisation resolves against chain state per request; the registry is a performance optimisation only. Migrating the deployed relay off its key registry is Phase 1 scope. |
| Fail-closed availability under RPC failure | Medium | Observed in production: correct fail-closed behaviour combined with RPC rate limiting silently hid waiting messages. Mitigation: minimise on-chain calls per request; cache authorised results briefly and never denials; treat RPC availability as an explicit audit requirement. |
| Audit reveals critical vulnerability | High | Contingency budget covers remediation. Open-source code enables community review before audit. Two findings have already been surfaced and addressed pre-audit under live traffic. |
| Low Safe DAO adoption | Medium | FAX CHAIN game proves coordination model with real users. Start with Gnosis DAO as first pilot. |
| Gnosis VPN/HOPR transport unstable | Medium | Sovereign Transport Mode is optional. Standard HTTPS transport works independently. Degrade gracefully. |
| Regulatory attention (encrypted comms infra) | Low | Open-source. No user data. Operator-blind architecture means no plaintext to produce. Tool posture, not operator posture. |
| Single developer dependency | Medium | Open-source release enables community contributions. Audit by independent firm validates code quality. |
| Competing protocol emerges | Low | First-mover advantage with live infrastructure. Standards-based architecture enables interoperability, not lock-in. |
FAQ
Q: How is this different from using Signal for Safe coordination?
Signal provides end-to-end encrypted messaging but uses phone numbers as identifiers, cannot verify that a message recipient is currently a Safe signer, requires manual group management when signers rotate, and relies on Signal’s centralised infrastructure. Pipes is cryptographically gated to the Safe signer set, rotates access automatically, and lets the DAO run its own relay.
Q: What happens if the relay goes down?
The relay is stateless and deployed across three jurisdictions. If one relay is taken offline, the other two continue operating. A new relay instance can be deployed in minutes. Messages are stored temporarily in KV: the relay is a pass-through, not a database.
Q: Can the DAO verify the relay is not logging anything?
Yes. The relay is open-source. The DAO can audit the code, run its own instance, and verify that the operator cannot decrypt messages (ECIES encryption is client-side). For maximum assurance, the DAO deploys its own relay: Pipes is infrastructure, not a service.
Q: How does this integrate with existing DAO tooling (Snapshot, Tally, Safe UI)?
Pipes is complementary. Snapshot handles voting. Safe handles execution. Pipes handles the coordination between them. No integration with existing tooling is required: Pipes is a standalone coordination channel that signers use alongside their existing workflow.
Q: Why not build this as a Discord bot or Signal bot?
Bots introduce a third party that can read messages. A Discord bot sees plaintext. A Signal bot requires a phone number. Pipes is operator-blind: the relay cannot read messages. The encryption is client-side, the identity is on-chain, and there is no third party.
Q: Do Safe signers need to hold a separate NFT to use Pipes?
No. For standard Safe signer coordination, Pipes reads the signer set directly from the Safe contract via getOwners(). No additional token is required. The NFT-gating model is an option for communities that already use governance NFTs (e.g., DeadFellaz holders using their existing NFT as their Pipes identity). For DAO treasuries, the Safe itself is the gate.
Feedback & Links
Smart Contract (NFTFAX CHAIN proof-of-concept): 0xcC121BF9E3a13d03EACd55E15495e3E8De61fac5 (Base)
API: 48 routes documented at nftfax.app (public resolution, inbox, fax composition, minting, telegraph)
Live relay: nftmail.box (PGP + ECIES encrypted messaging, operator-blind architecture)
Identity platform: ghostagent.ninja (ERC-8004 agent registry)
Trust oracle: notapaperclip.red (swarm-scored agent reputation)
Forum: This thread. Feedback on scope, budget, and architecture welcome.
Contact: GhostAgent on the Gnosis Discord or via the forum
This GIP is posted for Phase 1 discussion. The author welcomes feedback from delegates, especially on scope, budget, integration with existing Gnosis infrastructure, and the Safe module specification. All feedback will be incorporated before moving to Phase 2.
New coordination payload waiting for Safe 
|