How Layer1 powers stablecoin payments at scale (Part 1)

In this post, I’ll show how we’ve built Layer1 to drive new value for fintechs and payment companies, through features like automated consolidation with dustless sweeping, automated gas and fee management for all blockchain networks and dynamic onchain transaction monitoring.

These are all upgrades BVNK has made to our own infrastructure in the last 5 years to solve the problems we ran into as we scaled. These optimizations have enabled us to grow to processing more than $8bn in annualized volume.

And they’re why I’m convinced that Layer1 is the best stablecoin infrastructure solution for payment use cases – and payment operators – today.

In Part 1, I'm going to cover three important upgrades that are part of Layer1’s Digital asset payment engine:

• Custodial accounting
• Automated consolidation
• Onchain monitoring

Custodial accounting

The problem:

Making a transaction on the blockchain comes with a network fee known as a ‘gas fee’ which providers pay in the form of the native network token. If you’re processing stablecoin payments at scale, you’ll want to reduce those fees whenever possible.

‍

How the market solves it:

One of the best ways to reduce gas fees is to avoid blockchain settlement using omnibus accounting, i.e. segregating customer funds at books and records level, not at the blockchain level. This logic has been implemented by all major digital asset players (exchanges, custodians, brokers, PSPs, banks) that are processing digital assets at scale.

For example:

• Your customer requests to withdraw stablecoins from their wallet held with you
• They supply a destination wallet address which is also managed by you
• You update the balances off-chain in your own ledger, avoiding blockchain settlement fees.

But at scale, this creates a challenge. How do you map customer deposits from external wallets to the right customer, and credit their balance in your off-chain ledger?

Different wallet infrastructure solutions approach this differently: Deposit wallets, omnibus wallets, payout wallets, accounts, multi-ledger accounts, virtual accounts, vault accounts.

Things can get complicated pretty quickly – and require multiple logical layers which often reduce platform performance and scalability. For us, this didn’t work.

‍

How Layer1 solves it:

We went back to the whiteboard and asked:

• How would we design wallet infrastructure in 2024?
• How can we abstract the complexity of blockchain and wallet management in a platform optimized for payments at scale?
• Do we really need to manage our payments on a wallet level, limiting our opportunities to automate and scale?

Layer1 is built on the notion of ‘asset pools’. This is a fully flexible logic to group operational or customer addresses within a given asset pool.

Some customers might use a single asset pool to get the maximum out of Layer1’s default automation, others might prefer dedicated asset pools to segregate funds between operational and customer funds, asset pools for different regions, customer types, jurisdictions, etc. So, the Layer1 architecture allows our customers to be fully compliant with regulatory requirements, like safeguarding in the European MiCA framework.

Let’s take an example: adding a new customer with support of USDC, USDT and FDUSD for Ethereum, Polygon and Tron.

Before we built Layer1: We created 3 wallets for each asset, then 3 addresses in each of those wallets, resulting in 12 new entities. Each of those needed configurations that varied between networks.

With Layer1: We now create 3 addresses. That’s it. Choose the network, attach your customer ID, create the address.

‍

Automated consolidation

The problem:

Setting up the proper accounting logic for your use case is obviously not enough:

• What happens once a customer makes a pay-in?
• How can you pool incoming deposits for different customers, assets, amounts and networks in the most efficient manner to avoid scattered liquidity?
• How can you maximize outbound asset liquidity to guarantee your payment SLAs even in peak or off-cycle market dynamics?
• How do you sweep efficiently from deposit wallets to payout wallets without leaving dust?
• How do you make sure each of those processes is properly funded with the native coin (aka “Gas”) to pay for the on-chain transaction fees across networks with just the right amount?

Let’s take an example.

Your customer deposits USDT to a unique deposit address via Tron. Your customer’s USDT balance is updated on your wallet but the TRX balance is zero. Meaning you can’t sweep funds to a pooled account because there is no native token balance to cover the gas fee.

‍

How the market solves it:

Some wallet solutions have tackled this on the Ethereum Virtual Machine (EVM; Ethereum + Layer 2 networks) with the concept of “Gas Stations”  – operational blockchain accounts which hold the cryptocurrency of each supported network to cover fees.

In the example of the customer deposit before, this enables you to make a small funding transaction of ETH to the deposit address from the Gas Station address, then another transaction to sweep the funds to the pooled address, still leaving dust as these  transactions are sequential. If this is multiplied over thousands of similar transactions it leads to inaccessible liquidity.

While the funding transaction settles on the blockchain (especially with high network congestion), the fees might increase on-chain which could result in the lack of sufficient fees to pay for the sweeping transaction.

Those gas stations typically work with buffers and thresholds to make sure the sweeping transaction doesn’t fail without too much dust.

But wait, what about the example with Tron?

With first generation wallet solutions, you’ll need to replicate this same logic yourself without further tooling. The same applies for other networks, whether that’s funding the sweeping of token (eg USDC/USDT) or crypto deposits (eg TRX, BTC).

‍

How Layer1’s solves it:

Layer1 enables automatic consolidation in every asset pool, without additional configuration.

As soon as native cryptocurrency is deposited to an address in an asset pool, Layer1 automatically creates a master pool address and initiates consolidation transactions. Now you’re ready to receive and internally sweep crypto assets at scale.

Layer1 applies the basic principle of a gas station with advanced fee estimation capabilities to determine just the right amount of funding for any given transaction.

This fully automated process enables dustless sweeping and gas management across all supported networks (EVM, BTC & other UTXO networks, XRP, SOL, TRX and growing) and tokens.

Every new address created in a Layer1 asset pool is automatically included, while this feature can be disabled for each asset pool individually to allow for maximum flexibility.

‍

Onchain monitoring

The problem:

To maintain high service levels, you need to maximize liquidity and throughput in your outbound payment wallets. But sometimes market forces cause a sudden spike in blockchain traffic and gas fees.

I’ve seen instances where fees double from the moment you send a transaction request to the moment the transaction hits the blockchain – leaving you with insufficient fees to compete for the next block.

I’ve seen many cases where the majority of working capital (crypto liquidity) was locked up, because the wallet infrastructure would still reserve the balance of the pending transaction to avoid double-spending (see my last blog on reserve management in custody solutions).

Most self-custody stablecoin solutions follow a “fire and forget” logic:

• The transaction is created, signed and fired to the blockchain.
• It is added to the queue (aka memory pool) of any given blockchain and competes to be confirmed with the next block which happens every couple of seconds or minutes (depending on the blockchain; eg ETH 12 seconds, TRX 3 seconds, SOL 0.42 Seconds, BTC 12 Minutes)
• If the transaction fees in the queue spike in the meantime and your transaction doesn’t get picked up, it might end up in a pending state as transaction fees are not adjusted
• Most custody solutions do not monitor this state. The only thing they know is 1) what fee amount it attached to the transaction when it fired it to the blockchain and 2) whether or not the transaction has been picked up.
• There is no notion of ‘keeping a position’ with a given status and no notion of process or time.
• To retrieve dynamic data from the blockchain to understand how the fee amount of the pending transaction needs to be increased for the transaction to be included, you need to build complex custom logic yourself.

So the only thing you can do is to manually resubmit a new transaction or to wait until network congestion drops. Some solutions enable you to manually boost transactions, but no more.

‍

How Layer1’s solves it:

Layer1 provides out-of-the-box automation for this. Instead of a “fire and forget” logic, it deploys sort of a “fire and monitor” logic:

• Creating, signing and firing (aka “broadcasting”) a transaction (as any other solution)
• Monitor the transaction status on-chain and elapsed time / blocks
• Automatically triggering a replacement transaction like a boost transaction or a cancel transaction to release working capital when fees are high.
• You can benefit from our default configuration with best practices from BVNK, but can also configure the rules of automation (eg when and under what circumstances to trigger a replacement transaction) based on your use cases, liquidity requirements or SLAs

These kinds of payments optimisations can save a huge amount of time and hassle when you’re managing stablecoin payments at scale.

‍

But Layer1 goes even further that this, enabling you to hold funds, move funds and trade funds – all within your own environment.

In Part 2, I’ll cover some more powerful and unique elements of Layer1, which support payment companies in converting between stablecoins and fiat currencies at scale.

‍