GIP-XXX: Should GnosisDAO fund Pipes — encrypted coordination infrastructure for Safe signers?

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:

  1. 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 to safe.42@pipe. No separate token, no mint, no additional onboarding. If you are a signer, you have access. 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 and removing users.

  2. 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 signer who left 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.

  3. 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.

  4. 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.

  5. The namespace is sovereign. safe.42@pipe is 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.

  6. 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 analyzers: 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.

Key Metrics (Current)

  • NFT communities onboarded: 4 (DeadFellaz, Chonks, Normies, POW NFT)
  • Addressable holders: ~21,000 unique wallets across ~103,000 NFTs
  • Live on-chain contract: 0xcC121BF9E3a13d03EACd55E15495e3E8De61fac5 (Base)
  • API routes: 48 (identity, messaging, coordination, minting)
  • Standards implemented: ERC-8004, ERC-8312 (contributed), ERC-8048, EIP-4361 (SIWE), ERC-8217 (referenced)
  • Uptime: relay operational since deployment; no downtime incidents
  • Encryption: ECIES + PGP dual-stack, operator-blind architecture verified

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.


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
Audit reveals critical vulnerability High Contingency budget covers remediation. Open-source code enables community review before audit.
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.

From a signer’s point of view, how would they know that a new coordination message is waiting?

If it means regularly checking another inbox, I worry important messages could be missed compared with the tools teams already use. Clear notifications and a simple fallback path seem important before asking signers to change their workflow.

1 Like

Great question, Anzus. You’ve hit the exact nail on the head: notification latency is the difference between a protocol people want to use and an inbox that gets neglected.

Expecting a multisig signer who manages 5+ DAOs to log into a separate dashboard every morning just to check for pending messages will fail. Here’s how we solve the push-vs-pull workflow without compromising payload privacy:

1. The Operator-Blind Webhook Adapter (Phase 1 deliverable)

The Pipes relay knows when a new encrypted envelope is deposited for safe.42@pipe. It cannot read the payload, but it knows an event occurred.

The relay fires a minimal webhook containing only what the relay already knows:

Copied


  "event": "COORDINATION_MESSAGE_WAITING",
  "recipient": "safe.42@pipe",
  "timestamp": 1724391200,
  "messageHash": "0x8f3a..."

messageHash is a SHA-256 hash of the encrypted envelope. It lets the client check “is this new?” without asking the relay for the full ciphertext. It leaks nothing — it’s a hash of noise to anyone without the recipient’s private key.

Sender identity is intentionally omitted from the default webhook payload. The Discord bot doesn’t need to know who sent the message, only that a message exists. If a DAO prefers sender-visible notifications (“safe.17 sent a coordination message”), they can toggle that in their relay config. Default is metadata-minimal.

2. Meeting signers where they already are

That webhook feeds into lightweight adapters for the surfaces signers already monitor 24/7:

  • Discord / Slack bot – posts “:open_mailbox_with_raised_flag: New coordination payload waiting for Safe #42. Open Pipes to decrypt.” in the DAO’s private signer channel.

  • Telegram bot – direct ping to the signer group.

  • Email digest – daily summary or real-time alert.

The bot never sees plaintext, ABI data, or sender metadata. It’s a signal bell, not a reader.

3. Built-in quorum tracking is the safety net

If the notification adapter is down or a signer ignores the ping, the sender’s client displays real-time quorum status: “2 of 5 signers have acknowledged.” The sender knows instantly that something is wrong and can ping the missing signer through traditional channels. The protocol degrades gracefully, it doesn’t silently stall.

4. Long-term: native Safe{Wallet} integration (Phase 4)

The ultimate home is a “Coordinate” tab inside Safe{Wallet} with an unread badge next to “Transactions.” But signers shouldn’t have to wait for Safe UI updates to get a usable workflow today. The webhook bridge means nobody’s blocked on upstream integration.

1 Like

Thanks for publishing the proposed audit budget and Phase 1 timeline.

Has an audit provider or procurement route already been selected for the $25,000 security-review allocation?

Arctek Audits could assess a bounded initial package around the Safe-module authorization, signer-set changes and the relay-to-Safe trust boundary. If the engagement remains unassigned, who should receive a private scope discussion?

Reuben Kassongo
Arctek Audits

1 Like

Thanks for reaching out, Reuben. The audit procurement process hasn’t begun yet — the GIP is still in Phase 1 discussion, and the $25,000 allocation is contingent on the proposal passing. The proposal references a preference for a Gnosis DAO-approved firm given the sensitivity of the Safe module integration, but I’m happy to receive a scope proposal at ghostagent@nftmail.box once we’re closer to Phase 2.

Appreciate the interest.

Thanks, @GhostAgent , understood.

I’ll follow the Phase 1 discussion and wait until the proposal is closer to Phase 2. If it advances and Arctek is eligible under the final procurement route, I’ll send a concise scope proposal to the address you provided, focused on the Safe-module authorization path, signer-set transitions and the relay-to-Safe trust boundary.

Appreciate the clear direction.

Reuben Kassongo
Arctek Audits

1 Like