Skip to content
AnalysisKinexys by J.P. Morgan and MIT Digital Currency Initiative

What Kinexys and MIT DCI's public blockchains paper is actually asking for


Key points

  • Kinexys by J.P. Morgan and MIT DCI's third co-published paper reframes MEV and front-running as an enforcement-reliability problem for financial institutions, not a trading-fairness one, and names live Ethereum improvement proposals (EIP-7805/FOCIL, EIP-7732/ePBS) as the load-bearing fixes.
  • The paper's own run scenario, holders bidding gas fees up exactly when an issuer needs a pause transaction included, sits in direct tension with the pause and freeze powers that stablecoin regimes across Hong Kong, the EU, and the US assume work on demand.
  • Several of the paper's own mitigations (private order flow, validator onboarding rules, TEE-dependent encrypted mempools) push toward the same permissioned properties public chains exist to avoid, a tension the paper flags without resolving.
  • A bank that already runs JPMD on Base co-publishing with an academic partner reads as institutional requirements-routing conducted in public, not conventional thought leadership, though several of its regulatory asks would also lower the publishing bank's own compliance costs.

Kinexys, the J.P. Morgan blockchain unit, and the MIT Digital Currency Initiative have published the third instalment in a co-authored series, this one working through four unresolved problems financial institutions hit when using public blockchains: front-running, transaction censorship, receipt of unsolicited tokens, and gas fees ending up in the hands of sanctioned entities. The paper's own framing is that these are not exotic edge cases but structural mismatches between how regulated institutions expect to control their technology stack and how a decentralised network is designed to work.

The paper's central claim, stated in its executive summary, is that "solutions that are most accessible to FIs, such as those at the application and smart contract layers, primarily mitigate symptoms rather than solve the root causes." Durable fixes, it argues, sit at the protocol and network-governance layers, where a financial institution has no direct control and has to lobby rather than build.

What this document structurally is. A bank that already issues a deposit token, JPMD, on a public Ethereum L2 through its own Kinexys platform is co-publishing, with an academic partner, a document that names specific live Ethereum improvement proposals (EIP-7805, the Fork-choice-enforced Inclusion List design known as FOCIL, and EIP-7732, enshrined Proposer-Builder Separation) and states plainly what financial institutions need from each. The likelier read is that this is institutional requirements-routing conducted in the open, addressed as much to Ethereum's protocol developers as to fellow banks, and a signal of Kinexys's own operational stake in how the base layer evolves. MIT's co-authorship does real credibility work in both directions here: it lends the paper a neutrality a single-bank white paper would lack, and it also softens the fact that several of the regulatory asks, a market-manipulation designation for front-running, a safe harbor for sanctions exposure that survives reasonable effort, would directly lower Kinexys's own compliance costs as an issuer. Both readings belong alongside each other rather than one replacing the other.

The compliance reframing of front-running. MEV discourse has mostly been about trading fairness between arbitrageurs. This paper reframes it as an enforcement-reliability problem: a transaction adding an address to a deny-list is visible in the mempool before it lands, which invites the target to move funds first. The paper's own footnote goes further than most front-running literature bothers to: a profit-maximising block builder would legally execute the target's escape transaction ahead of the institution's freeze even without being outbid, because ordering purely by profitability favours whichever transaction the builder happens to see first. Read straight, this says issuer controls that depend on winning a race are structurally unreliable on public Ethereum as it exists today. The operator implication is that fail-secure design, the paper's heart-beat and dead-man's-switch pattern for pausing a contract when an institution goes silent, and private order flow relationships with builders start to look like compliance architecture rather than a nice-to-have for execution quality.

The pause-versus-gas-market collision. The paper's own run scenario is its strongest and most underplayed section: a wave of holders trying to exit a token bids gas fees up at precisely the moment an issuer needs its global pause transaction included, and the paper acknowledges the economics of that moment could keep the pause from landing in time. That collision cuts directly against an assumption baked into how settlement finality is expected to work once a stablecoin regime is written down: that an issuer's freeze or pause reaches finality on demand, not on however congested the network happens to be that hour. Hong Kong's Stablecoins Ordinance, MiCA's EMT (e-money token) chapter, and the GENIUS-era US framework all lean on exactly that assumption as a supervisory backstop. This is the paper's strongest wedge into Asia's own live deployments: HSBC's HKD stablecoin licence (awarded 10 April 2026, signalled for an H2 2026 launch), JPYC's live yen stablecoin, and XSGD's role settling StraitsX's merchant-payment rails are all regimes or products where a working pause function is treated as a given. Progmat's own migration off Corda onto a dedicated Avalanche L1, completed 13 July 2026, is a useful test case in the other direction: a permissioned chain sidesteps the gas-market problem entirely, which is itself a data point on how much institutional appetite there is for accepting exactly this kind of public-chain physics. Whether regulators requiring pause functions have actually priced in gas-market behaviour under stress is a fair question to put to them, not a verdict this paper or this review can settle.

The centralisation undertow. Several of the paper's own proposed mitigations pull toward the properties public chains exist to avoid. Private order flow already accounts for 30 to 40% of Ethereum transactions by the paper's own citation. A single builder, Titan Builder, built 45% of MEV-Boost blocks in January 2026. Validator-onboarding rules and TEE-dependent encrypted mempools both trade decentralisation for institutional comfort. The paper flags this tension explicitly but does not resolve whether the resulting institution-friendly endpoint is still meaningfully a public chain. Its Layer 2 chapter concedes something similar in quieter language: an L2 with a known operator gives a financial institution legal and commercial arrangements the paper describes as comparable to those it already has with traditional infrastructure providers, which on this reading is the traditional intermediary stack rebuilt one layer up, with residual L1 risk retained underneath it rather than removed.

What an operator should reconsider. Compliance, legal & risk should treat mempool exposure of administrative transactions, deny-list updates, pauses, freezes, as a live audit item for any issuance already running or being scoped on a public chain, not a theoretical risk to revisit later. Infrastructure & platform teams should read FOCIL and ePBS progress as institutionally load-bearing roadmap items worth tracking directly rather than protocol arcana to leave to the validator-ops team. Regulatory & policy affairs desks should expect the safe-harbor and market-manipulation asks in this paper to resurface in stablecoin consultation responses across jurisdictions over the next year, and are better served forming a position on both questions now than reacting to whichever framing lands first.