From Polsto to BXB: Why We Built Blockchain Middleware
In February 2023, Korea's Financial Services Commission announced its plan to revamp the regulatory framework for issuing and distributing token securities. It was the moment when the direction—recognizing distributed ledgers as a new form for issuing securities and building an institutional foundation for issuance and distribution—became a concrete policy document.
Our team responded by building a prototype of Polsto, a tokenized-securities issuance platform. Rather than leaving “tokenized securities” in a business plan, we wanted to find out what functions and connections an actual system would need.
Technology and legislation, however, do not move at the same speed. The legislative process took longer than we had initially expected. We had to reconsider whether it made sense to keep adding features to one specialized service while waiting for the market to open.
So we temporarily removed “tokenized securities” from the question.
What technology would remain without tokenized securities? Could we separate the problems that would recur in other EVM- and ABI-based integration projects into shared infrastructure?
The earlier articles, Can Rights in Tokenized Securities Be Calculated by Holding Period? and Recording Holding Periods Without a Hard Fork: A Design Review of SecurityToken.sol, examined the calculation of tokenized rights and their smart-contract implementation. This article looks back at the boundary that connects those capabilities to existing systems.
It is not a specification or roadmap for the entire BXB product. Based on our 2023 prototype experience and the public history of the design, it records how one service experience led to the next question: blockchain middleware. Because we do not provide a public implementation commit, performance tests, or operational data here, this article should not be read as proof of the product's current capabilities or verification status.
The Integration Problem We Found in Polsto
Building issuance and management for tokenized securities in Polsto required more than writing smart contracts.
Existing financial systems operate in terms of customers, accounts, products, and transactions. REST APIs and structured requests and responses are widely used to connect systems, and authentication, authorization, error handling, logging, and monitoring are organized around those boundaries.
Blockchains speak a different language. A smart contract's functions and data types are described by its ABI (Application Binary Interface), while applications communicate with nodes through JSON-RPC. Reading state and executing a state-changing transaction follow different paths. A transaction must be signed, and its submission may return only a transaction hash rather than the final outcome.
The difference between the two worlds can be summarized as follows.
| Boundary | Existing business system | Blockchain execution environment |
|---|---|---|
| Interface | REST API, OpenAPI specification | ABI, JSON-RPC |
| Actor identification and transaction approval | Customer and account, authenticated session and approval policy | Address, key, and digital signature |
| Execution result | Synchronous HTTP response and business error | Immediate read result or transaction hash and receipt |
| Operational unit | Request ID, application log | Block, transaction, event |
| Change management | API version and deployment | Contract address, ABI, and network state |
We could write code in the prototype to bridge these differences. The problem was that the next project would have to write the same integration code again.
An address alone does not prove a customer's identity. In a real financial service, the relationship between a business account and a blockchain address—and the authority to approve transactions from that address—must be managed through a separate account and permission system.
Even in an EVM- and ABI-based digital-asset service unrelated to tokenized securities, the same tasks recur: interpret the ABI, turn a business request into a transaction, connect signing and submission, and track an asynchronous result. The specific business changes, but the translation between an existing system and a ledger does not go away.
Turning the Boundary into a Product
Bankware Global's R&D Center had deeper experience in infrastructure that connects and operates multiple systems than in any one financial product. We therefore changed the question from “What tokenized-securities feature should we add next?” to “What common ground recurs when an EVM- and ABI-based service is connected to an existing system?”
The product that grew from this perspective is BXB (BX-Blockstream), our blockchain middleware.
BXB does not replace a blockchain ledger. Nor is it a business system that decides the issuance and distribution policies for tokenized securities. Its role is to bridge the different interfaces, execution models, and operational lifecycles between existing applications and blockchain networks.
[Customer and Existing Business Systems]
| Authenticated and authorized REST request
v
[BXB]
API Service Factory
-> Transaction Converter
-> Custodial Wallet System (authorization and signing)
-> Blockchain Connector (submission and result tracking)
|
v
[Smart Contracts and Blockchain Network]
Business applications can focus on the rules for customers and products, while the middleware handles interface translation and the common execution path that would otherwise be rebuilt for every EVM- and ABI-based project. This was more than reusing integration code from Polsto in another service. It redefined integration itself as a product problem.
What It Takes for a REST API to Become a Transaction
For a state read, translating between an ABI and a REST API may appear to complete the integration. A request that changes ledger state, however, must ultimately be signed when it is executed from an EOA. There is another boundary between the server that constructs the transaction and the key that authorizes it.
Consider a non-custodial wallet managed directly by the user. An API server can construct the contract address and call
data needed for transfer, but it cannot sign on the user's behalf with the user's private key. It must send a signing
request to a browser or mobile wallet and receive the user's approved result. This does not make the REST API useless,
but a single server-side REST request does not complete the path through transaction submission.
It would be inaccurate to treat an EOA and a custodial wallet as opposites. An Ethereum EOA is an account controlled by whoever holds its private key. If the customer holds that key directly, the wallet is non-custodial. If an institution manages it under a customer agreement and defined controls, the same EOA can be an account within a custodial wallet system. The distinction is less about the account type than about who manages the key and what policy authorizes a signature.
Here, custodial describes a technical operating model in which an institution manages keys and executes signatures under controlled policy. It does not by itself determine whether the institution is legally engaged in a custody business; that status depends on the applicable law and the service's actual structure.
This distinction matters when an institution gives customers wallet accounts within its own service and processes
blockchain transactions through its existing authentication and authorization procedures. The institution must map a
business account and wallet alias to a blockchain address, verify the requester's permissions and the transaction
policy, and sign within a controlled signing boundary. It can then submit the signed result to the node through
eth_sendRawTransaction and track subsequent state by transaction hash.
In this model, users do not need to handle private keys, ABI encoding, nonces, or blockchain signature formats directly. They authenticate and approve a transaction through the institution's existing service, and the custodial wallet system executes that approval as a blockchain signature. The signature does not disappear; it moves into a controlled execution step inside the institution's system.
BXB implements this signing boundary with a custodial wallet system. It allows an endpoint produced by API Service Factory to become more than API documentation or an unsigned-transaction generator: it can form an execution path from institutional authorization through signing, submission, and result tracking. An institution that assumes responsibility for the lifecycle of a server-side REST API needs a controlled signing system. Custody is one way to implement that system, and it is the approach BXB takes.
Of course, users not having to understand blockchain signatures does not mean that user consent or transaction approval can be omitted. Customer authentication, transaction limits, multi-step approvals, and audit trails remain part of the institution's business policy. A custodial wallet must connect that policy safely to private-key use and onchain transactions.
From API Documentation to an Execution Path
The core capability we envisioned at this boundary is API Service Factory.
A Solidity contract's
ABI JSON describes function names, input and output types, and
stateMutability. Functions marked pure or view do not modify state, while nonpayable and payable functions can
be entry points for state-changing transactions. This field alone, however, does not determine every execution policy
for a business API. A state-changing function can also be executed through eth_call for a preflight simulation.
The OpenAPI Specification, by contrast, describes HTTP API paths, operations, parameters, request bodies, and response schemas in a language-independent format. Beyond human-readable documentation, it can serve as a shared contract through which server and client tools understand an interface.
The two type systems do not map one-to-one. A uint256 can exceed the integer range that some JSON clients can
represent precisely, while bytes, arrays, and tuples require their own schemas and serialization rules. A
syntactically valid OAS3 document does not guarantee a safe API at runtime unless it also validates address formats
and numeric ranges.
API Service Factory builds an executable bridge between these two formats.
Smart Contract ABI
|
| Analyze function names, inputs, outputs, types, and state mutability
v
OAS3 API Specification
|
| Define paths, HTTP methods, parameters, and responses
v
REST API Endpoint
|
| Identify contract and function; map parameters and ABI-encode the call
v
Read: eth_call ───────────────────────> Immediate response
State change: construct transaction
-> Sign with Custodial Wallet
-> eth_sendRawTransaction
-> Track transaction hash and final result
First, the ABI is parsed to identify externally exposed functions and their types. Those definitions are then mapped to OAS3 paths and schemas. An API server reading the OAS3 document can construct the HTTP handlers that receive requests.
When a request arrives, its path and parameters identify the target contract and function. The function selector and
arguments are encoded according to ABI rules, then converted—according to the execution policy—into either a read-only
call or a transaction that requires signing. As the
Ethereum JSON-RPC documentation distinguishes, eth_call
returns a call result without creating a transaction. eth_sendTransaction signs and submits a transaction through
an account managed by the node, while eth_sendRawTransaction submits a raw transaction already signed at an external
wallet or HSM/KMS boundary. Submission returns a transaction hash.
Finally, a read result is mapped directly to the REST response body. For a state-changing request, the API first returns the acceptance result and transaction hash, then tracks the transaction's later outcome. At this point, API generation has gone beyond producing documentation: it has created an execution lifecycle.
The Same ERC-20, Two Different Lifecycles
The difference is visible even in a comparison of ERC-20's balanceOf and transfer.
| Function | Contract behavior | Example API exposure | Blockchain execution | Response lifecycle |
|---|---|---|---|---|
balanceOf(address) | Non-state-changing view | GET with a query parameter | eth_call | Return the balance immediately in the response body |
transfer(address,uint256) | Changes balances | POST with a request body | External signature followed by eth_sendRawTransaction | Transaction hash on acceptance, then success or failure tracking |
For a balanceOf request, the address to query arrives as an API parameter and is encoded as an ABI address. The
returned uint256 is then represented according to the API response schema.
A transfer request contains the recipient address and amount. The middleware assembles the target contract address,
the transfer function selector, and the encoded arguments, then hands the transaction to the configured signing and
submission path described above. The HTTP request may end quickly, but the blockchain transaction lifecycle continues
afterward.
GET and POST are not rules imposed by Solidity. The table shows one mapping policy that makes reads and state changes clear to existing API consumers. In a real system, the HTTP method and the placement of values in query parameters, path variables, or a request body must be configurable for business requirements. Automatic conversion does not eliminate policy. It creates a default structure and a starting point for applying policy consistently.
Operations Are Harder Than Automatic Generation
Converting an ABI to OAS3 and creating an API endpoint does not complete a blockchain integration. Even with BXB's custodial wallet system implementing the signing boundary, its responsibilities on either side must be explicit before it can operate in an institutional environment.
- The institution's authentication and authorization policies must determine which wallet and permissions a business user can access.
- The relationships among a wallet alias, its actual address, and its keys must be protected, with role separation, auditing, and recovery procedures.
- Each deployment must define how keys integrate with protection systems such as an HSM or KMS.
- Idempotency and nonce policies must prevent a retry after a timeout from creating the same transaction twice.
- The system must distinguish the creation of a transaction hash from inclusion in a block. Network finality and possible reorganizations are technical constraints; business policy must define when the transaction is treated as final.
- Changes to a contract address or ABI must be managed for compatibility with existing APIs.
- HTTP errors, RPC errors, reverts, and network failures must be normalized into forms that business systems can handle.
- Logs and monitoring must trace API calls, blockchain transactions, and events as one flow.
The value of middleware is not that it makes these responsibilities invisible. It brings responsibilities that each application would otherwise implement independently into one boundary, where they can be operated under consistent policies and observability.
Nor does every responsibility move into the middleware. Network finality and reorganization behavior are technical constraints that the middleware must account for. The point at which a network state is accepted as final for business purposes—along with who may transfer which assets and what customer verification and approval procedures apply—is a matter of business and regulatory policy. API Service Factory does not make those decisions. It exposes the network state and connects the established policy consistently to blockchain execution.
A Broader Problem Revealed by Waiting
The legislative delay in 2023 did not make the Polsto work irrelevant. Instead, it revealed which problems remained even after the market label was removed.
We separated the capabilities specific to a tokenized-securities service from the integration capabilities shared by many EVM- and ABI-based services. The former change with the market and the business; the latter recur across industries. BXB is the result of regrouping those recurring concerns as an infrastructure product.
Part of the technical structure developed along the way was also formalized in 2025 as Korean Patent Registration No. 10-2887854, “System and Method for Providing APIs Through Smart Contract Format Conversion,” registered in the name of Bankware Global. The registration is included here to document the public history of the design, not as a badge meant to prove product performance.
The regulatory landscape has changed since then. Amendments to Korea's Act on Electronic Registration of Stocks and Bonds and Financial Investment Services and Capital Markets Act for introducing token securities passed the National Assembly in January 2026 and were subsequently promulgated. The amended Electronic Securities Act is scheduled to take effect on February 4, 2027. The Financial Services Commission is preparing detailed rules for technology and infrastructure, issuance, and distribution in line with that date.
The legislative clock is moving again, but our conclusion about infrastructure has not changed. As the market for tokenized securities opens, connecting existing financial systems, account management, signing, ledgers, and operations will matter as much as issuance itself.
The Business Changes; Integration Repeats
Polsto began as an attempt to build a tokenized-securities platform. Its implementation revealed a question that would recur across markets, rather than an answer for only one market.
Existing systems want to retain familiar APIs and business concepts. The EVM execution environments discussed here have their own model: ABIs, transactions, signatures, and asynchronous finality. Merely making one world look like the other is not enough. We need a boundary that understands the difference without letting it leak repeatedly into every application.
That is why we built BXB. Instead of building another specialized EVM-based service, we chose to build an integration foundation that multiple EVM- and ABI-based services could share. API Service Factory is one pillar of that foundation, turning a smart-contract interface into an API and execution path that existing systems can use.
The business changes from one market to another. Integration repeats.
The move from Polsto to BXB was less a change of product names than the process of recognizing that repetition and redrawing the boundary of the problem.
This article is a retrospective on the technical background of blockchain middleware. It is neither legal advice on issuing tokenized securities nor an investment solicitation. Any real system requires separate review of applicable law, security, key management, disaster recovery, and operational policy.