Softech designed native stablecoin payment infrastructure for an NDA-protected client using dedicated blockchain addresses. The solution does not treat an on-chain transfer as a finished user balance: an address is first linked to business context, an observer detects the event, the system validates network, token and amount, a confirmation engine waits for the chosen finality policy, and only then does the internal ledger apply the business effect. Sweeping and treasury operate separately, so an internal treasury failure does not invalidate an otherwise correctly credited customer payment.
Business context and the situation before implementation
In this product, blockchain payment was part of the core domain rather than a checkout add-on. The system had to identify customer deposits deterministically and process them automatically without relying on manual explorer checks or a shared treasury address.
- A payment address had to map to a user, account or specific payment intent.
- Transfers had to be validated by network, token contract, destination and amount.
- The system had to separate transaction detection from final product credit.
- After crediting, funds could move through a separate treasury workflow without altering user history.
Before state
The simplest model — one shared wallet with manual transaction checks — does not scale operationally and does not provide deterministic mapping from transfer to obligation. It is equally risky to derive product balance directly from the current blockchain balance.
- A shared address makes deterministic ownership and payment-purpose mapping difficult.
- RPC or indexer availability can be interrupted, so the observer must replay missed blocks.
- A technically valid transfer may still use the wrong token, network or amount.
- Treasury movement after payment is a different process from crediting the user obligation.
Goals, success criteria and constraints
Discovery covered address ownership, payment-intent lifecycle, finality policy, blockchain data sources, replay requirements, invalid-transfer classification and the boundary between customer ledger and treasury. The key decision was to treat blockchain as an event source rather than the product accounting ledger.
Product goals
- Assign dedicated addresses to business context without exposing private keys to the application layer.
- Detect stablecoin transfers with replay capability and without duplicate processing.
- Validate network, token contract, destination, amount and finality policy.
- Credit payments in an internal ledger independent of blockchain balance.
- Separate treasury sweeping from the customer payment lifecycle and provide exception handling.
Success criteria
- Every observed transfer has a deterministic event key and can be safely reprocessed.
- The product does not credit payment before finality and token-validation rules are satisfied.
- An RPC or indexer outage does not permanently lose a payment event.
- A sweep failure does not reverse a correctly credited customer payment.
- Operations can distinguish underpayment, overpayment, wrong token, wrong network and manual-review cases.
NDA and key security
We do not disclose the exact custody model, derivation paths, addresses, key providers or production security parameters.
Asynchronous finality
Detecting a transfer does not automatically mean the product should credit the user immediately.
Multiple failure domains
RPC, indexer, queue, database and sweep service can fail or become unavailable independently.
Custody and application separation
The product layer should not have direct access to keys capable of unrestricted treasury transfers.
Analysis and product decisions
- We defined ownership and lifecycle of a dedicated payment address.
- We established deterministic event identity from transaction, log index and network context.
- We defined checkpointing and safe block-replay boundaries.
- We mapped DETECTED, CONFIRMING, CONFIRMED, CREDITED and exception states.
- We separated payment acceptance from sweeping and later treasury management.
Solution architecture
The system combines address allocation and wallet registry, a checkpointed blockchain observer, validation and confirmation engine, event store, internal ledger and a separate sweep/treasury pipeline. Each layer is designed to be recoverable and replayable without crediting the same payment twice.
- 01Layer 01
Address allocation and wallet registry
A dedicated address receives an explicit link to a user, account or payment intent together with lifecycle state.
Dedicated addressesWallet registry - 02Layer 02
Blockchain observer
The observer reads blocks and token events, stores checkpoints and can safely replay a range after a data-source outage.
RPC / indexerCheckpointingReplay - 03Layer 03
Validation and confirmation engine
The layer validates network, token contract, destination, amount and the selected confirmation policy before crediting.
Token validationFinality policyState machine - 04Layer 04
Blockchain event store and internal ledger
The raw blockchain event is preserved as evidence, while an accepted payment event creates a controlled entry in the product ledger.
Event storeInternal ledgerIdempotency - 05Layer 05
Sweep, treasury and operations
After payment credit, funds can move according to treasury policy while exceptions are routed to controlled operator workflows.
Sweep serviceTreasury workflowOperational review
Problems, decisions and implemented capabilities
A single shared address would not deterministically identify deposit ownership.
Addresses are allocated and registered against a specific user or payment intent.
Deterministic deposit mapping
A transfer can be mapped to the correct domain context without guessing from amount or memo.
A data-source outage could cause a block to be missed.
The observer stores checkpoints and supports safe range replay.
Recoverable chain observation
After recovery, the system can catch up on events without duplicate credits.
A token transfer alone does not guarantee payment validity.
Before crediting, the system checks network, token contract, destination, amount and finality.
Validated payment acceptance
Wrong token, wrong network and mismatched amounts are not automatically credited as valid user balance.
Blockchain balance does not represent product obligations and history.
An independent internal ledger is used as the business source of truth.
Product ledger independent of chain balance
Product balance preserves history and domain semantics independently of later treasury movements.
Treasury sweeping may fail even after a valid customer payment.
Customer credit and sweeping use separate state machines and retry policies.
Decoupled treasury operations
An internal treasury transfer failure does not reverse a correctly confirmed customer payment.
Technology decisions
| Technology | Role | Rationale | Trade-off |
|---|---|---|---|
| Dedicated deposit addresses | Deposit identification | The address becomes a stable routing key from a transfer to specific business context. | More addresses increase registry, monitoring and custody-policy complexity. |
| RPC / indexer observer | Blockchain event source | It enables automated token-transfer detection and historical reconstruction from blocks. | It requires redundancy or recovery strategy for unavailable or inconsistent sources. |
| Checkpoint + replay | Recoverability | The system knows the last processed range and can replay scanning after failure. | Replay must be fully idempotent and efficient over larger ranges. |
| Confirmation engine | Finality | It separates DETECTED from CONFIRMED and allows finality policy to match network and product risk. | More conservative policies increase user waiting time. |
| Internal ledger | Business state | It preserves obligations and history independently of current blockchain and treasury balances. | It requires explicit synchronization and reconciliation with the on-chain layer. |
| Sweep service | Treasury movement | It consolidates funds or applies treasury policy without burdening the customer payment lifecycle. | It introduces a separate domain for fee management, nonce handling and retries. |
Integrations and data flows
Blockchain RPC / indexer
Chain → observerProvides blocks, logs and token-transfer events to the detection layer.
Checkpointing and replay reduce the risk of event loss during temporary source outages.
Wallet / custody layer
Allocator ↔ wallet layerProvides payment addresses and controlled execution for later transfers without exposing keys to the product domain.
The public description does not disclose the exact custody or key-management model.
Treasury operations
Ledger → sweep / treasuryTriggers internal fund movement only after the payment event has been correctly credited.
Sweeping has separate state and retries, so failure does not change customer payment status.
AI, security and reliability
No private keys in the product domain
Application logic works with wallet identifiers and controlled requests rather than raw signing secrets.
Deterministic event identity
Every blockchain event receives a stable identity so replay and multiple sources cannot create duplicate credits.
Checkpointing and backfill
The observer stores progress and supports controlled backfill of missing blocks.
Separate state machines
Customer payment, confirmation and treasury movement are not one status, so downstream failure cannot reverse a correct deposit.
Manual review instead of automatic guessing
Invalid or ambiguous transfers are routed to review instead of changing balance based on heuristics.
Implementation, testing and release
- 1Phase 1 / Wallet domain
Define address ownership, allocation lifecycle and custody boundary.
- Wallet registry
- Address allocation rules
- Custody boundary contract
Result: Addresses gained explicit business-context relationships without moving signing secrets into the application.
- 2Phase 2 / Chain observation
Detect transfers with checkpointing, replay and deterministic event identity.
- RPC/indexer adapter
- Checkpoint store
- Replay and deduplication
Result: The observation layer can catch up on missed events and safely process them again.
- 3Phase 3 / Validation and ledger
Separate detection, confirmation and final product credit.
- Token/network validation
- Confirmation state machine
- Internal ledger entries
Result: Product balance is created only after payment rules are satisfied and preserves its own history.
- 4Phase 4 / Treasury and operations
Add sweeping, retries, monitoring and manual handling for ambiguous events.
- Sweep state machine
- Treasury reconciliation
- Operations exception queue
Result: Fund movement and exceptions were separated from the core customer payment lifecycle.
Replay of the same block range
Re-scanning cannot create another payment credit for an already processed event.
Wrong token / wrong network
A transfer to a known address that violates asset or network rules becomes an exception rather than valid balance.
Underpayment and overpayment
Amounts different from expected are not automatically normalized without an explicit product policy.
RPC outage and catch-up
After a controlled outage, the observer resumes from checkpoint and catches up on missing events.
Sweep failure
A failed treasury transfer remains retryable and does not change the status of a correctly credited customer payment.
What confirms the project description
The case study does not publish on-chain volume, address count or treasury data. Technical outcomes are described through verifiable architecture properties: deterministic mapping, replay, validation, controlled finality, an independent ledger and separation of customer payment from treasury operations.
| Scope | Basis | Reference | Confirmation | Interpretation boundary |
|---|---|---|---|---|
| A dedicated address is linked to business context before transfer acceptance. | Wallet architecture diagram | CW-01 · project material and implementation architecture | Operationally confirmed | The public diagram does not reveal derivation or custody design. |
| Transfer detection and final payment credit are separate states. | Observer and confirmation diagram | CW-02 · project material and implementation architecture | Operationally confirmed | Exact finality thresholds for production networks remain confidential. |
| The observer can replay block ranges using checkpointing and idempotent processing. | Observer and confirmation diagram | CW-02 · project material and implementation architecture | Operationally confirmed | RPC provider topology and redundancy configuration are not published. |
| The product ledger is independent of blockchain balance and later sweeping. | Ledger and treasury diagram | CW-03 · project material and implementation architecture | Operationally confirmed | The public version does not expose the client internal accounting schema. |
| Treasury sweeping is a separate workflow with its own state and retries. | Ledger and treasury diagram | CW-03 · project material and implementation architecture | Operationally confirmed | Treasury addresses and fee-management rules remain confidential. |
| Wrong token, wrong network and mismatched amount are classified before crediting. | Observer and confirmation diagram | CW-02 · project material and implementation architecture | Operationally confirmed | The public diagram shows exception classes rather than the client exact risk rules. |
How to read this information
- Address and active-wallet counts are not published.
- Production networks, finality thresholds and transfer volumes are not published.
- Custody model, key providers and treasury addresses are not published.
- Outcomes are described as system capabilities rather than percentage business KPIs.
Process change, decision consequences and lessons
| Area | Before | After | Business impact |
|---|---|---|---|
| Deposit identification | A shared address would require extra heuristics or manual mapping. | A dedicated address has explicit ownership and payment-intent context. | A transfer can be mapped automatically to the correct domain context. |
| Blockchain detection | An event missed during an RPC outage could remain unnoticed. | Checkpointing and replay allow the range to be scanned again. | The system can recover state without manually inserting transactions. |
| Finality | A detected transfer could be credited too early. | The confirmation engine separates DETECTED, CONFIRMING, CONFIRMED and CREDITED. | Risk policy becomes explicit and controlled. |
| Product balance | Blockchain balance mixes technical funds with user-obligation semantics. | The internal ledger preserves domain state independently of where funds are held. | Treasury can change without changing customer history. |
| Treasury | Fund consolidation would sit in the same path as customer payment. | Sweeping runs as a separate retryable workflow. | A treasury failure does not invalidate a correct deposit. |
Dedicated addresses
- Alternative
- One shared address
- Trade-off
- More wallet objects and higher operational registry cost.
- Rationale
- Deterministic payment mapping is more important than the simplicity of one address.
Checkpointed observer
- Alternative
- Realtime websocket only
- Trade-off
- More processing logic and checkpoint storage.
- Rationale
- The system can recover from interruption and does not depend on one continuous connection.
Internal ledger
- Alternative
- Blockchain as the only balance source
- Trade-off
- Additional reconciliation and data layer.
- Rationale
- It preserves obligation, refund and product-history semantics.
Separate sweep workflow
- Alternative
- Immediate sweep before payment credit
- Trade-off
- More operational states and retries.
- Rationale
- Customer payment is not blocked by a treasury operation that can fail independently.
Key lessons learned
- A blockchain address is a technical identifier; the payment intent gives it business meaning.
- The observer should support replay from day one because a realtime event stream is not a completeness guarantee.
- A blockchain event and product-ledger entry should have an explicit auditable relationship without being the same record.
- Finality policy is a product and risk decision, not an arbitrary confirmations value in code.
- Treasury is a downstream process and should not decide whether a valid customer payment exists.
Which organisations this model is relevant for
FinTech and account-based products
When stablecoin deposits fund a user account or affect the core product balance.
Marketplaces and multi-sided platforms
When the system must distinguish many payers, beneficiaries and treasury flows.
Products with treasury workflows
When funds require consolidation, allocation or other internal operations after payment.
Systems requiring on-chain control
When a managed gateway does not provide enough control over addresses, transfer identification or product state.
Related expertise and services
Crypto Wallet Development
BOFU path for embedded/programmatic wallets, MPC, deposit addresses and treasury operations.
Crypto & Stablecoin Payment Systems
Service covering custom wallet infrastructure, on-chain monitoring, ledger and treasury.
Digital Assets & Blockchain
Softech hub for blockchain and digital-asset infrastructure services.
Smart Contract Development
Related capability for products combining payments with programmable on-chain logic.
USDC + CoinGate managed settlement
Alternative model using a managed payment provider instead of a custom wallet layer.
Node.js
Backend event processing, queues and integrations for transaction systems.
API Engineering
Contracts between wallet layer, observer, ledger, treasury and product.
Need a native payment rail instead of a managed gateway?
We can design wallet allocation, blockchain observation, confirmation policy, internal ledger, reconciliation, sweeping and treasury so payment becomes part of the product domain rather than merely a transfer to an address.
Key confirmed facts
The following statements summarise the confirmed product scope and contain no unapproved growth data.
- 1
The client project is protected by an NDA and the organization name is not published.
- 2
The implementation uses dedicated addresses to identify stablecoin deposits.
- 3
The system maintains a registry linking addresses to business context.
- 4
The blockchain observer uses checkpointing and replay capability.
- 5
Transfers are validated by network, token contract, destination and amount.
- 6
Transfer detection is separated from final product credit.
- 7
Product balance is maintained in an independent internal ledger.
- 8
Sweeping and treasury are separated from the customer payment lifecycle.
- 9
Invalid or ambiguous transfers are routed into controlled exception handling.
- 10
The custody model, keys, addresses, volumes and security parameters are not published.
Visual evidence
The diagrams present confirmed product scope and workflows described in this material. They are not mock-ups or claims of undocumented outcomes.
FAQ
Does every customer need a separate wallet?
Not always. A dedicated address may be assigned per user, account, invoice or payment intent depending on the business model, privacy, cost and custody approach.
Why is blockchain balance not the user balance?
An address balance only tells you how much value is on-chain. It does not tell you which obligation a transfer belongs to, whether it was accepted, whether it is final or whether the product has already credited it.
How does the system handle RPC or indexer outages?
The observer stores checkpoints and processes blocks idempotently, so it can resume from a known point or replay a selected range without crediting the same event twice.
Does a treasury sweep have to complete before the customer payment is complete?
No. Crediting the payment intent and moving funds to treasury are separate workflows. A sweeping failure should not reverse an otherwise correctly confirmed customer payment.
How are wrong tokens and networks handled?
Transfers are classified by network, token contract, destination and amount. Events that do not satisfy payment-intent rules are not automatically credited as valid payments.
