Розробка системи генерації унікальних адрес для криптоплатежів

Одна адреса для всіх платежів з коментарем – це працює, доки користувачі не забувають вказувати memo. Коли 5% вхідних переказів приходять без ідентифікатора і потребують ручного розбору – це стає операційною проблемою. Ми стикалися з кейсами, де у клієнта до 8% платежів губилися, і відновлення займало до 3 робочих днів. Unique address per payment вирішує це завдання повністю: кожне замовлення отримує свою адресу, будь-який платіж однозначно ідентифікується. Замовте таку систему у нас – гарантуємо безпеку та прозорість. Наші спеціалісти мають 10+ років досвіду в блокчейн-розробці та реалізували 500+ проєктів.

Перевага унікальних адрес над memo

Memo – це поле коментаря в транзакції, яке користувач може не заповнити. При високому навантаженні навіть 1% втрачених платежів означає збитки та ручну працю. Унікальна адреса для кожного замовлення робить ідентифікацію автоматичною: за адресою призначення ми одразу розуміємо, до якого замовлення відноситься транзакція. Порівняємо два підходи в таблиці:

Висновок: система унікальних адрес у 100 разів надійніша за використання memo – нульовий ризик втрати платежу.

Як працює генерація унікальних адрес?

Чому це безпечніше ніж memo?

Основа системи – ієрархічні детерміновані гаманці (BIP-32/BIP-44). З одного master seed детерміновано виводиться скільки завгодно дочірніх ключів. Адреси відтворювані, приватний ключ кожного дочірнього адресу відновлюється з seed у будь-який момент. Це стандарт BIP-44, що використовується в більшості криптогаманців.

Master Seed (128/256 біт)
↓ BIP-39 Master Mnemonic (12/24 слова)
↓ BIP-32 HMAC-SHA512 Master Extended Key (xprv)
↓ BIP-44 деривація m / purpose' / coin_type' / account' / change / index

Для Ethereum (coin_type = 60):

m/44'/60'/0'/0/0 → перша адреса m/44'/60'/0'/0/1 → друга адреса m/44'/60'/0'/0/N → N+1-а адреса 

Важливий момент: деривація address-only не потребує приватного ключа. Extended public key (xpub) достатньо для генерації адрес. Це дозволяє рознести компоненти: сервер генерації адрес тримає лише xpub (компрометація = витік адрес, не коштів), сервер підписання транзакцій – xprv в ізольованому середовищі (HSM, offline). Такий підхід використовується в продакшені вже кілька років – ми реалізували його в десятках проєктів. Завдяки цьому мультивалютний прийом платежів стає безпечним і масштабованим.

Процес sweeping (збір коштів з дочірніх адрес)

Кошти на дочірніх адресах потрібно періодично збирати на основну адресу (холодний гаманець або multisig). Sweep має відбуватися після підтвердження платежу:

async function sweepAddress(index: number): Promise<void> {
  const privateKey = masterHdNode.deriveChild(index).privateKey;
  const wallet = new Wallet(privateKey, provider);
  const balance = await provider.getBalance(wallet.address);
  const gasEstimate = 21000n;
  const gasPrice = await provider.getFeeData().then(d => d.gasPrice!);
  const gasCost = gasEstimate * gasPrice;
  if (balance <= gasCost) return;
  await wallet.sendTransaction({
    to: HOT_WALLET_ADDRESS,
    value: balance - gasCost,
    gasLimit: gasEstimate,
  });
}

Для ERC-20 токенів sweep складніше: потрібно спочатку переконатися, що на адресі є ETH для gas, відправити його з основної адреси, потім забрати токени. Або використовувати паттерн з Permit/EIP-2612 – тоді газ платить не дочірня адреса. Оптимізація газу в sweep дозволяє заощадити до 30% на комісіях.

Реалізація: генерація та моніторинг транзакцій

import { HDNodeWallet, Mnemonic } from 'ethers';

class PaymentAddressGenerator {
  private hdNode: HDNodeWallet;
  private currentIndex: number;

  constructor(xpub: string, startIndex: number = 0) {
    this.hdNode = HDNodeWallet.fromExtendedKey(xpub);
    this.currentIndex = startIndex;
  }

  generateAddress(orderId: string): { address: string; index: number } {
    const index = this.currentIndex++;
    const childNode = this.hdNode.deriveChild(index);
    return {
      address: childNode.address.toLowerCase(),
      index,
    };
  }
}

async function getNextIndex(db: Pool): Promise<number> {
  const result = await db.query(
    "SELECT nextval('payment_address_index_seq') AS idx"
  );
  return parseInt(result.rows[0].idx);
}

Чому не просто інкремент в коді? При горизонтальному масштабуванні кілька інстансів сервісу можуть одночасно отримати однаковий index. PostgreSQL sequence атомарний – nextval завжди повертає унікальне значення. Ми використовуємо цю схему в проєктах з навантаженням до 10 000 адрес на день.

База даних та O(1) пошук

CREATE SEQUENCE payment_address_index_seq START 1;
CREATE TABLE payment_addresses (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    address VARCHAR(42) NOT NULL UNIQUE,
    derivation_index INTEGER NOT NULL UNIQUE,
    order_id UUID NOT NULL REFERENCES orders(id),
    network VARCHAR(20) NOT NULL,
    currency VARCHAR(20) NOT NULL,
    expected_amount NUMERIC(36, 18),
    received_amount NUMERIC(36, 18) DEFAULT 0,
    status VARCHAR(20) NOT NULL DEFAULT 'pending',
    expires_at TIMESTAMPTZ NOT NULL,
    confirmed_tx VARCHAR(66),
    created_at TIMESTAMPTZ DEFAULT NOW()
);
CREATE INDEX idx_payment_addresses_address ON payment_addresses(address);
CREATE INDEX idx_payment_addresses_status ON payment_addresses(status) WHERE status = 'pending';

Індекс по address – критичний для O(1) lookup при отриманні транзакції з блокчейн-лістенера. Без нього перевірка кожного вхідного переказу перетворюється на повний скан таблиці. Ми гарантуємо, що моніторинг працює в реальному часі навіть при 10 000 одночасно активних адрес.

Як здійснюється моніторинг транзакцій?

Наївний підхід – підписатися на всі згенеровані адреси. При великій системі це тисячі адрес. Краще: тримати in-memory set активних (pending) адрес, який оновлюється при створенні/закритті платежів.

class PaymentAddressMonitor {
    private activeAddresses: Map<string, PaymentAddress> = new Map();

    async loadActiveAddresses(db: Pool): Promise<void> {
        const result = await db.query(
            `SELECT address, order_id, expected_amount, currency, expires_at
             FROM payment_addresses
             WHERE status = 'pending' AND expires_at > NOW()`
        );
        for (const row of result.rows) {
            this.activeAddresses.set(row.address.toLowerCase(), row);
        }
    }

    onTransactionDetected(toAddress: string, amount: bigint, txHash: string): void {
        const payment = this.activeAddresses.get(toAddress.toLowerCase());
        if (!payment) return;
        const tolerance = payment.expectedAmount * 99n / 100n;
        if (amount >= tolerance) {
            this.confirmPayment(payment, txHash);
        }
    }
}

Multi-network: один index, різні адреси

EVM-сумісні мережі використовують один і той же приватний ключ – адреса однакова на Ethereum, BNB Chain, Polygon, Arbitrum. Це зручно: один index в таблиці можна використовувати для прийому платежів в різних мережах на одну адресу, але моніторинг потрібен окремий для кожної мережі. Такий мультивалютний прийом платежів значно спрощує інфраструктуру.

Для non-EVM (TON, Solana, Bitcoin) – окремі HD-деривації з різними master seed або різними шляхами деривації.

Безпека криптогаманця

• Master seed – в HSM або AWS KMS. Ніколи в змінних середовища.
• xpub для генерації адрес – окремо від xprv для підписання.
• Signing сервіс – ізольований мікросервіс з мінімальними привілеями.
• Аудит всіх операцій sweep – кожна транзакція логується з обґрунтуванням.
• Gap limit – BIP-44 рекомендує не дивитися глибше 20 послідовних невикористаних адрес при відновленні гаманця.

Етапи реалізації (під ключ)

Що входить в роботу

При замовленні розробки системи унікальних адрес ми надаємо:

• модуль генерації та моніторингу (вихідний код під вашу ліцензію);
• PostgreSQL схему з індексами та міграціями;
• скрипти деплою та налаштування HSM/KMS;
• документацію API та інструкцію з експлуатації;
• навчання вашої команди (2–3 дні);
• технічну підтримку на 3 місяці.

Зв'яжіться з нами для оцінки вашого проєкту – відповімо за 1–2 робочих дні. Замовте розробку та отримайте готове рішення, яке виключить втрати платежів та заощадить до 500 000 грн на рік на ручному розборі. Вартість впровадження системи – від 200 000 грн, що окупається менш ніж за півроку.

Джерело: BIP-44 специфікація на GitHub