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 (Polymophic Security Token Offering), 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 blockchain 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.

This article looks back at how the Polsto experience led to BXB. It explains the signing boundary using the custodial wallet system implemented in BXB, without covering the entire product specification or validating performance and operations. The technical scope is the EVM (Ethereum Virtual Machine), the contract execution environment used by Ethereum-compatible networks, and its contract-call interface, the ABI.

The Integration Problem We Found in Polsto

Building issuance and management for tokenized securities in Polsto required more than writing smart contracts.

Consider a customer who transfers 10 tokens to another customer through an existing financial service. This is an illustrative example, not an actual customer transaction or a specification of BXB's APIs.

The customer signs in and approves the transfer. When the server accepts that request, however, the tokens have not yet moved on the ledger. The system must map business accounts to blockchain addresses, sign the transaction, submit it to a node, and check whether it took effect. One customer action spans several systems.

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.

In the transfer example, the business system defines the rules for the customer and product. BXB sits at the boundary that translates the request into a contract call and connects custodial-wallet signing with blockchain submission and result tracking.

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 (Externally Owned Account), an account controlled by a private key. 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—a business-facing wallet identifier—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.

The transfer of 10 tokens follows this path. Users do not need to handle private keys 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.

For a transfer example showing how a customer account selects a wallet and signing key, and how responsibilities are divided at each step, see How Does a Customer Account Lead to a Blockchain Signature?.

Registering an API and Executing a Request

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.

OpenAPI Specification 3 (OAS3), by contrast, describes HTTP API paths, inputs, and response formats. It is an interface contract shared by human-readable documentation and server and client tools. The OpenAPI 3.0.4 specification is a reference for this explanation, not a statement of the exact version used in the 2023 implementation.

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 is easier to understand when we separate preparing an API from calling that API.

When Registering an API

The factory reads the functions and types to expose from the ABI and maps them to OAS3 paths, inputs, and responses. The configuration must also connect each HTTP request to a particular network, contract, and function before the endpoint is registered to receive requests.

An OAS3 document alone does not choose the contract address or signing authority. The connection to the target function and execution policy requires additional information. This describes what that connection needs, not BXB's internal storage format or a deployment-specific configuration.

When Calling the Registered API

The request to transfer 10 tokens uses the connection already configured. It does not generate a new API for every request.

1. Validate the requester's permission, recipient address, and amount. The amount must be expressed in the token's smallest units.
2. Encode the target function and arguments according to the ABI.
3. For a read, obtain the result through eth_call. For a state change, construct a transaction and sign it with the custodial wallet.
4. Submit the signed transaction through eth_sendRawTransaction and track its result by transaction hash.

In the Ethereum JSON-RPC documentation, eth_call executes a call without creating an onchain transaction. eth_sendRawTransaction submits a transaction that is already signed; it differs from eth_sendTransaction, which signs and submits through a node-managed account. A read result and a submission identifier are different kinds of response.

What It Takes to Operate a Contract as a REST API follows balance queries and transfers through their HTTP inputs and outputs, including large-integer precision and the meaning of a transaction response.

Following One Transaction from Acceptance to Finality

Compare checking the balance before the transfer with actually transferring the 10 tokens.

Request	Execution	First result received by the business system
Check balance with balanceOf	eth_call	Balance at the queried state
Transfer tokens with transfer	Sign and submit a transaction	Acceptance or submission state and a tracking identifier

A queried balance describes one state. Other transactions may change it, so a successful read does not guarantee that the transfer will succeed. A transfer should be understood through successive states. The following states are illustrative; they are not BXB's actual response fields or status-code catalog.

Stage	What has been established
Accepted	The business request has been received and is being tracked. It has not necessarily been submitted.
Submitted	The signed transaction has been submitted to a node and a transaction hash returned.
Execution checked	The included transaction's receipt and contract outcome have been checked.
Final for business purposes	The network's finality conditions and the institution's transaction policy have been met.

An authorization or input error can stop the request before submission. A submitted transaction can still fail during execution, for example because of an insufficient balance. The customer-facing “10 tokens transferred” result belongs to the final stage, not merely to request acceptance or receipt of a hash.

Success must also be defined for the contract involved. The ERC-20 standard requires callers to handle a possible false return from transfer. A receipt's execution-success status is not a universal business-success criterion; return values, events, and state have their own meaning. Nor does a standard receipt simply contain the function's return value.

An HTTP API for this example could expose balance reads with GET and transfer requests with POST.

GET and POST are not rules imposed by Solidity. This distinction is 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.
• A retry of the 10-token transfer after a timeout must be able to find and continue the same business request. This requires duplicate-prevention (idempotency) and nonce policies; a nonce is the sending account's transaction sequence number.
• 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.