Project Opera: Blockchain Interoperability From Chicago to Singapore

Exploring Northern Trust and Singapore's NUS Blockchain Interoperability Proposal: Ambitious Ideas with Unclear Practicality, Unfortunately.

This is a first for me—I haven’t yet written about anything produced by my favourite bank from Chicago: yes, Northern Trust, the bank with a logo that looks a bit like Starbucks. It’s a shame because they’ve been quite engaged in digital initiatives. This is thus an excellent opportunity to review their recent publication, which promises to:

"Explore the challenges, best practices, technical considerations, and standards in building blockchain interoperability solutions for secondary trading of tokenized real-world assets."

And it’s co-authored with the National University of Singapore (NUS). Who are they? I’m told this university enjoys a stellar reputation both regionally and globally, often regarded as Asia's equivalent to top Western universities like Harvard, MIT, or Oxford. Not bad, Northern.

But the title—Northern Trust, what were you thinking? Towards a Secured and Unified Future in the Financial Industry. Secured? As in no more worries about hitting financial targets? Secure, maybe—safe would make more sense. But unified? When the report is about decentralization and distribution? This reads more like a slogan from one of those five-year economic plans in the Soviet Union. A very peculiar title, I must say.

I also don’t really understand what Northern Trust has to do with this topic other than being an interested party—or how this would be meaningful for their clients. Obviously, they would know better than me. The report comes across as a rather theoretical document, offering speculative assessments rather than drawing from practical experience.

But let’s see. The report starts off with a technical overview that has a few minor inaccuracies, sometimes reads a bit funny, but otherwise aims to provide a framework of considerations for building connectivity between chains.

"To ensure the credibility of participants such as users and traders in the system, a governance model must be established."

Credibility? Do they mean identity?

"One of the key unique selling points of a blockchain system is that once source code is deployed and data is stored, it cannot be altered easily."

Not sure what they’re referring to here—smart contract code being static or the “immutability” of data stored? The source code of a blockchain can, of course, be changed, and I’m not sure anybody would think it’s beneficial for software to be unchangeable when updates are needed.

The report then stresses the importance of adherence to relevant laws and regulations, followed by profound insights like:

"This builds trust among users and upholds the integrity of the trading system."

Okay. How exactly does a blockchain ensure the integrity of a trading system, which I assume is separate? And what defines a trading system with integrity? Not sure.

There are a couple more moments like this, but let’s move on. They identify three existing cross-authentication-based interoperability approaches: atomic swap, notary scheme, and cross-chain bridge, and aim to evaluate their pros and cons.

The section on atomic swaps has some nuances I would question. They refer to mechanisms like hashed time lock contracts (HTLCs). To me, an atomic settlement refers to multiple transactions included in the same block and processed simultaneously, ensuring either all transactions occur together or none do. This is inherently limited to a single blockchain. Atomic swaps using HTLCs involve a sequence of actions across different blockchains. While they aim for atomicity (all-or-nothing execution), the steps are not truly simultaneous. Each action must be confirmed on its respective blockchain, creating inherent time delays due to differences in block times and confirmation speeds.

The report also states:

"It only supports blockchains that are compatible: they must use the same hashing algorithm for atomic swaps to work."

Must? Not exactly. It is generally preferred and more practical for the blockchains involved to use the same hashing algorithm. Statements like this make the discussion overly generic, failing to highlight the deeper implications of the technical design.

The next section surveys cross-chain bridges relevant to their project’s scope of trading tokenized assets across chains, focusing on Axelar Network, LayerZero, and Chainlink CCIP (Cross-Chain Interoperability Protocol). They note that other protocols like Wormhole, Circle CCTP, and zkBridge are more tailored to cryptocurrency use cases and were excluded.

However, the selected protocols primarily deal with cryptocurrency and DeFi assets, such as ETH, BTC, and USDC, rather than tokenized real-world assets. So the selection criteria they chose probably put too much faith in the marketing material of those providers. Axelar says that it “has transferred over +$6 billion in value cross-chain via a secure, programmable network” since 2022. It’s still niche, I would say.

They categorize Axelar, LayerZero, and Chainlink as cross-chain bridges, but that’s debatable. Chainlink is better described as a notary scheme or hybrid solution, relying on decentralized oracle networks (DONs) for secure cross-chain communication rather than a traditional bridge-like infrastructure. Axelar and LayerZero, in contrast, are true cross-chain bridges, directly handling asset transfers and messaging without relying on notary-like mechanisms.

Evaluation Criteria: Missed Opportunities

The report then evaluates the protocols’ interoperability potential, but the criteria and scrutiny applied are overly simplistic.

For instance, the report begins by comparing the number of supported chains, which is not the most relevant metric. The number of chains doesn’t directly correlate with functionality or suitability for tokenized asset trading. Metrics like the security model, architecture, supported use cases, and quality of integration should take precedence.

Their security analysis of Axelar is particularly underwhelming:

"The security of Axelar Network on public blockchains is guaranteed by the consensus of the 75 validator nodes."

This is the entirety of their security assessment, plus a note that not all validators are active for all chains. That’s it.

Really!

Axelar’s reliance on an intermediate blockchain introduces scalability and trust concerns. All transactions pass through Axelar’s blockchain, meaning its throughput and consensus mechanism limit scalability. Additionally, the intermediate blockchain creates a single point of failure—if Axelar’s network is compromised, cross-chain operations halt. Validators are incentivized through transaction fees and staking mechanisms, but as tokenized asset values grow, this model raises serious questions. For example, Axelar’s native token has a market cap of $800 million USD—hardly sufficient to secure transactions at the scale of JPMorgan’s operations (since they supported JP Morgan as part of project Guardian). These are simply some examples and I am not trying to say one solution here is better than the other. Impossible to say without specific requirements.

The report’s assessment of LayerZero is even thinner:

"LayerZero V2. The integration and blockchain support are the best."

This vague statement doesn’t address critical aspects of LayerZero’s architecture, such as its reliance on decentralized verifier networks (DVNs) and their implications for security and scalability.

Closing Thoughts

Reading the rest of the report, the conclusion feels a bit random. What are they actually trying to say? Their key recommendation—to use multiple solutions to spread risk—is questionable because the identified risks, such as smart contract vulnerabilities or deployment errors, are not protocol-agnostic. In fact, spreading across unsuitable solutions could increase risks rather than mitigate them.

The report then describes a prototype system to demonstrate cross-chain trading of tokenized assets and evaluates the performance of existing bridges. However, the reference section reveals the sources used were

• vendor websites and simply noted as https://wormhole.com or https://www.zkbridge.com

• Investopedia, and

• two academic papers authored by someone who is a Research Assistant at NUS (of course) and a PhD candidate specializing in blockchain interoperability.

This strongly suggests the report is not positioned as an academic paper but rather a summary aimed at a broader audience. NUS being the Harvard of Singapore, this is really cheap—like serving kopi from a hawker stall at Marina Bay Sands.

For anyone interested in tokenized assets, the takeaways are unclear. They suggest interoperability is important for trading, but it’s not evident why that is so or how such trading would be structured. The crypto trading landscape differs dramatically from traditional securities markets, where custodians often operate what could be described as prime brokerage services to address challenges like cold storage and position mobilization. Will tokenized securities markets face similar issues? There are various models to trade securities—from notice boards to open order books. Will tokenized instruments adapt existing methods or require dedicated trading platforms?

While it’s reassuring to know that interoperability solutions exist, the report doesn’t seem to offer a clear punchline. It feels like the takeaway is: If you need interoperability, you can have it since NUS built some prototype of sorts.

But don’t get me wrong—the overall idea of exploring these technical models is superb. Discussions around the future market model need to take place at this kind of technical level. However, this report would benefit greatly from better articulation of the business implications of these technologies. As it stands, it reads more like a generic summary of technical models without offering substantial insights or actionable takeaways for stakeholders interested in tokenized assets.

PS: The university calls the collaboration with Northern Trust ‘Project Opera.’ I think they’ve been watching too many movies—or the wrong kind—to think this needs a project code. No need for all the drama lah.