Start with the job, not the product label
Crypto applications often collapse several distinct jobs into one screen. A user may connect a wallet, choose an asset, submit an order and see a balance update, but those actions cross separate systems with different responsibilities. A wallet provides an interface for managing assets and requesting actions; depending on its key-management and custody model, signing may happen within the wallet or be delegated to a separate signer or custodian. An exchange or decentralized exchange coordinates a trade. Liquidity determines whether a requested conversion can be carried out at an acceptable execution outcome. The chain or settlement system records state changes. Payments add another concern: whether the recipient can identify and use the value received.
For builders, the first useful artifact is a responsibility map. Take one user journey, such as converting one token into another and then sending the result. For each step, identify who creates the instruction, who authorizes it, where counterparties or liquidity come from, where execution occurs, how final state is observed, and what the interface tells the user. This exercise exposes hidden dependencies before they become confusing error messages or misleading balances.
Keep the map product-specific. A custodial service, a self-custody wallet and a protocol interface may all display an account balance, but they do not necessarily control the same keys or have the same recovery path. A payment flow may not need an exchange at all. A trading interface may need market and order state that a basic wallet does not provide. Treating these as separate components makes it easier to explain what the product does and what remains outside its control.
A wallet is an authority boundary
A wallet is not simply an account display or a container for token balances. Its authorization role depends on its key-management and custody model: it may produce signatures itself, coordinate approval with a separate signer, or request that a custodian execute an authorized action. The application can prepare a transaction, show its important fields and request approval, but the signing authority determines whether that instruction is authorized. This division matters for user consent, recovery design and security review. A polished interface does not make an unsafe signing flow safe.
When designing a wallet-connected feature, specify the signing boundary explicitly. Which fields does the user review? Can an application request an operation that differs from the one described in the interface? What happens if a transaction is delayed, rejected or submitted twice? How does the user distinguish a pending action from a completed one? These are implementation and testing questions, not just copywriting. Build cases for cancellation, malformed requests, stale state and session interruption.
For applications that need multiple operators or policy controls, a single signer may not match the operational model. Solana builders can examine the permissions and transaction-approval approach in Goki as a reference point for multisignature authority, timelocks and role-based control. Such mechanisms add coordination and configuration work: define who can propose, approve or execute, how changes to roles are protected, and what a delay is intended to accomplish. A multisig does not automatically secure an application; its policy and recovery procedures must be reviewed and tested.
Exchanges coordinate execution; they do not create value from nothing
An exchange is a mechanism for bringing buy and sell intent together and determining how an order is executed. In an order-book design, participants place orders at prices and quantities; the system matches compatible orders according to its rules. A decentralized exchange may put order management or settlement logic on chain, but the label alone does not tell a user how liquidity is supplied, how execution is triggered, or which operations require separate infrastructure.
A builder integrating an order-book component needs to account for more than the trading screen. Inspect the order format, cancellation behavior, matching rules, transaction construction, event or state-reading path and any off-chain service required to keep the market progressing. Then test partial fills, stale quotes, insufficient balances, failed transactions and concurrent order changes. The UI should distinguish an order that was submitted from one that was matched or settled. Dex V4 provides a concrete Solana example: an on-chain order-book program with JavaScript and WASM bindings and an associated cranking runtime. It is a protocol building block, not a complete consumer exchange, so teams still need to understand the runtime and assemble the application experience around it.
Order books also clarify why a price shown before submission is not a promise of the final result. Available orders can change, a request can match only in part, or execution can fail. State the assumptions behind displayed estimates and handle changes between quote and confirmation. Avoid presenting a protocol’s availability as a guarantee of execution quality; that depends on current market conditions and the system’s specific rules.
Liquidity is the capacity to execute a trade
Liquidity describes the ability to trade without an excessive change in execution terms. It is not the same thing as a token balance shown in a wallet, nor does a market’s existence establish that a particular order can be filled. In an order book, available counterparties and their order sizes shape execution. In other designs, liquidity may be organized differently. Builders should identify the actual source of executable inventory and the conditions under which it can be used rather than treating “available” as a binary feature.
When aggregating liquidity across venues, the application has to reconcile differences in market data, order sizes, fees, minimums, asset representations and failure behavior. A broker-style system can combine order-book depth, match offsetting interest internally, and route or split remaining orders. That can increase routing options, but it also creates operational responsibilities: venue connectivity, retries, reconciliation, partial completion and accurate user status. Bitcoin Broker illustrates this category of self-hosted BTC broker, including depth aggregation, internal matching, order splitting and retries across supported exchanges. Its documented setup uses a service and database, so it should be evaluated as an integration and operations reference rather than assumed to be a drop-in component for another chain or trading workflow.
A useful prototype test is to replay a range of order sizes against captured or controlled market data and record the routes the system would select, the assumptions it makes and how it handles unavailable venues. Keep routing policy separate from presentation. Users need a clear account of whether an order is pending, partially completed, retried or abandoned; hiding those states behind a single success indicator makes support and reconciliation harder.
Staking and payments are different product promises
Staking is commonly presented as a way to participate in a network’s validation or consensus design, but the word is not a complete specification. The mechanics depend on the particular chain and product: what asset or credential is committed, who controls the relevant keys, how rewards or penalties are determined, whether withdrawal is delayed, and which operations a user must perform. Do not borrow assumptions from one network or staking service and apply them to another without verifying its rules.
For implementation, document the state transitions and user obligations: initiation, active participation, any waiting period, withdrawal request and completion. Identify which facts are on chain, which are supplied by an external service, and how the interface detects a changed or failed state. Test the path where the user loses access, the relevant service is unavailable, or the product cannot confidently determine whether an action completed. If these cases are not supported, say so plainly rather than implying a universal recovery path.
Payments focus on delivery and recognition rather than market execution. A payment product must establish what asset and network a recipient can accept, how the sender obtains the correct destination, what confirmation means for the product, and how the recipient can reconcile incoming value. If the payment requires conversion, then exchange and liquidity concerns enter the flow, but they remain separate from the basic transfer. Keeping those functions distinct helps avoid implying that every payment can be converted immediately or at a guaranteed rate.
Turn the map into tests and operational boundaries
A functional layer map becomes useful when it changes the test plan. For each user action, record the authority boundary, the system that executes it, the source of current state and the criteria for reporting completion. Test both expected results and ambiguous ones: signature rejected, transaction submitted but not yet observed, order partially filled, venue unavailable, or the displayed balance behind the latest state. Build explicit status transitions instead of treating every request as a single success-or-failure event.
Separate what your product controls from what it depends on. You may control transaction construction and interface messaging while relying on a wallet for signing, a protocol for execution, an operator for market maintenance or a service for data. Assign monitoring and support ownership for each dependency. If a component can be replaced, define the interface and compatibility tests; if it cannot, record the migration cost and the assumptions that make the choice acceptable.
A practical next step is to choose one narrow flow and build a sequence diagram from user intent to confirmed application state. Mark every external boundary and write one failure test for each. Then prototype the wallet interaction, execution path and state observation independently before presenting them as a seamless product journey. This does not eliminate protocol or market risk, but it helps teams explain which layer is responsible, make limitations visible and avoid promising behavior that the architecture does not provide.