Most build guides for decentralized app development still start in the wrong place. They tell you to pick Solidity, connect a wallet, pass an audit, and ship. That sequence produces a contract demo, not a product finance can close.
A public chain will execute whatever you deployed. It will not tell operations which deposit is final, who was allowed to sign the payout, or why yesterday's balance no longer matches the chain. I would treat event handling, ledger design, reconciliation, signing policy, and recovery from irreversible mistakes as architecture from day one. The contract is only the lock.
Table of Contents
- What Decentralized App Development Really Covers
- The Four Layers Every dApp Needs
- Choosing a Wallet and Signing Model
- Event Streams and Ledger Design
- Integration Patterns by Business Model
- Compliance and Risk Controls to Set First
- How to Move From Sandbox to Production
- Frequently Asked Questions
What Decentralized App Development Really Covers
The contract-only view is the enemy. A smart contract with a web page attached is not an application. Decentralized app development means building software whose core state transitions run on a public blockchain, while users, operators, and auditors work through off-chain systems that they can run themselves.
Think of the contract as the vault lock. The bank still needs tellers, signing procedures, statements, and a closing routine. Wallets, broadcasting, event monitoring, and reconciliation are those routines. Teams that leave them unplanned meet the gap in launch week, when a deposit sits pending and nobody owns the ledger.
Usage is already large enough that those routines have to scale. DappRadar's 2024 industry report found that decentralized applications averaged 24.6 million daily unique active wallets by year-end, a 485% increase during the year.
Scope also includes policy. Who may request a transfer, which network and asset are allowed, when a pending state becomes a credited balance, and how finance keeps its own copies. You can export account information and transactions through the app or documented API, and you remain responsible for the copies accounting, compliance, and continuity require.
At BroLabel, the goal is to make financial products easier to build without requiring teams to create every infrastructure layer themselves. The path below is architecture layers, signing models, event and ledger design, integration by business model, risk controls, the move from sandbox to production, and the buyer questions that usually show up last.
The Four Layers Every dApp Needs
A port is a clearer picture than a generic stack slide. The contract sets the customs rules. The signing layer holds the gate keys. Broadcast moves the ships. The ledger is the port log finance trusts when the day closes.
Most applications are not a crowd of contracts. An empirical study of Ethereum dApps reported that 70.57% of applications used only one smart contract, while 90.46% used fewer than three. The hard work sits in wallets, indexing, compliance, and operations. A weak contract is painful to correct after deployment. A weak off-chain layer can be patched. Contract quality is not system quality.
What breaks when a layer is thin
Read the failure column as the incident you will page on.
| Layer | Job | Typical failure | Example component |
|---|---|---|---|
| On-chain contracts | Verifiable state changes and authorization rules | Irreversible logic bugs after deployment | Token, escrow or payout contracts |
| Signing and wallets | Authorize each transaction under defined policy | Compromised key or weak approval flow | MPC 2-of-3 signing with client-controlled Co-Signer |
| Broadcast | Submit transactions and track their status across networks | Stuck, replaced or silently dropped transactions | Submission across 10 supported networks |
| Events and ledger | Record observations, confirmations and decisions | Duplicate, missing or overwritten entries | Append-only operating ledger with reconciliation |
| Application interface | Show balances, flows and pending states to users | Pending transactions displayed as final | Web, mobile or Telegram front end |
BroSettlement covers signing and broadcast: DKG, MPC signing, network submission, and a Co-Signer under the customer's control, across 10 networks. Next to it sit an immutable operating ledger, real-time events, and REST plus OpenAPI tooling with Ed25519 authentication. The platform is API-first infrastructure for embedded MPC wallets, operational logs, card products, and fiat integrations.
Owned, bought, or missing
Mark each layer before you staff a sprint.
- Volume you cannot forecast. Buy broadcast and the ledger rather than building a queue you will rewrite.
- Compliance load. Heavier audit duties need an exportable ledger, not rotating application logs.
- Network count. One chain and ten chains are different broadcast problems.
- Time to market. Buy the layers that fail irreversibly. Keep the interface if that is your product.
Choosing a Wallet and Signing Model
One private key on one server, or on one engineer's laptop, is a total-loss design. One compromise authorizes every payout. I would not ship that past a prototype.
Three wallet shapes cover the products founders usually describe. Consumer apps use user wallets. Automated systems use per-agent wallets, so each agent has an owner. Operator platforms, including iGaming, use per-player wallets so a deposit address is not a shared hot wallet.
Where the key actually lives
| Signing model | Where key material sits | Single point of failure | Best fit |
|---|---|---|---|
| Single private key in the application | One server, device or engineer | Yes | Prototypes and test environments only |
| On-chain multisig contract | Contract with several named owners | Partial, and only if the signers are truly separate | Treasuries that need on-chain governance |
| MPC 2-of-3 with client-controlled Co-Signer | Split key shares; no single share can sign alone | No single share or party can sign alone | Production payouts and embedded wallets |
| Provider-held custodial key | Inside the provider's systems | The provider | Simple onboarding with low operator control |
Key management is an organizational control problem, not only an algorithm choice. NIST SP 800-57 splits the work into protection of keying material, organizational policy and security planning, and application-specific use of cryptographic features. A 2-of-3 arrangement without those boundaries is only a clever key store.
The policy a Co-Signer has to carry
The client-controlled Co-Signer in BroSettlement should run on a written signing policy.
- Who may request. Named roles, not a shared admin login.
- Who may approve. A different system from the one that built the transaction.
- Amount limits. Per transaction and per day, with a second approval above a threshold.
- Emergency recovery. Who can restore a share, and who cannot.
- What gets logged. Every request, approval, rejection, and broadcast attempt.
If your configuration uses a customer-managed Co-Signer, or customer-controlled signing or recovery materials, you operate and protect those components. That includes access control, backups, and approval rules. MPC removes dependence on one key location. It does not remove a malicious transaction, a weak approval path, or a signer who is offline when payroll is due.
Separate creation from authorization, and evaluate policy before any signature is released. Scoped API keys, with IP allowlists and replay protection, are a second boundary so a leaked token cannot sign from anywhere. If you are still comparing account models, read account abstraction wallets and then decide whether the user holds a smart account or you embed the wallet behind the policy above.
Practical rule: If one person, or one compromised system, can move funds alone, the model is not ready for production payouts.
Event Streams and Ledger Design
A first-seen chain event treated as final is the enemy in this layer. A deposit notification is a sighting, not a credit.
Geth's publish/subscribe documentation describes JSON-RPC subscriptions over a full-duplex connection, commonly WebSocket or IPC. The node returns a subscription ID and pushes a notification when a subscribed event occurs. You stop polling. You do not gain delivery guarantees, accounting completeness, or finality.
A deposit that can still change
Say an operator watches a player's TRC20 deposit.
- deposit.observed writes a pending state. The player sees pending, not a spendable balance.
- deposit.confirmed advances that state only after your confirmation threshold.
- A payout is released only after operator policy passes.
Connections drop. Notifications repeat and arrive out of order. Ethereum's execution API allows removed logs to be pushed with removed: true. Append a reversal. Do not delete the original observation. The same split is why teams study decoupling services for safer releases before they let one consumer both watch the chain and pay out.
Three records, not one row
Keep the external network event, the internal ledger entry, and the business decision apart. Collapsing them is how a reorg overwrites the only evidence finance had.
| Field | Purpose |
|---|---|
| chain | network where the event was observed |
| transaction hash | identifies the on-chain transaction |
| log index | separates several logs inside one transaction |
| event version | lets handlers process corrected or reversed events |
| subscription ID | links each notification to its stream |
Withdrawals need an idempotency key so a retry cannot create a second payout. Run reconciliation on a schedule, hourly is a sound default, and compare ledger totals and statuses with authoritative chain data. Flag every difference for a person, not only a log line. The integration surface for this is a REST API, Ed25519 authentication, and WebSocket events. How reviewers walk that trail belongs in a written audit workflow.
WebSockets improve timeliness and cut polling load. They are a notification bus, not settlement.
The test is simple. Could finance explain every balance change from the ledger alone, without application logs? If not, the ledger is still a cache.
Integration Patterns by Business Model
One stack serves five different owners of the balance. Who holds the money, and how it leaves, changes the wallet, the events, and the ledger you reconcile.
| Business model | Wallet model | Event feed | Ledger focus |
|---|---|---|---|
| Crypto exchange | User deposit and withdrawal wallets | deposit.observed, deposit.confirmed, withdrawal status | Customer balances matched to chain state |
| iGaming operator | Per-player TRC20 USDT deposit addresses | deposit events and operator policy outcome before payout | Player balance reconciliation |
| Neobank or fintech app | Per-user embedded wallets | Deposit, transfer and withdrawal status | Account ledger matched to fiat statements |
| AI agent platform | Per-agent wallets with role-based access | Transaction and policy outcome events | Audit trail per agent and owner |
| Enterprise treasury | Multi-wallet structure with approval policy | Confirmation and approval events | Treasury ledger matched to bank records |
iGaming, one address per player
Do not share one USDT address across players. Give each player a TRC20 USDT deposit address, consume deposit events, and evaluate an operator policy before signing a payout. Keep an append-only log for reconciling player balances. The policy is the gate. The log is what finance opens when a player disputes a credit.
Agents need a named owner
AI agent wallets are per-agent and non-custodial, with role-based access and an audit trail. Every action has an owner. Without that, a runaway agent and a compromised prompt look identical, and risk cannot tell which one to stop.
Heavier ledgers, same networks
BroSettlement MPC wallets operate across 10 networks, including BTC, ETH, SOL, BNB, TRX, POL, BASE, and ARB. Confirm the set for your workflow in current API documentation before you scope a launch. The same base covers exchanges, neobanks, payment gateways, DeFi platforms, enterprise treasury, stablecoin platforms, and iGaming and betting.
A neobank or treasury team should weight the ledger more than the event feed. Fiat statements will not match a chain notification by themselves. Write down wallet count, event types, and the reconciliation owner before you pick a row. If nobody owns reconciliation, you have a demo.
Compliance and Risk Controls to Set First
Unowned responsibility is the failure mode. The provider will not absorb a wrong address. The network will not unwind a bad broadcast. An audit will not run Monday's incident.
Public blockchains, validators, token issuers, and independent providers may fail, delay, or reject transactions, reorder blocks, or change the visible status of a transaction. You account for that in your own confirmation, reconciliation, and end-user servicing rules. You are also responsible for addresses, network and asset selection, amounts, recipient data, transaction instructions, and your compliance decisions. Blockchain transactions may be irreversible.
A withdrawal sent to a valid address on the wrong network is the plain case. Nobody pulls it back for you.
What a test actually proves
Scanners disagree with each other and miss exploitable behavior, so one scan is not a release gate. Combine scanning with property-based fuzzing and manual review, weighted by what the contract does. Financial contracts need arithmetic and oracle checks. Token contracts need authorization and allowance checks. A finished audit is evidence about code at one moment. It is not a running control plan.
CertiK's Hack3d 2025 Web3 security report recorded approximately $3.35 billion in losses, up 37.06% from 2024, with supply-chain attacks alone accounting for about $1.45 billion across two incidents. Dependency and wallet-integration monitoring belong on the launch checklist for that reason.
AML checks apply only when they are set up for a specific service and defined by its configuration, the customer contract, applicable requirements, or the provider involved. Any regulated service or custody role must be defined in a signed contract and backed by the right permits. Once those checks are configured in practice, understanding AML monitoring with Portreeve gives a clear outside view, and it should line up with your compliance management process.
Controls to write down
- Pre-broadcast checks on address and network before any signature.
- Recipient allowlists for treasury and payout destinations.
- Amount limits with dual approval above a threshold.
- Role-based access so request, approve, and broadcast stay separate.
- A runbook for pause, incident response, and user notification.
- Continuous reconciliation against chain data, on the schedule the ledger job already runs.
A compliance lead should answer, in writing, who approves, who can stop a flow, and who tells users when a transaction is delayed or reversed.
How to Move From Sandbox to Production
Working and test environments are separated. Access to the test environment does not establish availability, limits, or performance in the working environment. A sandbox pass is a rehearsal, not a capacity claim.
- Verify scope. In the app and current API documentation, confirm environment, enabled network, asset, transaction type, limits, and operational requirements for each workflow. A mismatch here fails the launch before the first real user.
- Build and test in the sandbox. Exercise signing and broadcast with test funds. Test speed is not production speed.
- Write the signing policy. Roles, approving systems, amount limits, recovery, and logging. Name who controls the Co-Signer.
- Wire events and the ledger. Stable business keys, idempotent handlers, and append-only reversals. Do not invent a second event model here.
- Run reconciliation drills. Duplicate notifications, a dropped connection, and a simulated reorg. Totals match before anyone names a date.
- Set contracts and controls. Sign any regulated or custody agreement, configure AML checks for that specific service, and finish the incident runbook. Standard access to BroSettlement is by registering and activating a tariff plan in the app. The standard self-service plan does not require a separate master services agreement. Regulated roles still need their own contract.
- Launch at low volume. Staged limits, then a review of events and fee calculations over the first weeks. Raise limits only after that review.
Fix the go-live date only after steps 1 to 5 are signed off by engineering, finance, and compliance.
Frequently Asked Questions
Is a smart contract audit enough before launch?
No. An audit describes code at one moment. Launch still needs a signing policy, event handling, reconciliation, and a runbook.
Do we need MPC or is a multisig enough?
It turns on signer independence. MPC 2-of-3 with a client-controlled Co-Signer fits production payouts. An on-chain multisig fits treasuries that want governance visible on-chain.
How do we avoid crediting a deposit twice?
Use a stable business key of chain, transaction hash, log index, and event version, and process it idempotently. If a log arrives with removed set to true, append a reversal.
Do WebSockets guarantee we capture every deposit?
No. They improve timeliness and reduce polling. They do not provide delivery guarantees, accounting completeness, or finality. Scheduled reconciliation against chain data is still required.
Which networks are supported?
10 networks in total, including BTC, ETH, SOL, BNB, TRX, POL, BASE, and ARB. Confirm the full list in current API documentation before you scope a workflow.
Who is responsible if funds go to the wrong address?
You are. Address, network, asset, and amount are customer responsibilities, and the transaction may be irreversible.
BroLabel gives production teams embedded MPC wallets, a client-controlled Co-Signer, network broadcast, an append-only operating ledger, and WebSocket events, so decentralized app development does not stop at the contract. If you are setting signing policy, deposit handling, and reconciliation before go-live, start in the sandbox and wire those controls with us. Bro has your back! Visit BroLabel when you are ready to run the stack against a real workflow.
