Colabonate — Decentralized Collaborative Commerce on Bitcoin L2, with an ICP Canister as the Non-Custodial Escrow Layer

Developers Showcase
1

Hi everyone,

I’m Deniz (info@colabonate. com), founder of Colabonate, an open protocol for Decentralized Collaborative Commerce (DCC) built on a Bitcoin-native stack with an Internet Computer canister as the non-custodial escrow layer.

We are applying to the DFINITY Ecosystem Grant and would like to introduce the project to the developer community here. I’m especially interested in feedback from canister engineers on the escrow architecture (Path 2 / threshold-ECDSA, see below).

  • What: Open-source, ADR-driven commerce protocol, 8 cooperation types (sale / service / crowdfunding / barter / …), 0% platform fees, public DAO governance.
  • Stack: Bitcoin L1 + Lightning + Nostr (Kind 30407/30408) + Cashu (NIP-60) + ICP Escrow Canister (threshold-ECDSA, native BTC, controller blackholed or DAO-governed).
  • Why ICP: A canister holding native BTC with provably no human in control is exactly the trust-minimized escrow primitive P2P commerce needs.
  • Status: V1 reference build, 326 ADRs, 65 Prisma models, whitepaper v8 (EN+DE); escrow canister at BUILD → PILOT (ADR-254), mainnet pilot gated by a security gate (FU-253-H).
  • Ask: Architectural review from ICP devs, and introductions to anyone who has shipped threshold-ECDSA-based canisters in production.

Repo, whitepaper and ADRs are linked at the bottom.

Architecture overview

┌──────────────────────────────────────────────────────────────────┐
│   Buyer / Seller Wallets (Nostr keys, no ICP identity "not now") │
└──────────────────────────────────────────────────────────────────┘
           │ Nostr events               │ signed actions
           ▼                            ▼
   Nostr Relays                  ┌───────────────────────┐
   (Kind 30017/30019/30022/      │   ICP Escrow Canister │
    30024/30408)                 │   • threshold-ECDSA   │
                                 │   • P2WPKH per trade  │
                                 │   • payout invariant  │
                                 │   • DAO controller    │
                                 └───────────────────────┘
                                           │
                  Bitcoin L1 (settlement)  │  Lightning (Direct-Pay rail)
                                           ▼
                                 ┌──────────────────┐
                                 │  Bitcoin Network │
                                 └──────────────────┘

Path 2 escrow (ADR-253 / ADR-254) — fully documented in escrow-canister-protocol.md:

  • One canister-wide ECDSA key id (key_1 Mainnet), per-trade derivation via derivation_path = [trade_id.to_be_bytes()], address type P2WPKH.
  • Buyers/sellers only hold Nostr keys (secp256k1 / BIP-340) — no ICP wallets required. State-changing calls are authenticated by Nostr-signed payloads verified inside the canister via a compiled-in Schnorr library.
  • Payout invariant: every payout transaction the canister signs can only send to addresses fixed at trade creation (buyer refund + seller payout + optional DAO fee). No operator, no controller, no DAO majority can redirect funds to a new address mid-trade.
  • Trade state machine: PendingFunding → Funded → Released | Refunded | Disputed → released/refund/split — each transition gated by the correct party signature or a DAO verdict.
  • Controller is blackholed or DAO-controlled, no single point of failure.

Why ICP fits the brief

  1. Native Bitcoin via threshold-ECDSA: Colabonate is intentionally Bitcoin-only (ADR-007, no EVM, no bridges). The IC’s sign_with_ecdsa + bitcoin_get_utxos + bitcoin_send_transaction give us a canister that holds real BTC, not an IOU token.
  2. State machine on-chain. every escrow transition is a canister update call, deterministic and reproducible. The canister code is reproducibly buildable, so the verifier assumption holds for any independent auditor.
  3. Provable no-custody: controller blackhole or DAO SNS removes operator custody risk, which is the #1 reason P2P commerce today needs a trusted third party.
  4. HTTP outcalls / chain-key cryptography round out the toolbox for fiat reference data and future cross-chain attestations without adding bridge surface.

What we’re asking from this forum

  • Architectural feedback on the escrow canister: anyone shipping t-ECDSA-based canisters in production, we’d love a review.
  • Security gate (FU-253-H) reviewers for the mainnet pilot, particularly on confirmation depth, payout invariant testing, and DAO-controller integration.
  • SNS / DAO governance patterns, anyone who has run a canister under an SNS-controlled principal in production.
  • Intro threads with the DFINITY grants team if you’ve been through the process, happy to learn from your experience.

Links

Repo: github .com/Colabonate/Colabonate-App (and the protocol sub-repo)

Whitepaper v8 (EN): in-repo, docs/colabonate_whitepaper_en_v8.md

Whitepaper v8 (DE): docs/colabonate_whitepaper_de_v8.md

Escrow Canister Protocol (normative): Colabonate_Protocol/docs/protocols/core/escrow-canister-protocol.md

DFINITY grant draft: available on request — currently under internal review before submission

:globe_with_meridians: Website colabonate .com
:octopus: GitHub github. com/Colabonate
:handshake: Open Collective opencollective. com/colabonate
:clapper_board: YouTube youtube. com/@colabonate
:bird: X / Twitter x. com/Colabonate
:camera_with_flash: Instagram instagram. com/colabonate
:wrapped_gift: Patreon patreon. com/c/Colabonate

Happy to do an architecture walkthrough in a thread here, or jump on a community call. Looking forward to your feedback.

Deniz Yilmaz
Lübeck - Germany

info@colabonate .com
Founder

2

The Developer Grants program is currently closed and not accepting applications. There isn’t an active grant program to apply to at the moment.

If I may ask, where did you find out about the developer program? If there’s any page or documentation that states the contrary, we would appreciate a heads up.

3

I just received information that funding is no longer available. Thank you for your reply – I hope my solution supports the general goal of a decentralized domain.

4

I have developed with a small team on the IC an app that uses ckBTC.
Your project is pretty good, it is very much at the infrastructure level, but quite useful.

As DFINITY responded to you unfortunately there are no Developer Grants anymore, I suggest you turn your idea into a solution, not just an open source project or infrastructure, but an actual solution for paying customers. This change would allow you to search for funds, or if you can: self fund it and later launch a product, not a project.

There is no need anymore for you to be open source, in fact that makes it easier for others including AI agents to copy your work, and leverage it. We are living in brave new AI world.

Take care,

Joseph Hurtado
Founder Granata Consulting
Building Satoshi Notes