A bank spots a problem with a token it has issued and submits an instruction to pause transfers. Before that instruction takes effect, someone sees it waiting to be processed and moves their holdings. The bank can intervene. The network determines whether it acts in time.
That gap sits at the centre of the debate over public blockchains for banks. An issuer gains programmable controls without necessarily controlling the infrastructure executing them.
BFRR guests Wee Kee Toh of Kinexys by J.P. Morgan and Michael Maurer of MIT’s Digital Currency Initiative examine this tension in their joint research. They identify four problems that remain difficult for regulated institutions: front-running, transaction censorship, unsolicited tokens and gas fees potentially reaching sanctioned entities.
Public blockchains for banks expose a control gap
Open networks promise shared access to assets, payments and applications. Banks gain common infrastructure but must meet institutional obligations without fully controlling its operators or governance.
Large institutions can fund extensive safeguards. Smaller banks face a different calculation. If participation requires expensive bespoke controls, the benefits of shared infrastructure become harder to access.
The research separates potential responses across applications, smart contracts, token standards, networks, governance and regulation. The layers banks can most easily change may not contain the source of the risk.
When a freeze becomes a trading signal
Front-running is often discussed as a way to profit from another trader’s order. A pending bank instruction can also reveal an opportunity. A holder who sees an approaching pause may attempt to transfer or redeem tokens before restrictions take effect.
Encrypted mempools aim to conceal transaction contents until ordering has been determined. A heartbeat-based pause mechanism would require regular operator confirmations that processing should continue. If those confirmations stop arriving, activity pauses automatically.
Neither approach removes every difficulty. Encryption cannot eliminate information obtained elsewhere. Heartbeats create costs and leave intervals during which transactions may still proceed.
An instruction can also be valid yet fail to reach the ledger promptly. Private arrangements with block builders may improve processing reliability, while inclusion-list proposals seek to strengthen censorship resistance. Inclusion and ordering remain distinct requirements.
The operational cost of unwanted tokens
On an open network, an institution’s address can receive tokens it never requested. Many users treat such assets as spam. Toh describes a more demanding institutional response, involving monitoring and decisions about how to handle unexpected receipts.
Returning a token requires care. A function labelled “transfer” belongs to the token’s smart contract; its name does not guarantee benign behaviour. Before interacting with unfamiliar code, a bank may need to understand what that code will execute.
Monitoring can also extend beyond the network a bank uses. The same address may be valid across multiple EVM-compatible chains, creating questions about assets received elsewhere. The business case for public blockchains for banks must account for an overlooked expense: strangers can create operational work.
A fee recipient the bank cannot choose
Gas fees raise a further concern. An institution may know its customer and counterparty yet lack certainty about the entities receiving fees for processing its transaction. Potential sanctions exposure therefore extends beyond customer screening.
Checking a block’s designated fee-recipient address offers a limited mitigation. Addresses can change, and identifying an address does not necessarily establish who controls it. Relationships with known builders may narrow uncertainty without resolving every downstream interaction.
The guests seek clearer regulatory expectations around reasonable precautions. They propose safe-harbour provisions for institutions that take those precautions but retain unavoidable sanctions exposure.
What would affordable participation require?
Permissioned public networks and layer-two designs offer different combinations of access, control and responsibility. A more identifiable operator may make some risks easier to manage. It also introduces dependencies and changes the distribution of power within the system.
Making public blockchains for banks viable requires costs to be considered alongside technical safeguards. Toh compares the process with banking’s adoption of cloud services, where early institutional use helped providers develop more reusable answers to compliance requirements.
The researchers want institutions to agree on essential requirements. They must establish which safeguards banks can share, who will operate them and what participation can reasonably cost.
Wee Kee and Michael Maurer on the infrastructure deficiencies of permissionless public blockchains for TradFi usage
Wee Kee Toh LinkedIn
Michael Maurer LinkedIn