How Does a Customer Account Lead to a Blockchain Signature?
Customer A signs in to a financial service to send 10 tokens to B. The business application knows that the customer who signed in is A. But a blockchain transaction needs A's sending address and a signature for that address's transaction, rather than A's login information.
This connection raises a question that cannot be settled with a single mapping: Which wallet does A's request select, and who decides whether that wallet may execute this transaction?
BXB is middleware that connects business applications to blockchains. It provides a custodial wallet path in which an institution manages keys and executes signing on the server. This article follows a small transfer of 10 tokens to examine the relationships between a customer account, a wallet, an address, and a signing key.
The connections behind a transfer of 10 tokens
Suppose token T exists on an EVM network, and A and B each have an address. The EVM is the contract execution environment used by Ethereum-compatible networks. Before the transfer, A holds 100 tokens and B holds none. Here, we follow the path in which the BXB server signs and submits the transaction using the key linked to the wallet.
The goal is simple.
| Customer | Before | After |
|---|---|---|
| A | 100 | 90 |
| B | 0 | 10 |
Assume there is no token issuance, burning, separate token transfer fee, or other concurrent transaction. The native coin needed for network fees is available separately. This is an illustrative example for examining how the process works under these conditions.
The business application authenticates A and decides whether A may send 10 of these tokens to B. It must then select the wallet linked to A, construct the transaction, and have it signed.
Customer A's transfer request
↓
Business application:
authenticate A and
authorize the transfer
↓
Select the wallet linked to A
↓
Check its address on
the selected network
↓
Check blocking rules
and sign the transaction
↓
Submit to the blockchain
and check the execution result
↓
Token balances: A 90 / B 10
The retrospective on the path from Polsto to BXB explained why we brought these connections together in shared middleware. Here, we look more closely at how a customer's request selects the wallet and key that will sign.
How does a customer ID relate to a wallet alias?
Suppose A's customer ID is C-A. The business application can link this customer to the business alias
customer-a in BXB. In BXB's code, this alias is called userKey.
Despite the word “key,” it is not the private key used for signing.
Putting the identifiers from the same transfer request side by side makes their roles clearer. All the names below are fictional values used for this example.
| Identifier and example | Role |
|---|---|
Customer IDC-A | Identifies the customer in the business application |
Business aliascustomer-a | Looks up a wallet within a chain family |
Wallet identifierW-A | Tracks the wallet's status and its link to a signing key |
| Blockchain address Address A | Identifies whose balance and transactions are involved on that network |
HSM key labelK-A | Selects a key inside the key protection device, or HSM |
The customer ID and business alias can use the same string, but they do not have to. What matters is that the business application manages the relationship between the customer who signed in and the alias to be used.
For example, the application must not trust that a request came from A merely because it contains customer-a.
The server must derive the alias from authenticated customer information or check that the requested alias
is permitted for that customer. Knowing another customer's alias must not be enough to use that customer's wallet.
The alias is used to find a wallet. The business application must separately determine who signed in and whether that person is authorized to make this transfer. Information that selects a key and the basis for permission to use it serve different purposes.
Selecting a wallet still leaves a network to choose
BXB looks up the wallet using the target network's chain family and the business alias.
The chain family is called namespace in the code. It distinguishes families such as EVM and Solana;
it does not identify a customer or department.
For example, if A's transfer targets an EVM network, BXB looks for the active wallet W-A linked to
customer-a in the EVM family. Wallet registration also rejects a duplicate when an active wallet with
the same alias already exists in that chain family. This condition makes it clear which wallet an alias selects.
After finding the wallet, BXB checks the address linked to it on that particular network. BXB manages wallet information separately from addresses on individual networks. Even within the EVM family, different networks have separate ledgers. The same address string therefore still requires a choice of which network's balance to read and where to send the transaction.
In this example, the selection does not end at “wallet W-A.” It must resolve to
executing a transaction from address A on the network where token T exists.
The token contract, recipient address B, and amount of 10 must also be specified.
Authorizing a transaction and protecting a key
Finding a wallet does not mean that this transaction has been authorized. Several distinct decisions are involved in this connection.
The business application determines whether A is the customer who signed in, whether A has permission to transfer, and whether the amount and recipient meet the business rules. Any required approvals or transaction limits are checked at this stage.
This transfer path in BXB checks whether the wallet is active and whether its business alias is blocked. The path that obtains the material needed for signing checks the alias stored in the wallet again. This control stops a new signing operation when BXB has blocked the alias, even if the business application has already authorized the request.
There are also address checks. The EVM signing and submission path checks whether the sending address or the address directly called by the transaction is blocked. For a token transfer, the directly called address is token contract T, while recipient B appears in the function's inputs. This address check therefore does not cover the customer's entire recipient and amount policy. Who may send what, to whom, and how much must be determined together with the business rules.
The key management and signing path provides a signature for a transaction that passes these checks. A signature makes it possible to verify that the transaction contents were signed with the selected key. It does not determine what the customer intended or approved on screen.
What changes when an HSM is used?
An HSM, or Hardware Security Module, is a device that protects cryptographic keys and performs cryptographic operations. Depending on its deployment configuration, BXB provides a signing path using software keys or a path using an HSM. Here, we compare their roles in this EVM transfer.
With software signing, the server's signing code uses the key material.
With an HSM, a label selects a key prepared inside the device, and the signing result from that key is returned.
The earlier K-A is the name used to find the key at this stage.
The business alias customer-a and HSM key label K-A are identifiers used at different stages.
The component handling the business request first determines the wallet and transaction contents. The signing path then signs the transaction with the selected key and assembles it into a form that can be submitted to the blockchain. This separates how the key is held from which customer wallet is selected.
An HSM protects keys, but it does not decide whether the business application has mistakenly linked another customer's wallet to A's request. The same is true if the recipient or amount has been constructed incorrectly. Key protection must accompany the responsibility to construct a properly authorized transaction.
Where does a blocked customer's request stop?
Return to A's request to send 10 tokens.
This time, suppose customer-a is already on BXB's blocklist before the request is processed.
Even if A is signed in to the business service and the application requests the transfer, BXB checks the alias's blocked status in this transfer path and rejects the request. The request does not proceed to a new signature or submission, so without other transactions, the token balances remain A 100 / B 0.
Conversely, if an active, unblocked wallet is selected and the required checks pass, the transaction can be signed with the key corresponding to address A and submitted. The intended A 90 / B 10 is reached when the transaction's successful execution is confirmed. Signing alone does not change the balances.
Blocking here is a control on new transfers. It does not cancel transactions that have already been signed or submitted. It is necessary to distinguish stopping a new use of a key from handling a transaction that is already in progress.
Connecting customer intent to a signature for a specific transaction
When customer A decides to “send 10 to B,” the business application checks that intent and A's authority. BXB connects the authorized request to a specific wallet, network, and address, and executes signing through the controls in the transfer path. The customer ID, business alias, blockchain address, and key label each have a role in this process.
Keeping these roles separate also makes the questions clearer when investigating a problem. Was the customer identified incorrectly? Was the wrong wallet selected? Was an unauthorized transaction constructed? Was the signing key inadequately protected? These can be examined separately.
Connecting a custodial wallet to a business application means managing these relationships consistently: the customer's request must select the correct wallet, and the authorized transaction contents must lead to a signature using that wallet's key.