Decisions and lessons from building BXB blockchain middleware
Use a lost transaction submission response to compare BXB's node selection and recovery with the mirror's HTTP retries, and distinguish restoring a connection from confirming a transaction's outcome.
Follow a transfer of 10 tokens to understand HSM key labels and handles, signing digests, Ethereum signature conversion, chain-specific inputs, and connection failures.
Follow a Token-2022 token whose balance can be read but whose transfers are unavailable to see how extension parsing and BXB's command support decisions shape its APIs and signing path.
Follow a program file uploaded to a buffer in chunks to see how BXB handles byte verification, upgrade authority, and cleanup after a failed Solana deployment.
A two-step example that passes a token contract's address to a vault constructor shows how BXB's templates, deployment plans, and execution records handle dependencies and partial failures.
Follow independent transfers of 10 asset units on four chains to examine the business requests BXB handles in common and the transaction structure, costs, and support boundaries that must remain specific to each chain.
Follow a transfer of 10 tokens as its event becomes a database row, exploring log decoding, amount units, collection progress, and the limits imposed by chain reorganizations.
Follow a transfer of 10 tokens whose response was lost to distinguish querying its status, rebroadcasting the same signed transaction, and creating a new transfer, and examine the boundary between BXB's result tracking and business-level duplicate prevention.
Follow the sessions, participants, key versions, and HPKE protection of joint signing messages to understand where an MPC relay server's authority ends and wallet signing authority begins.
Replacing one participant in a 2-of-3 wallet explains how key shares can be redistributed without reconstructing the private key, why the public key stays the same, and where BXB's recovery and storage updates fit into the process.