Skip to content

Conversation

@TaprootFreak
Copy link
Collaborator

@TaprootFreak TaprootFreak commented Jan 14, 2026

Summary

Comprehensive technical documentation for integrating Internet Computer Protocol (ICP) blockchain into DFX payment infrastructure. Based on the signed DFINITY contract (January 2026).

⚠️ Major Revision: ICSI Webhooks → Official DFINITY Polling

After thorough evaluation, ICSI webhooks were rejected in favor of polling on official DFINITY infrastructure.

Why ICSI Was Rejected:

Issue Problem
Not True Event-Driven ICSI internally polls every 15s, then sends webhook
Single Point of Failure Community-maintained canister outside DFX control
Low Adoption Only 5 GitHub stars
Inactive Maintainer No guaranteed support or SLA
No Recovery Logic No documented backfill for missed transactions

Why Polling Was Chosen:

  • Industry Standard - Used by Binance, Coinbase, Kraken
  • Official DFINITY - Index Canister maintained by DFINITY Foundation
  • Full Control - Own error handling, retry logic, recovery
  • Same Pattern - Already used in DFX for Bitcoin/Lightning
  • Fast Enough - 10-second polling + 2-second finality = excellent UX

Architecture

DFX API → @Cron(10s) → ICP Index Canister (DFINITY) → Detect deposits
                                ↓
                          PayInService.createPayIn()

Key Features

  • Polling-Based Deposit Detection via official DFINITY Index Canister
  • Subaccount Model: One principal with unique subaccount per route
  • Token Support: ICP, ckBTC, ckUSDC, ckUSDT (VCHF/VEUR pending VNX)

Official Canister IDs

Component Canister ID Maintainer
ICP Index qhbym-qaaaa-aaaaa-aaafq-cai DFINITY
ICP Ledger ryjl3-tyaaa-aaaaa-aaaba-cai DFINITY
ckBTC Index n5wcd-faaaa-aaaar-qaaea-cai DFINITY
ckBTC Ledger mxzaz-hqaaa-aaaar-qaada-cai DFINITY

Documentation Covers

  • NPM packages required (@dfinity/agent, @dfinity/ledger-icrc, etc.)
  • Core service implementations (IcpClientService, IcpDepositService, IcpAddressService)
  • PayIn strategy (polling-based, NOT webhook)
  • PayOut strategy (ICRC-1 transfers)
  • Address generation (Principal + Subaccount)
  • Configuration and environment variables
  • Database schema updates
  • Comparison table: Polling vs ICSI

Test Plan

  • Review documentation for completeness
  • Validate canister IDs against mainnet
  • Confirm polling approach aligns with DFX architecture

Comprehensive technical documentation for integrating Internet Computer
Protocol (ICP) blockchain into DFX payment infrastructure.

Covers:
- Architecture overview and key differences from EVM chains
- Required NPM packages (@dfinity/agent, @dfinity/ledger-icrc, etc.)
- Core service implementations (IcpClient, IcrcLedger, CkBtc)
- PayIn strategy (polling-based deposit detection)
- PayOut strategy (ICRC-1 transfers)
- Address generation (Principal + Subaccount model)
- Configuration and environment variables
- Database schema updates
- Testing strategy and deployment checklist

Tokens in scope:
- ICP (native token)
- ckBTC (chain-key Bitcoin)
- VCHF/VEUR (pending VNX canister deployment)

Reference: DFINITY contract signed January 2026
Replace polling-based deposit detection with ICSI (ICP Sub-Account Indexer)
webhook integration for scalable deposit detection across thousands of
customer deposit addresses.

Key changes:
- Remove per-address polling (unscalable for DFX customer volume)
- Add ICSI webhook-based architecture as primary solution
- Document IcsiIndexerService with webhook registration
- Add IcpWebhookController for handling deposit notifications
- Include ICSI canister ID and API documentation
- Update PayIn strategy to be event-driven instead of polling
- Add liquidity consolidation flow documentation
- Document all relevant canister IDs (ICP, ckBTC, ckUSDC, ckUSDT)

ICSI provides real-time webhook notifications when deposits arrive,
eliminating the need for expensive polling of individual subaccounts.
@github-actions
Copy link

github-actions bot commented Jan 14, 2026

⚠️ Security: 0 critical, 61 high vulnerabilities

Major revision after evaluating third-party webhook solutions (ICSI):

ICSI Webhooks REJECTED because:
- Not true event-driven (internally polls every 15s, then sends webhook)
- Single Point of Failure (community-maintained canister)
- Only 5 GitHub stars, inactive maintainer
- No guaranteed SLA or documented recovery logic

POLLING APPROACH CHOSEN because:
- Industry standard (used by Binance, Coinbase, Kraken)
- Uses official DFINITY-maintained Index Canister
- Full control over error handling and recovery
- Same pattern already used in DFX for Bitcoin/Lightning
- 10-second polling with 2-second finality = excellent UX

Key changes:
- Remove ICSI/icsi-lib dependency
- Remove IcpWebhookController
- Add IcpDepositService with @Cron polling
- Add IcpAddressService for subaccount-based addresses
- Use official ICP Index Canister (qhbym-qaaaa-aaaaa-aaafq-cai)
- Add ckBTC Index Canister (n5wcd-faaaa-aaaar-qaaea-cai)
- Add comparison table: Polling vs ICSI
Remove references to Base, Solana and other blockchains.
Document now covers only ICP-native tokens:
- ICP (native)
- ckBTC, ckUSDC, ckUSDT (chain-key)
- VCHF, VEUR (ICRC-1, pending VNX deployment)
- Remove section 1.3 (Why Polling Instead of Webhooks)
- Remove section 12 (Comparison: Polling vs ICSI)
- Simplify code comments to focus on implementation
- Renumber remaining sections
@TaprootFreak TaprootFreak marked this pull request as draft January 15, 2026 17:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants