Softech Blog
Digital Assets & Financial Infrastructure

Integracja MPC Wallet: Signing, Policy, Recovery i Operations

Praktyczna architektura integracji MPC bez mieszania business authorization, signingu, blockchain execution i ledger posting w jeden krok.

2 min czytania
Integracja MPC Wallet: Signing, Policy, Recovery i Operations
Podsumowanie

Najważniejsze informacje z artykułu

Praktyczna architektura integracji MPC bez mieszania business authorization, signingu, blockchain execution i ledger posting w jeden krok. Kluczową decyzją jest to, kto kontroluje przepływ wartości, kto autoryzuje signing i który stan należy do blockchaina, a który do product ledgera.

Najważniejsze wnioski
  • Wybierz control model przed wyborem vendora walletów.
  • Oddziel business authorization od cryptographic signing.
  • Mapuj każdy wallet/adres do kanonicznej encji produktu.
  • Oddziel stan depozytu klienta od stanu treasury sweep.
  • Zaprojektuj recovery i reconciliation przed startem produkcji.
Kluczowe obserwacje

Kluczowe obserwacje i tezy

Najważniejsze obserwacje podsumowujące doświadczenia, decyzje i rezultaty opisane w materiale.

Wallet SDK nie powinien przypadkiem definiować modelu custody.
Signing authority i business authorization to osobne kontrole.
Saldo blockchain jest dowodem aktywów, nie kompletnym product ledgerem.
Treasury movement nie powinien zmieniać faktu, czy depozyt klienta był poprawny.

Co rozwiązuje MPC — a czego nie

Multi-party computation może usunąć pojedynczą granicę raw private key przez rozdzielenie signing material/participation. Nie decyduje, czy transakcja powinna się odbyć, czy destination jest dozwolone, czy kwota przekracza limity ani czy product ledger powinien zostać zmieniony. To nadal odpowiedzialność aplikacji.

Granica integracji produkcyjnej

Solidna integracja MPC ma co najmniej cztery oddzielne warstwy: business authorization → signing request → blockchain execution → business posting. Poprawny podpis jest dowodem, że signing system zatwierdził operację kryptograficznie, a nie że proces biznesowy się zakończył.

Policy przed signingiem

Sprawdzaj actor, role, transaction intent, asset, network, amount, destination, velocity limits i approval. Treasury często potrzebuje multi-person approval albo policy engine providera; programmatic wallets mogą wymagać application-side policy przed wywołaniem API.

Idempotency i correlation

Każdy signing request powinien mieć stabilny business operation ID. Zapisuj provider request IDs, transaction hash i transition statuses. Retry po timeout nie może stworzyć drugiego withdrawal.

Recovery i key rotation

Zaprojektuj recovery dla user access, operator access, entity secrets, signer changes i provider migration. Recovery powinno być testowane, udokumentowane i oddzielone od normalnych transaction privileges.

Pytania przy wyborze providera

  • Kto kontroluje każdy signing share lub credential?
  • Czy signing może działać server-side?
  • Jakie approval policies są natywne?
  • Jak wygląda recovery?
  • Jak eksportowane są audit events?
  • Co dzieje się przy częściowym outage?
  • Jak reprezentowane są EVM i non-EVM accounts?
  • Czy możemy utrzymać provider-neutral wallet registry?

MPC nie zastępuje ledgera

Nawet idealna infrastruktura signing nie powie finansom, dlaczego wartość się przesunęła. Wallet execution references powinny być spięte z product-owned ledgerem i reconciliation timeline.

Wzorzec implementacji

Transaction Intent → Authorization Policy → Approval(s) → MPC/Signing API → Broadcast → Chain Observation → Finality → Ledger Posting → Reconciliation.

Taka kolejność daje jasne failure boundaries i pozwala operatorowi odpowiedzieć, na którym etapie zatrzymała się transakcja.

Model rozwiązania

Kluczowe elementy i zależności

Wallet Control Architecture

Pięć warstw rozdzielających ownership, authorization, signing, execution i accounting.

Warstwa 1
Control model

Kto ekonomicznie kontroluje aktywa i kto może inicjować ruch wartości.

Warstwa 2
Authorization

Polityka produktu dla ról, limitów, destination i transaction intent.

Warstwa 3
Signing

MPC, passkey, key lub smart-account mechanism autoryzujący wykonanie blockchain.

Warstwa 4
Execution

Submission transakcji, obserwacja i finality w sieci.

Warstwa 5
Ledger & operations

Stan produktu, treasury, recovery, monitoring i reconciliation.

Źródła i kontekst

Informacje wspierające analizę

Circle documents developer-controlled wallets for backend-controlled automation, user-controlled wallets for user-approved transactions, and modular wallets for custom wallet experiences.

Circle documents developer-controlled wallets as API-driven wallets where the application controls creation, transaction execution and signing.

Circle documents user-controlled wallets as user-owned wallets where users authenticate and approve transactions from their device.

Fireblocks documents vault, policy and wallet infrastructure for controlling digital-asset operations and treasury workflows.

Coinbase CDP documents non-custodial wallet infrastructure and programmatic wallet APIs for application-integrated wallets.

Czytaj dalej

Powiązane artykuły

Materiały, które rozwijają temat i uzupełniają go o dodatkowy kontekst praktyczny.

Autor

Matt Dudzicz · Softech.app

Founder

Founder Softech.app, skoncentrowany na product engineeringu, infrastrukturze digital assets, custom software i systemach biznesowych AI-native.

LinkedIn
Następny krok
Projektujesz embedded wallet, MPC albo treasury?
Zmapujemy control model, signing policy, recovery, ledger i operacje zanim wybierzemy providera oraz SDK.