Payment L1s

New payment focused chains have been popping up left and right for the past few years – Codex, Plasma, Stable, Tempo, Arc… And the story isn’t new; Ripple was supposed to replace SWIFT, Stellar’s been branded as the chain that “powers borderless payments”, and Concordium pivoted to becoming a PayFi-chain.

Today, we’ll take a look at four payments-focused L1 blockchains: Arc, Concordium, Plasma, and Tempo. The core question we’ll be asking is ”What makes them different from general purpose chains?”. But before we get there, let’s take a moment to think about this from first principles.

Table of Contents

What must a payments L1 look like?

First of all, a payments L1 must reliably & neutrally process transactions without rollbacks from finalised state.

• It must not be able to unilaterally roll back the chain’s state, like Flow did. That causes issues with anyone who relies on the chain as a source of truth or to execute actions beyond the blockchain’s own environment (e.g. offchain).
• It must not be biased. Deprioritising transactions related to a competitor degrades the value proposition for all parties due to the precedent set (what if I become deprioritised?). Interoperability suffers as a consequence of lack of neutrality.

Crucially, it must reach deterministic finality. As per Coste & Pantelopoulos:

settlement finality refers to the irrevocable and unconditional transfer of an asset … This concept is fundamental in ensuring the stability and reliability of payment systems.

Probabilistic finality is not finality. Without finality, there is no payment system. Therefore, all payments L1s must have a deterministic way of reaching transaction finality.

What should a payments L1 look like?

While the above conditions are met by most modern blockchains, the shoulds start becoming more opionated. Payment L1s targeting different use cases, verticals, businesses, etc. might have slightly different takes and nuances. However, I believe these features should be present in most, if not all, payment-focused L1s:

• Stable & a priori deterministic transaction costs denominated in one currency: payments use cases may be extremely reliant on stable and predictable transaction costs. If your client is building an app with micro-payments where average transaction sizes are in cents, the transaction costs for stablecoin transfers cannot be subject to high volatility. Furthermore, the transaction costs must be denominated in one currency so businesses & users do not need to hedge currency risks (or if they do, it is on very liquid pairs, not volatile shit coins) AND so that their accounting is much easier. Achieving the latter would likely also require the payment token to be regulated, e.g., as e-money.
• Selective payment privacy: payments – and transactions in general – must be able to be processed in a confidential, shielded, private execution environment. For stablecoins to be used in day-to-day and business transactions, from payroll to paying for corporate espionage services, the transaction information must stay private on an opt-in basis. Sometimes, the parties to the payment might want to publish the data so that has to be possible as well. But all core data (counterparties, amount, payment terms…) must be able to be kept private.
• Out-of-ledger calls (vertical interoperability): interoperability beyond the blockchain itself is important for the payment methods based on that blockchain to be real money – in traditional lingo this is known as interoperability among payment systems. There are three types: technical, semantic, and business interoperability. From a technical design point, these out-of-ledger calls should be able to trigger actions beyond the current execution environment through standardised interfaces. Similarly, calls in other interoperable environments should be able to trigger execution within the current execution environment. This is pretty basic but the payment L1 should make opionated decisions about those out-of-ledger environments it may trigger or get triggered by and build the relevant integrations & interoperability. Coste & Pantelopoulos (ibid.) refer to this as vertical interoperability.
  • Note: vertical interoperability can also be achieved on the application layer, as shown by Monerium which issues blockchain-linked vIBANs that automatically mint stablecoins. However, for the blockchain to truly be a layer one, the basis for all payments activity, these features should be as integrated as possible (e.g. through standardisation).

What could a payments L1 look like?

In addition to the features all payment L1s should have, there are a few properties that would make a lot of them better – features they could have:

• Interoperability between currencies (both within and across currencies): as stablecoins have not reached complete ubiquitousness yet and preferences between which stablecoin to receive vary, the blockchain should have an enshrined DEX that allows the recipient to receive a different stablecoin of the same denomination than what was sent – with very low costs. Furthermore, to boost liquidity uniformity and payment programmability, an enshrined FX DEX should most likely be part of the core protocol. Directionally, Coste & Pantelopoulos (ibid.) refer to the former as 2nd dimension horizontal interoperability (with additional qualifications for crosschain interoperability).
• Recurring payments capability: while recurring payments can be achieved by out-of-protocol mechanisms, enshrining this at the protocol level decreases reliance on third-parties and makes integration processes more uniform, decreasing costs and improving security.

What do payments L1s look like?

First, here’s an overview of the four chains we are looking at:

As we can observe, all of the EVM compatible chains have swapped Ethereum’s Gasper consensus mechanism for a faster one. It’s an “easy” swap and improves transaction latencies a lot. Concordium, the only non-EVM chain, uses its own ConcordiumBFT consensus mechanism.

Arc stands out from a design perspective in that it has replaced “economic incentives with institutional accountability” by using a Proof-of-Authority system.

While working off of EVM is great for easily and cheaply integrating existing infrastructure onto the blockchain, it is terrible for building a truly payments-focused L1 because you have to live with the compromises made in designing the general purpose Ethereum Virtual machine. Here’s where we stand from developer POV:

All, with the exception of Concordium, are sufficiently fast to be used in a physical Point-of-Sale situation. The lack of Solidity/EVM infra support can also be definitely observed in the outcomes for Concordium when compared to Plasma, the only other chain that is live. Concordium is a much more inward looking ecosystem where many of its capabilities are built-in at the protocol level, whereas those have been outsourced (integrated) in the case of Plasma. Other than block times & transaction costs – which are on Concordium’s roadmap to improve – the tech behind Concordium is superior for a payments focused chain.

Now, let’s analyse the four blockchains from the perspective of the “shoulds” and “coulds”:

Fees

As suggested during the first-principles discussion, three of the four blockchains have fixed gas fees in fiat currency terms. Tempo has by far the most advanced approach in terms of transaction fee payment system, borrowing simple transaction re-signing approach from Solana’s design playbook.

🏆 Category winner: Tempo

Privacy

🏆 Category winner: Tempo/Plasma

Vertical & Horizontal Interoperability

All blockchains have a canonical standard for stablecoin issuance which is the basis for any interoperability. Arc also integrates some of Circle’s cross-blockchain interoperability features “natively”, whereas others only get third-party integrations. All with native stablecoin issuance have some level of vertical interoperability depending on the extent of support offered by the relevant stablecoin.

Assuming Arc would have native stablecoin issuance when it goes into production, the differentiating factor here is the native 2nd dimension horizontal interoperability of Arc and Tempo through enshrined exchanges. Until then, Arc would be the category leader due to its native Circle Mint integration.

🏆 Category winner: Arc

Programmable Payments & Other Features

Only Tempo offers scheduled payments for its stablecoins which is surprising given scheduling of transactions is a very core piece of any payments system. Think your payroll, invoice payments, and more.

On the compliance side, Arc focuses more on strong low-level guarantees, Tempo on reducing overheads, and Concordium on preventing incidents via an identity-based system.

Unique to tempo, its “Payment Lanes” ensure payments processing even when rest of the execution environment is congested (due to e.g. memecoin mint).

🏆 Category winner: Tempo

Summary

Here’s how the four blockchains score against the first-principles criteria set in the beginning (in their current state, except where noted):

Looking at the summary table, it is clear that Plasma and Concordium are currently not serious contenders. However, Concordium has planned features in relation to its consensus and execution layer that would improve its core by a few points, surpassing Arc, and is therefore worth watching. Plasma, on the other hand, lacks a credible pathway to improve in many of its reds.

Arc and Tempo are the more serious contenders with the latter in a much better state due to its deeper EVM modifications and lack of clear stablecoin issuer bias. While both may be valid systems for the future of France once they go into production, Tempo is clearly a more payment-focused L1 than Arc.

All in all, with the exception of Tempo, most of the “Payments L1s” fail the first principles tests for a true Payment L1 and they are not sufficiently differentiated from other modern general purpose blockchains.