​That has changed now. SWIFT’s blockchain-based shared ledger is ready for use with seventeen banks preparing for live tokenized deposit transactions. A group of large US banks has also built a network to clear tokenized deposits, which The Clearing House will operate from early 2027. Very recently, it was announced that around 21 global major financial institutions from five regions are launching a USD stablecoin in H1 2027.

​Networks like these need several competing institutions to transact on the same infrastructure. But that raises a question a single-bank ledger never had to answer before. How is privacy handled for each institution? Not permissioning. Permissioning is something we solved years ago.

​Zeeve Tegaris is a modular privacy infrastructure built to answer that question. This article covers the problem Tegaris solves, its main features, the four privacy layers it works across, and a lot more.

What Problem Does Tegaris Solve? Why Do Banks Need a Privacy Solution Like This?

Okay, so what we were saying is most bank blockchain deployments to date have improved efficiency inside one institution. They deploy the ledger, run every node themselves, and give clients or internal teams access through an application. That bank is the only real party on its own network. But honestly, a network like this has stronger integrity guarantees, but it gives no second institution independent assurance, because there is no second institution actually on it.

​

Banks accepted this for years because the use cases in front of them did not require more, and this pattern is still the majority of live activity, concentrated where the parties involved sit inside a single bank or a tightly governed bank-run network.

Source: BCG and Anchorage Digital Report, June 2026

​

That is changing. Multi-bank tokenized deposits, stablecoins, tokenized funds, repo, and cross-border settlement all require more than one institution transacting on shared infrastructure. If you’re thinking about interoperability problems, banks have largely answered that by forming consortium networks, where an FMI, ACH, or a group of leading banks stands up a shared chain, and everyone uses it.

But what does “participating” on that network actually mean for each bank?

It is easy to assume a consortium network already gives its member banks the privacy they need, since the network is permissioned and every member appears involved. But permissioning decides who is allowed to join; it says nothing about what each member can see once inside. In most live multi-party deployments today, participating banks hold application-layer access only. They log in, submit instructions, and view their own activity through an interface, while the entity operating the network runs the nodes, the validator set, and the ledger itself.

​

There is a reason banks accept this. On a standard shared ledger, every institution that runs a node sees every transaction written to it, and no bank will accept that exposure. Permissioned systems were designed so that one entity can observe everything on the ledger. Here’s what the IMF July 2026 Note says about it,

“It is also fair to say that permissioned systems do not really solve privacy-related questions. They are often designed such that one entity can observe everything, and users must trust that this entity neither exploits its privileged position nor becomes compromised by a malicious third party.”

To capture blockchain’s real potential, banks need true network-layer access. What we mean by this is they will run validators themselves, hold an independent copy of the ledger, and verify transactions directly, without losing the confidentiality and compliance a regulated institution requires.

That is the gap Tegaris closes. It gives each participating institution the controls needed to hold a genuine network-layer position, with confidentiality and supervisory access built into the deployment.

What Are the Key Features of Zeeve Tegaris?

The first feature of Tegaris is full-stack privacy. Because blockchain does not follow a single, monolithic architecture, each layer of the stack carries its own risk. Application access, infrastructure participation, transaction contents, and contract execution each expose different risks if left uncontrolled. Tegaris is built with dedicated controls at each of these layers. We will come to this shortly.

The second feature is modularity. Every bank doesn’t need the same privacy setup. Even one bank may need different controls for different projects. An internal asset registry may require strict application access but no confidential token transfer. On the other hand, a multi-bank settlement use case may need private balances, hidden amounts, selective disclosure, and private contract execution. Tegaris lets an institution select the required modules as the needs arise. It can begin at the application layer, add asset privacy when token transfers start, and introduce ledger layer privacy controls when more complex workflows move on-chain. So privacy can grow with the use case.

The third one is policy-driven confidentiality. Tegaris is built for banks, regulated fintechs, and AMCs, where privacy cannot turn into opacity. These institutions need confidentiality from competitors and unauthorized participants. But they also need transparency to stay compliant with regulations. Tegaris uses roles, permissions, ZK proofs, and selective disclosure, to name a few, to create these separate views.

The fourth feature is EVM-agnostic deployment. Tegaris works across all EVM environments. Whether it’s a Besu chain, enterprise rollups, a ZK chain, private L1S, any public-permissioned chain, or even a public chain, Tegaris can integrate with all of them. So a bank can adopt privacy without locking into one blockchain stack, vendor, or deployment model.

How Does Tegaris Work? The Four Layers, Various Modules, and Stack-Agnostic Deployment

Tegaris divides institutional blockchain privacy into four layers. The layers complement one another, but an institution does not need to deploy all four on day one.

Different modules apply these controls at required access points. For example, Tegaris Policy and Control Plane defines who can read state, submit transactions, or call contract functions. Private RPC controls work as an identity-aware gateway that enforces those rules on every JSON-RPC request before it reaches a node. The Private Explorer gives each participant a role-scoped operational view.

The ZK Tokens module covers confidential minting, burning, and transfers for any asset. Selective Disclosure module makes it easy to share proofs for audit and reporting. Custom ZK Circuits can extend this same approach for eligibility checks, private settlement logic, and workflow validation when required because standard transfers do not cover them.

Because these controls sit above the chain, the architecture decision and the privacy decision are always separated. An institution can run application-layer privacy on a base permissioned network and add asset-layer privacy on an L2. It can deploy all four layers on a single Besu network instead if that’s required. If changing the underlying chain later becomes necessary, that can also be done, since the privacy layer was never permanently tied to one protocol.

​And none of these layers require every layer on day one. Application-layer first suits networks whose immediate need is controlling access. Asset-layer first suits programs where the token itself must be confidential from the start. Base-layer-plus-L2 privacy suits architectures where different tiers carry different visibility requirements. Full-stack privacy suits shared networks where every single boundary has to be airtight, which is usually the final goal for a mature group of partner banks.

Let’s Visualize an Example of What Tegaris Can Enable

Let’s suppose three banks are using a shared network for tokenized deposit settlement. Bank A, B, and C.

In a conventional sponsor-operated model, the network operator runs the blockchain infrastructure. Each bank logs into an application, submits instructions, and receives the information that the application permits it to see.

As mentioned before, in this model, banks use a blockchain-based service, but they do not independently validate the underlying ledger. Every participating bank here has a governance seat in the consortium to make the arrangement look democratic.

A consortium may want each bank to operate a validator. That creates shared verificted explorer views show each bank only what it needs to see, while auditors get read-only access to specific proof according to the disclosure policy.

To be clear, Tegaris here does not decide how many validators a consortium must run or which party should operate them. It only provides privacy controls that make a more distributed operating model practical.

Some Use Cases Tegaris Can Support

Tokenized deposits

Tokenized deposits represent commercial bank money on programmable infrastructure. Their usefulness increases when they can move across institutions and connect with other tokenized assets.

That shared nature can expose sensitive information. For example, payment amounts, counterparties, etc which should never be visible to every member of the group. Tegaris keeps these details strictly private while still letting internal bank teams and approved regulators see what they need.

Cross-border payments and remittance

International transfer networks reveal sensitive business clues, like which banks work together, customer activity spikes, or total cash flow. Competitors can easily use those trends to gain an edge.

Tegaris keeps the payment details strictly between the banks involved. Everyone on the network sees only what matches their specific role in the transaction.

Stablecoin use cases

Issuers, distributors, banks, payment providers and supervisors do not require identical visibility, right? A retail user may need privacy from other users. An intermediary may need information for compliance. A central bank or regulator may require a governed supervisory view.

Tegaris can support these layered responsibilities through policy-based access, confidential assets, and selective disclosure.

Tokenized funds and RWAs

Tokenized investment products carry investor information, allocation details, subscription and redemption activities. Putting the asset on a shared ledger should not publish the private business surrounding it.

Tegaris can protect investor and transaction data while allowing approved issuers, distributors, custodians, auditors and regulators to perform their respective functions.

Repo and collateral workflows

Repo transactions expose positions, funding behavior, collateral choices, pricing conditions, and counterparty relations. Some of this information must also be verified across institutions. Not every member of the network should see it. Right?

Tegaris uses private workflow state, hidden asset transfers, and selective data sharing. This makes the deal fully auditable for the two trading banks and their watchdogs, without putting sensitive deal terms in front of bystander banks.

Apart From Tegaris, What Else Does Zeeve Provide?

Privacy is one part of building institutional blockchain infrastructure. A very important part, yes, but still one part.

The institution must first choose an architecture. It must decide whether the use case belongs on Besu, an enterprise EVM rollup, a private Layer 1, or a hybrid kind of architecture. If an older blockchain network already exists, migration may be a bigger concern too.

Zeeve works with banks, financial market infrastructures, asset managers, and regulated fintech companies across these decisions. It provides architecture consultancy without forcing every institution towards one preferred protocol. The selected network can run in Zeeve-managed infrastructure, inside the institution’s own cloud account through Bring Your Own Cloud, on-premises, or in a hybrid environment.

Zeeve also supports the deployment and management of blockchain nodes and networks along with monitoring and ongoing operations support. Its infrastructure operates within ISO 27001 and SOC 2 Type II compliant environments. Expert-led migration support can help institutions move from legacy blockchain setups to a new infrastructure more easily.

Zeeve has years of experience deploying and managing blockchain networks for enterprises. 

Talk to us for unbiased consultancy and privacy-enabled blockchain solutions.

It has studied the available enterprise blockchain frameworks, spoken to its technology team, and finally chosen Besu. And the choice makes sense. Besu-based architecture is already being used for Swift’s shared ledger, Citi Token Services, DTCC’s collateral platform, and many others.

So, is the difficult part over?

Well, it seems the difficult part is only about to begin.

Choosing Besu gives the bank a ledger. It does not automatically give the bank institutional privacy, core banking connectivity, or security controls.

All of that must still be designed, built, and operated.

This is where the difference between deploying Besu and implementing Besu for a bank becomes important. The first can be done by a capable engineering team. The second requires a complete financial infrastructure around the chain.

And that is where Zeeve comes into the picture.

The Problem with Basic Besu Deployments

Getting a few nodes online is not terribly difficult.

A team can configure a validator set, select QBFT or IBFT 2.0 consensus, connect the peers, and watch the network produce blocks. For a demo, this may be enough. For a regulated settlement network, it is only the starting point.

The trouble begins when questions start arriving from outside the blockchain team.

Who approves a new validator? Which member can read which transaction? Where are the signing keys held? How will an event on Besu reach the core banking system?

Besu, on its own, does not answer these questions.

An in-house implementation leaves every answer with the bank. The bank must assemble the architecture, harden the infrastructure, create the governance processes, connect the legacy systems, monitor the network, plan upgrades, and maintain an incident-response team. It also owns the complete attack surface across the infrastructure and integration layers. This is the layer where most of the issues happen. 

Here’s what the BCG & Anchorage Digital 2026 report says about it,

“Security concerns are a key gating factor: stakeholders are often constrained by uncertainty around technical vulnerabilities and attack vectors, and this is further exacerbated by the fact that banks are typically not native operators or experts in this domain.

As highlighted by recent incidents, vulnerabilities often emerge in low-level infrastructure and integration layers, not just application logic. The technology agenda should therefore prioritize resilience, security-by design, and reliance on proven architectures.”

Basic node hosting with just another provider does not take the problem much further. It may place the nodes on servers and keep those servers running, but the bank is often still left to handle the rest of the things. For example, banking integrations, privacy engineering, monitoring, and incident response.

This is why the sensible division of work is not difficult to see. A bank should retain the areas in which it has a lasting advantage, like its customer relationships, internal controls, client channels, and core banking systems. For blockchain orchestration and other digital-asset-native infrastructure, it can work with an external provider with mature expertise that already knows how the pieces fit together.

Again, this excerpt from the same BCG report needs an absolute mention here. 

Zeeve is built for this part.

Below are five reasons, broken down, on why Zeeve matters for a Besu implementation.

1. Institutional Privacy and Custom Controls

The words permissioned and private are often used together. That makes them sound like the same thing.

They are not.

Permissioning decides who may enter the network. Once inside, the participants may still hold readable copies of the same ledger. For a bank, that can expose balances, counterparties, contract state, or transaction activity to institutions that have no business seeing them.

It is much like allowing only approved people into a building but giving every person inside a key to every room.

Banking secrecy and client confidentiality require something more precise. The network must control not only who may join, but also who may see what after joining.

Zeeve provides this through Tegaris, its modular privacy framework. Instead of treating privacy as one piece, Tegaris applies it at four different layers.

At the application layer, it controls access to RPC endpoints, user actions, and explorer views. At the network layer, it governs validators, peers, and node onboarding. At the asset layer, zero-knowledge proofs can keep balances, amounts, and counterparties confidential. And at the ledger layer, smart-contract state can be limited to the participants who are supposed to see it.

Read More: The Four Layers of Blockchain Privacy: What Banks & Financial Institutions Need to Know

Though we said there are four layers, the bank does not have to begin with every privacy control at once. It can apply what the first use case requires and add stronger privacy controls as the network expands.

2. Bank-Grade Compliance and Security

A familiar temptation in new technology projects is to build the product first and deal with compliance once it works.

A bank does not have that luxury.

Its Besu infrastructure is expected to meet the same security standards as the other systems on which financial operations depend. The firewalls, access controls, logs, key custody, and evidence trails therefore cannot be loose pieces added later on unless it’s under a regulatory sandbox. They must exist underneath it from day one.

Zeeve provides an environment aligned with that requirement. Its infrastructure is ISO 27001 and SOC 2 Type II compliant and follows GDPR data rules. Enterprise firewalls, DDoS protection, role-based access control, and audit-friendly logging are part of the production setup.

Then there is the matter of keys.

Validator and treasury keys are not ordinary passwords. If their custody is weak, the rest of the network’s security becomes vulnerable. Zeeve integrates with enterprise key-management systems and bank-grade Hardware Security Modules (HSM), allowing the keys to remain within the bank’s approved custody perimeter.

This does not transfer the bank’s accountability to somebody else. Nor should it.

As a result, the compliance team keeps ownership of the controls. Zeeve provides the certified operating environment and the evidence trail that allows those controls to be reviewed.

That makes the arrangement workable. The bank here is responsible for its obligations without having to invent every piece of blockchain security infrastructure for itself.

3. Deployment Flexibility with BYOC, On-Premise, and Hybrid Options

Many technology products usually can start using the provider’s cloud.

For a bank, that instruction may be impossible to follow.

Data-residency requirements may determine the country in which infrastructure must run. Outsourcing rules may also apply, which will define which party can control it. Their internal policy may also require sensitive workloads to remain inside the bank’s own cloud account or physical data center.

So, what happens if the Besu infrastructure provider supports only one deployment model?

The bank is forced to redesign its policy around the technology or abandon the technology altogether.

Zeeve brings a solution to this. With Zeeve Bring Your Own Cloud (BYOC), Besu nodes run inside the bank’s existing AWS, Azure, or GCP account, under its own governance and billing. With an on-premise setup, the nodes remain on the bank’s physical infrastructure. And with a hybrid deployment, the network can span both environments while Zeeve orchestrates its monitoring, deployment, and upgrades.

This flexibility becomes even more useful in a consortium.

One member may be permitted to use a public cloud. Another may need to keep its validator on-premises. A third may have a separate regional requirement. Each institution can operate within its own regulatory boundary without breaking the network into three separate systems.

In a multi-bank network, this small-sounding change may be the change that makes participation possible.

4. Legacy Financial Integration and Asset Tokenization

A transaction may settle perfectly on Besu and still create problems if proper reconciliation is not done.

Because the core banking system may not know that it happened. The general ledger will have to wait for a separate entry. The fraud-monitoring system will also never receive the event. And the operations team may have to reconcile the same transaction by hand.

This is why integration with a core banking system (CBS) is a high-priority task. A production blockchain ledger must communicate with these CBS through which the institution keeps accounts, checks customers, monitors risk, and reports its financial position.

Zeeve offers integrations that connect every Besu event with core banking systems, KYC and AML tracking, and fraud-monitoring tools. Any event recorded on the blockchain can therefore move into the bank’s existing operating stack without creating a parallel manual process.

There is an asset side to this problem as well.

A Besu chain can use the Cosmos tokenization engine as well. And Zeeve, as a partner of Cosmos Labs and LF Decentralized Trust, can integrate both frictionlessly, giving banks a path to issue compliant tokenized assets on their permissioned networks. For connections outside an individual network, the Inter-Blockchain Communication protocol can be used. This allows a private banking ledger to transact with other independent financial ledgers without depending on one bridge provider.

That may not look urgent when a bank is building its first network. It becomes urgent when tokenized deposit systems, asset networks, and interbank settlement ledgers begin multiplying.

Apart from this, integration with other enterprise tools and systems is also possible with Zeeve.

5. 24×7 Operations

What’s most attractive about the word ‘deployment’?

It sounds kind of complete. Right?

‘The network has been deployed’.

Feels the project has crossed the finish line. So everyone can now move to the next important thing.

Except the network that has only just started its life.

From that point onward, it must remain available and continue working as usage changes. Problems must be noticed. Someone must know what to do when the network behaves differently from what was expected. Every alert needs to be investigated also.

Zeeve reduces that load in three ways.

First, One-click provisioning of Besu nodes deploys production-ready QBFT or IBFT 2.0 consensus configurations in minutes. This saves a lot of time.

Second, full-stack dashboards monitor node health, validator performance, block production, RPC activity, logs, and alerts. They are backed by round-the-clock incident response and strict enterprise SLAs.

Third, automated upgrade orchestration handles node patching and Besu client updates across the network without any downtime or network forks.

So, How a Production Besu Architecture Changes with Zeeve’s Full-Stack Infrastructure

At the center of the architecture, Besu remains Besu. There are issuer and counterparty validators, custodian nodes, regulated member nodes, and observer nodes. They participate through a permissioned membership model and reach consensus using QBFT or IBFT 2.0.

Above that network layer, there is the platform logic layer, where smart contracts, all use cases, asset rules, and policies live. An API and integration layer connects that logic to application layers like bank portals, fintech platforms, or any partner interface.

Then there are systems that make the ledger safe and useful. Key management, HSMs, custody, KYC and AML services, identity and access management, and reporting come in this layer.

And around the complete stack sits the operating layer that brings in monitoring, alerts, incident response, logs, and SLA-backed support for BYOC or other cloud environments.

That is the architectural difference.

A basic setup places Besu on infrastructure. Zeeve places Besu inside a governed, connected, privacy-enabled, continuously operated banking system.

The result can support tokenized deposits, tokenized funds, and real-world assets, interbank settlement networks, or a Quorum-to-Besu modernization without forcing the bank to build every surrounding capability from the ground up.

Deploy Your Besu Chain with Zeeve

Besu is a sound choice for a permissioned banking network. But the client is only one part of the choice.

The network must still be designed for the institution, deployed within its infrastructure boundaries, governed across its members, and operated every hour that financial activity may occur.

Zeeve brings those responsibilities together through a four-stage model: Design, Deploy, Govern, and Operate.

Design establishes the architecture, validator model, consensus choice, privacy requirements, cloud strategy, and production plan. Deploy provisions the network across managed, BYOC, on-premise, or hybrid environments and connects the required key-management systems. Govern sets the member-onboarding process, validator approvals, permissioning rules, and network policies. Operate keeps the complete system monitored, patched, upgraded, and supported under an SLA.

So, if your bank is planning a tokenized deposit platform, an interbank settlement network, or a move from Quorum to Besu, choosing the client is a good beginning.

Choosing who will turn it into production infrastructure is the decision that follows.

Ready to map your use case to a production Besu architecture?

Talk to a Zeeve architect.

Let’s suppose five banks decide to work from the same building.

It is not an ordinary office building. It has one shared record room where every deal, payment, and movement of money is entered. Whenever one bank adds a new record, copies are made for the others too.

The banks like this arrangement because nobody can quietly change an old record. If Bank A says a payment happened and Bank B later denies it, the other copies settle the matter.

This shared record room is our blockchain.

Of course, the banks do not let anybody walk into the building. There is a guard outside with a list of approved names. Only the five banks, their chosen employees, and a few operators are allowed in.

This is a permissioned blockchain.

The building is closed to the public, so everyone calls it private. There is only one small problem. After passing the guard, a person can still see almost everything inside.

The record room is open. The screens in the hallway show recent activity. Copies of the records are kept in each bank’s office. Even a technician who came to fix one screen may find that the other screens are working perfectly well for him too.

So yes, the building has a gate. But does it have privacy?

Not really. At least, not yet.

Because permissioning answers who is allowed to enter the network? It does not answer what they can see once they are in.

That leaves four separate privacy jobs linked with different layers of blockchain architecture. 

Application level privacy, network level privacy, asset level privacy, and ledger level privacy. A bank may need two of these layers or all four. It depends on who shares the network and what kind of business is happening there.

Keep the building in mind. We will keep coming back to it.

Before privacy, understand what a blockchain exposes

A blockchain is usually spoken about like it is one machine. It is actually several things put together.

There are servers running the nodes. A network connects those nodes. Validators agree on the next block. The ledger keeps transactions and smart-contract state. Then there are all the tools people use to reach the ledger, such as wallets, RPC endpoints, APIs, explorers, indexers, and dashboards.

These tools do different jobs, but they also create different ways to see information.

A full/validator node keeps a copy of the ledger. An RPC endpoint answers questions about accounts and transactions. A block explorer puts the same information into a neat, searchable screen. An indexer copies blockchain data into another database so applications can search it faster. Smart contracts publish events, and other systems can sit there listening to them all day.

None of these tools are doing something wrong. They are built to make blockchain data available.

The trouble starts when the bank has not decided who the data should be available to.

Back to our building for a moment. Stopping strangers at the main gate is useful. But it does not help much if every room inside has a glass wall. Nor does putting a lock on one filing cabinet help if the same papers are being shown on a screen in the hallway.

Each privacy layer deals with a different opening.

Layer 1: Application privacy decides who can use which door

Suppose Bank A brings in a technology vendor to manage a payment application.

The vendor needs access to payment records. Fair enough. But it does not need to see Bank A’s treasury movements, client settlement history, and every contract being used by the other four banks.

Still, that can happen quite easily.

Most people do not interact with a blockchain by reading raw blocks. They use an explorer, a dashboard, an API, or some business software connected through an RPC endpoint. These are the doors through which ledger data is normally reached.

If every door opens into the whole building, the guard at the entrance is not doing enough.

A standard JSON-RPC endpoint may answer a query about any account or transaction. A normal block explorer may give every user the same view. An indexer may copy the complete ledger into a database. Event subscriptions may send contract activity to any system that has been connected.

No hacking is needed here. A vendor can see too much simply because nobody narrowed its access. A support engineer may be checking a failed node and end up browsing customer transactions. An analytics company hired for one report may quietly receive a copy of data from several other business lines.

Application-layer privacy is meant to stop this kind of overexposure.

Role-based access decides what each employee, vendor, application, or auditor is allowed to read. A private RPC gateway applies those rules whenever someone sends a request. The explorer can show different views to different people instead of treating every signed-in user like the owner of the place.

The same idea applies to smart contracts and event feeds. A user may be allowed to view a contract but not call an important function. An indexer may receive payment events but not treasury events. An auditor may receive a wider view, with every visit recorded in an audit log.

A simple diagram that shows the vulnerabilities and how this is being addressed. 

In our building, application privacy is the set of keys and access cards used after a person has entered. The vendor gets the key to the payment office. It does not get one giant master key because that was easier to configure.

For an internal blockchain run by one bank, this layer may do most of the privacy work. It is also important when outside vendors, auditors, support teams, or several business units use the same network.

But there is a limit.

An access card can stop someone from opening a room. It cannot make that room invisible to another bank that already has a complete copy of the records in its own office. For that, we have to look at the network and the ledger itself.

Layer 2: Network privacy decides who is allowed in the building

Most institutions start with network privacy.

The network has an approved set of validators. New nodes go through an onboarding process. Old members are removed when they leave. Peer rules decide which nodes can connect to one another, and mutual TLS helps confirm that each node is speaking to the right machine rather than an impostor.

The infrastructure can also be kept away from the public internet. Operators, cloud providers, and managed-service teams can be placed under clear access and confidentiality rules.

All of this matters. A bank should know who is running the machines that hold its records. A consortium should know which member is allowed to validate transactions. A regulator will probably want to know too.

But let’s return to the building.

The guard outside checks names carefully. He keeps strangers away. He even records what time every approved person enters and leaves.

That makes the building secure from outsiders. It says nothing about what the five banks can see about one another.

This is why the line “we use a permissioned blockchain, so the data is private” is incomplete. Permissioning is membership control. Once a member joins and runs a full node, it may receive the same ledger as everyone else.

For one bank running all the nodes (a private ledger), that may be acceptable. For five competing banks (a shared network/ consortium), it is a different story. Each member could watch the others’ activity, not because it broke any rule, but because receiving ledger data is part of running the node.

Blockchain replication is the reason members can verify the history instead of trusting one central record keeper. But replication and confidentiality pull in different directions. If every participant receives the same information, every participant can potentially study it.

Network privacy gives the building a proper gate, and no institutional blockchain should be without one. It just does not put curtains on the windows inside.

Layer 3: Asset privacy decides what is inside the payment envelope

Now suppose Bank A sends money to Bank B.

The payment record shows the sender, the receiver, the asset, and the amount. Banks C, D, and E are not part of the payment, but their nodes may still receive the record.

One payment may not tell them much. After six months, they can begin to notice patterns.

They may see that Bank A sends large amounts to Bank B every Friday. They may notice its treasury moving funds at certain times of the month. They may work out which corridors are busy, which counterparties trade often, and where liquidity appears to be tight.

The ledger slowly becomes a map of Bank A’s business.

This is where asset privacy comes in. It hides the value being moved: the balance, the amount, the type of asset, and sometimes the identities of the parties.

One way to do this is with a zero-knowledge proof.

Suppose Bank A puts a payment instruction in a sealed envelope. The other banks cannot read the amount. However, attached to the envelope is a special proof showing that Bank A has enough money, the numbers balance, and the payment follows the agreed rules.

The network only can check the proof, but can’t read any private numbers inside the envelope.

That is roughly what a zero-knowledge system does. It allows the network to confirm that a transaction is valid without showing every detail used to create it.

This can mean confidential balances, hidden transfer amounts, private counterparties, and confidential minting or burning of tokens. It can also cover deposits and withdrawals when tokenized money moves in or out of the network.

There is an obvious question here though. If the transaction is hidden, how does an auditor verify it?

The answer is selective disclosure. The envelope is not sealed forever and for everyone. A regulator, auditor, or compliance officer can be given the right to inspect particular evidence under an agreed policy following the standard messaging standards. The other banks still do not get to look inside merely because they share the network.

Banks need asset privacy when the thing on the blockchain is money, or close enough to money that its movement reveals commercial information. Tokenized deposits, settlement assets, stablecoins, cross-border payments, and treasury transfers all fall into this area.

So now our shared building has a guard, access cards, and sealed payment envelopes. It sounds quite private.

We are still missing one room.

Layer 4: Ledger privacy decides who can see the meeting

A financial deal is rarely just a payment.

Take a repo between Bank A and Bank B. First, the parties agree on terms. Then collateral is locked. Cash is settled. The position is managed for a period, and later the whole thing is unwound.

Asset privacy can hide the amount of money in this deal. But the other banks may still see that a repo contract was used, which addresses interacted with it, when the steps happened, and how the contract changed from one stage to the next.

They cannot read the payment envelope, but they can stand outside the meeting room, see who went in, hear when people move around, and watch them leave with a collateral file.

Sometimes that is enough information.

A competitor may not know the exact terms, but it now knows that Bank A and Bank B completed a certain kind of transaction at a certain time. In institutional markets, that is not harmless metadata as it can reveal a trading relationship or a funding need.

Ledger-layer privacy makes the meeting itself private. The contract state and its execution are visible only to the parties involved and to others who have a proper reason to see them.

There is more than one way to arrange this.

• A private sub-ledger lets a smaller group of participants keep a shared record that the others cannot read.

• A private Layer 1 gives a defined group its own chain or chain segment.

• A ZK rollup carries out activity away from the base chain and sends back proof that the result is correct.

• A bilateral workflow keeps contract state between the two parties doing the deal.

• Privacy-scoped execution lets the wider network verify that a contract ran correctly without giving everyone the details.

The technical design may change from one platform to another. The purpose is the same: sharing a blockchain should not mean sharing every business process happening on it.

This matters in syndicated lending, where lenders may take part in the same facility without seeing one another’s private terms. It matters in repo and collateral management. It matters in OTC trade confirmation, where two parties do not want the rest of a consortium reading the history of their deal.

Asset privacy hides what was in the envelope. Ledger privacy closes the meeting-room door.

That is the difference.

Putting the four layers together

Our imaginary bank building now looks a little more sensible.

The guard at the main gate decides who belongs to the network. That is network privacy.

Access cards decide which rooms and screens each person can use. That is application privacy.

Payment details travel in sealed envelopes that can still be checked for validity. That is asset privacy.

Private deals happen in rooms where only the relevant parties can see the process. That is ledger privacy.

Here is the same idea without the building:

Does a bank need all four layers?

Not always.

If one bank runs an internal blockchain for its own teams, application access and network controls may be enough. There are no competing banks operating nodes, so hiding every transaction with cryptography may create more work than value.

If several banks share a tokenized deposit platform, asset privacy becomes much more important. Members may trust one another to follow the network rules without agreeing to share their balances and payment history.

A consortium settlement rail carrying real volume may need all four layers. It has several node operators, many users, outside vendors, sensitive transactions, and regulators who require access of their own. A single privacy control will not cover all of that.

The blockchain platform changes the starting point too.

Networks such as Canton include privacy in the protocol. That gives institutions a ready-made privacy model, which is useful when the use case fits it. The same model may be less flexible when a bank wants very different privacy rules for different products.

Custom chains offer more freedom. A bank may build with Hyperledger Besu, a dedicated Cosmos-based Layer 1, an EVM chain, or a ZK-powered Layer 2. These networks often start with permissioned membership. The remaining privacy controls still have to be designed or added.

The better approach is to decide early which information may become sensitive as the network grows. Then the privacy layers can be added in a sensible order.

A few common questions

Isn’t a permissioned blockchain already private?

It is private from people who are not allowed to join. It may still be transparent to the approved members running nodes. Permissioning tells you who is inside the building, not what they can see there.

Can a regulator audit a confidential transaction?

Yes. Selective disclosure can give a regulator or auditor access to the required evidence without showing the same data to every network member. A zero-knowledge proof can also confirm that a transaction followed the rules while keeping its private details hidden.

Does every bank need ZK proofs?

Not really. If it’s a private ledger and the main concern is employee or vendor access, standard policy controls are sufficient. ZK is useful when it’s a shared infrastructure but should not see one another’s balances, amounts, or workflows.

Which layer should come first?

Start with the place where information is leaking. If too many employees and vendors can query the chain, begin at the application layer. If competing institutions can read one another’s payments, asset privacy is the urgent problem. Network controls are a basic requirement in both cases.

Where Zeeve Tegaris fits into this

Zeeve Tegaris, the Zeeve Privacy Layer, is built around these four separate privacy needs.

The suite is modular and can be integrated with any chain type.The modules cover access governance, identity-aware private RPC, role-scoped private explorers, and ZK-based confidential tokens. They also include selective disclosure for auditors and regulators, custom ZK circuits for business-specific workflows, and audit dashboards for oversight.

Tegaris works across EVM-based environments, including Hyperledger Besu, custom EVM chains, ZK rollups, public-permissioned networks, and hybrid architectures.

So an institution does not need to abandon the network it already has just to improve privacy. It can look at the missing walls and add them where they are needed.

And that is probably the easiest way to begin.

Who is standing at the gate? Who has keys to each room? Which payment details are exposed? Which meetings can other members watch?

Once those four questions are answered honestly, the privacy gaps are usually not difficult to find.

Talk to Zeeve blockchain experts to discuss your requirements.  

Every regulatory regime for bank-issued digital money starts with that question. Because the answer only determines whether a token qualifies for deposit insurance, how it’s treated on the balance sheet, and who is allowed to issue it.

But banks are not waiting for full global convergence. Approximately two-thirds of banks are developing or discussing tokenized deposit solutions for corporate clients, per the American Banker 2026 survey. 

At the same time, regulators from Washington, EU, UK, Singapore, Hongkong and other countries have published rules, proposals, and pilot frameworks that differ in structure and scope.

This article maps how major countries treat tokenized deposits, compares their positions on a scorecard for risk and compliance executives, examines their blind spots, and concludes with an implementation roadmap for banking leaders.

How Do Different Countries Regulate Tokenized Deposits?

United States

US has taken a technology-neutral stand for tokenized deposits with a clear boundary for stablecoins. So in the US, a deposit recorded on a distributed ledger is still a deposit, and the ledger does not change its legal character.

Source: federalregister.gov/documents

The Federal Deposit Insurance Act’s definition of “deposit” is technology-neutral, and tokenized forms do not constitute a separate category under FDIC regulation. In April 2026, the FDIC Board approved a proposed rulemaking that would codify this directly, stating that a financial product meeting the statutory definition of a deposit remains a deposit regardless of the technology used to represent or record it, and proposing that tokenized deposits receive the same deposit insurance treatment as conventional deposits. 

This is reinforced by the GENIUS Act as well. It has created a separate federal framework for payment stablecoins and excluded tokenized deposits from that category. Stablecoin holders are explicitly barred from earning yield under GENIUS; tokenized deposit holders are not, because the underlying claim is still a bank liability, not a redemption right against a reserve pool. 

But there are a few edge cases that still need clarification. For example, clarity on BSA/AML checks specific to tokenized deposit networks, or how pass-through insurance concepts apply when a wallet provider is there between the bank and the end holder. 

In practice, US banks are currently using private, permissioned networks. For internal transfers, banks like JPMorgan and Citi use their own private ledgers. For transfers between different banks, a shared platform (like The Clearing House) coordinates the transactions. But the final settlement still runs through the traditional central bank RTGS system.

European Union

The EU took a different legal approach from the US to regulate tokenized deposits. The US has updated its banking rules to fit digital tokens. But the EU has created its new crypto law (MiCA) and explicitly left tokenized bank deposits out of it. Instead, the EU keeps them under traditional banking laws. 

“Accordingly, this Regulation expressly excludes from its scope crypto-assets that qualify as financial instruments as defined in Directive 2014/65/EU, those that qualify as deposits as defined in Directive 2014/49/EU of the European Parliament and of the Council (7), including structured deposits as defined in Directive 2014/65/EU…” 

Source: eur-lex. europa.eu/legal-content (Article 2, Paragraph 4, Clause (b))

This allows tokenized deposits to skip the heavy regulatory costs and capital rules that MiCA puts on electronic money tokens and asset-referenced tokens like stablecoins.  

So how a bank designs the token will determine if it gets deposit insurance or not.

• To get Deposit Status (Protected): The token must be tied directly to a traditional bank account. When a customer moves money to the blockchain, the bank debits their regular bank account and credits their digital token balance. Because it is backed by a real account on the bank’s core system, it counts as a regular deposit and gets deposit insurance. 

• To be treated as Crypto/EMT (Not Protected): If the token exists only on the blockchain ledger, with no connection to a traditional bank account, the EU views it as a “bearer instrument” (like physical cash or a stablecoin). The EU classifies this as an Electronic Money Token (EMT). It does not get deposit protection and faces stricter crypto rules. 

This is a meaningful design constraint. If your bank wants to offer tokenized deposits that keep their regulatory deposit status and insurance in the EU, you cannot build freestanding crypto tokens. You must architect the system so every blockchain token is anchored to a traditional, off-chain bank account. 

To give banks a supervised space to test without waiting for final regulation, the EU created a legal sandbox called the DLT Pilot Regime that lets institutions trial tokenized delivery-versus-payment and settlement rails. This was started in March 2023 and will be valid for 6 years.

Source: EY

United Kingdom

UK banks are operating tokenized deposits under existing banking permissions until a separate framework is finalized. The UK is building the framework live, through the Digital Securities Sandbox (DSS),  Great British Tokenized Deposits (GBTD) pilot, and a few other initiatives mentioned below.

In the Digital Securities Sandbox, the central bank’s guidance makes it explicit that tokenized deposits can be used as a payment asset within it, alongside other low-risk, regulated forms of private money, and that this approach aligns with the CPMI-IOSCO Principles for Financial Market Infrastructures. Sixteen firms, including HSBC, Euroclear, and the London Stock Exchange Group, are preparing to launch live tokenized settlement services through this sandbox from late 2026. 

Here’s what Sarah Breeden, Deputy Governor for Financial Stability said in her May 2026 speech,

“The sandbox will enable markets in these securities to grow up to a set size over the next five years, during which time the Bank, FCA and HM Treasury intend to learn from firms’ activity and, subject to that, to determine the new, permanent regulatory regime for the trading and settlement of digital securities.”

So, this controlled, five-year window gives financial institutions the operational predictability needed to scale their digital asset testing .

On the commercial banks’ side, the main vehicle is the Great British Tokenized Deposits (GBTD) pilot, coordinated by UK Finance with Barclays, HSBC, Lloyds, NatWest, Nationwide, and Santander. It runs live transactions through mid-2026 across three use cases. These are marketplace payments, remortgaging, and digital asset settlement. 

Source: UK Finance

The GBTD pilot connects into the Bank of England’s Digital Securities Sandbox work on cross-ledger settlement.

The UK is also coordinating internationally. Very recently, HM Treasury (UK) and the US Treasury have published the first ten recommendations of the Transatlantic Taskforce for Markets of the Future. The recommendations endorse a multi-money ecosystem in which stablecoins, tokenized deposits, and other forms of digital money coexist and interoperate. They are non-binding, and they indicate the direction both regimes intend to take. 

Source:  HM Treasury / US Treasury joint publication

Switzerland

Switzerland does not have any separate law for governing tokenized deposits. Hence the 2024 FINMA guidance is used here. Under FINMA’s stablecoin guidance, a fiat-pegged token with a fixed 1:1 redemption claim against the issuer is treated as public deposit under banking law, and accepting public deposits on a professional basis requires a Swiss banking licence.

Because Switzerland uses traditional banking rules, a company that wants to issue a fiat-pegged token has only two choices:

• Option 1 : You get a full Swiss banking license. The tokens you issue are treated as tokenized bank deposits. They are fully regulated under standard banking laws and automatically covered by the Swiss deposit insurance scheme (up to CHF 100,000).

• Option 2: If you are a FinTech and don’t have a banking license, you cannot hold the customer’s cash backing the token on your own beyond a limit. You must take all that cash and deposit it into a licensed Swiss bank. That bank must then issue an irrevocable default guarantee.

If option 2 is taken, the token holders are not protected by the government’s deposit insurance scheme if the fintech goes bankrupt. Instead, the private bank’s default guarantee substitutes for deposit insurance. So the token holders have a direct legal right to go to the Swiss bank that backed the project and make a claim. 

Hong Kong

Hong Kong’s approach runs through the Hong Kong Monetary Authority’s Project Ensemble. Its current phase, EnsembleTX, moved from simulated testing into real-value transactions in late 2025 and is running through 2026 with seven commercial banks. 

Interbank settlement of tokenized deposit transactions is handled today through the existing Hong Kong Dollar Real Time Gross Settlement system, with a roadmap toward 24/7 settlement in tokenized central bank money once the infrastructure matures. 

Both regulators are treating the underlying legal claim as a standard bank liability; the innovation is in the settlement rail, not the legal wrapper. 

Hong Kong regulates stablecoins separately. The Stablecoins Ordinance, effective 1 August 2025, established a licensing regime for fiat-referenced stablecoin issuers. Tokenized deposits sit outside that regime, inside the banking perimeter.

Singapore

Singapore separates stablecoins and deposit tokens cleanly. MAS regulates single-currency stablecoins under a dedicated framework. For deposit tokens, a MAS consultation proposed that no additional reserve backing or prudential requirements should be imposed on issuing banks, on the grounds that existing capital, liquidity, AML, and technology risk requirements already protect banks and their customers.

“As to bank SCS issuers, MAS acknowledges the feedback that there are differences in the value-stabilising mechanisms used for fully reserve asset-backed stablecoins and tokenised bank liabilities, and thus the risks they pose to holders. MAS will therefore exclude tokenised bank liabilities from the scope of the SCS framework. However, MAS may impose additional requirements on tokenised bank liabilities in the future as necessary, taking into consideration the design of such tokenised bank liabilities.”

Source: MAS, August 2023 Response Paper 

Alongside this, MAS’s BLOOM initiative and the long-running Project Guardian are testing cross-border interoperability for tokenized bank liabilities with more than 40 participating institutions. 

The Regulatory and Balance Sheet Scorecard for Tokenized Deposits

How Banking Executives Should Approach Tokenized Deposit Implementation 

Given how fragmented the legal landscape still is, the sequencing of a tokenized deposit program matters as much as the technology choice itself. 

1. Start with infrastructure selection.  

The first decision is network topology. A private single-bank ledger maximizes control and the most legally safe option. A shared multibank network extends reach globally and lets banks join global or existing consortiums. 

Within permissioned architectures, the choices can be from permissioned EVM chains, ZK chains, and Hyperledger Besu deployments to custom L1s. The choice of tokenization engine is also vital as it should match requirements for mint, transfer, and burn lifecycle control, messaging standards, identity integration, and auditability. 

Whatever the choice, banks should plan for deep integration with core banking, cash management, and treasury systems, since that integration is what enables large-scale corporate adoption. 

2. Choose the first use case for demonstrable value. 

Liquidity orchestration is the strongest opening move for most institutions. Smart-contract-driven treasury services offer immediate, measurable value to multinational enterprise clients. 

Adoption today is already concentrated in corporate treasury, selected cross-border payments, and intraday financing workflows within single-bank or tightly governed environments.

3. Where a sandbox exists, use it.  

The EU DLT Pilot Regime, the UK Digital Securities Sandbox, Hong Kong’s EnsembleTX, and the ADGM framework each provide supervised environments that reduce regulatory ambiguity during testing. 

Building inside these structures also creates a documented engagement record with supervisors, which is useful when bespoke rules arrive. 

4. Design privacy and compliance from day one. 

Banks should design entire system-wide privacy instead of just network level privacy in their blockchain stack used for tokenized deposits. It can’t be limited to only participator level access control that default enterprise blockchain networks provide. Selective disclosure, custom ZK-workflow, role-based access control, confidential token transfer, and more such components are necessary in a bank-grade blockchain. 

And they need to be designed from day1 to stay compliant. 

Zeeve for Unbiased Consultation and Privacy-Enabled Blockchain Infrastructure

Zeeve provides privacy-enabled blockchain infrastructure built for exactly this kind of regulatory complexity. Zeeve’s modular privacy layer Tegaris gives institutions application layer, network layer, asset layer and ledger layer privacy that gives 360 degree controls suited to tokenized deposit architectures. 

Zeeve’s infrastructure offersISO 27001 and SOC 2 Type II compliant environments, and Bring Your Own Cloud deployment so institutions retain control over where their data and infrastructure live. For banks already running on legacy blockchain infrastructure, Zeeve also helps in migration without requiring a full rebuild. 

Zeeve has a multi-stack expertise and can help banks and financial institutions build with any kind of blockchain stack. 

Zeeve has helped a big US bank with their tokenization initiative. Talk to us to discuss yours. 

The big question now is where that token should live. Banks have spent a decade testing permissioned ledgers, consortium networks, and even public chains. A newer answer could be building a bespoke rollup, meaning a dedicated Layer 2 chain that the bank or a bank consortium controls, running the Ethereum Virtual Machine (EVM) and anchored to an external settlement layer.

This article explains why the EVM standard matters even for banks that avoid public chains, where bespoke rollups could win against the alternatives, how a tokenized deposit rollup works, what the architecture looks like, and much more.

Why Does the EVM Standard Matter Even if a Bank Is Not Using a Public Chain? 

The EVM is the execution environment that runs Ethereum smart contracts. A chain is EVM-compatible when contracts written for Ethereum run on it without modification. That definition sounds technical. The commercial consequence is simple. EVM compatibility determines which developers, audit firms, token standards, and integration tools a bank can use safely.

There are enough precedents now that indicate financial institutions are converging towards EVM standards. For example, J.P. Morgan’s tokenized deposit platform runs on a private Enterprise Ethereum stack. Deka Bank’s SWIAT ledger, used for live DLT repo transactions in the ECB trials, runs on Hyperledger Besu, a permissioned EVM chain. These are private systems. They still chose the EVM because it gave them mature contract standards and a deep talent pool.

According to the IMF’s 2026 fintech note on tokenized finance, the major new payment infrastructures, including Circle’s Arc, Stripe’s Tempo, and Coinbase’s Base, are all EVM-compatible, and even Swift’s planned blockchain infrastructure is being designed as EVM-compatible. 

Source: IMF Notes 2026/006

So we can safely say the standard is also where the wider market is converging. For a bank, this convergence changes the risk calculation. A tokenized deposit contract written for an EVM environment today can later connect to, or migrate toward, whatever infrastructure the market settles on. It does not create interoperability by itself, but it gives contracts and messages common technical assumptions.

For a contract written for a proprietary environment, it’s hard. 

There is a second reason. Regulators and auditors are building familiarity with EVM-based systems faster than with any other smart contract model, because that is where most institutional activity sits today. Hence choosing the EVM also shortens the review conversation.

EVM is therefore a standard for execution, not a decision to expose bank money to an unrestricted public network. The bank can keep the familiar application layer while choosing a more controlled infrastructure underneath it.

Why Choose a Bespoke Rollup Instead of Another Bank Blockchain Model? 

A rollup is a chain that executes transactions in its own environment, batches them, and posts the results to a settlement layer such as Ethereum. 

The IMF observes that banks have traditionally emphasized privacy, scalability, accountability, and predictable costs when evaluating ledger infrastructure. 

“…banks have traditionally favored and explored permissioned ledgers operated by themselves or by a consortium of known entities for their own purposes and clients. They have emphasized privacy, scalability, accountability, and predictable costs.”

IMF Notes 2026/006

Rollups bring all of that to banks. A bespoke chain means the bank or the consortium defines that environment and its rules. Banks buys control by choosing a custom layer2 rollup chain. 

Five things come with it.

1. Blockspace and cost. The chain carries only the bank’s traffic, so throughput and fees do not move because of unrelated activity elsewhere.

2. Throughput. It has to match payment-network volume. This requires higher transactions per second with fast finality.

3. Validator selection. The bank decides who runs the nodes and under what contractual and supervisory arrangements.

4. Rule placement. Compliance logic can sit at the protocol level, not only inside individual token contracts, so restrictions cannot be routed around.

5. Upgrade authority. Protocol changes follow the bank’s change-management process rather than an external governance vote.

Anchoring to a public settlement layer provides external verifiability of the chain’s state, a path to public liquidity when a use case requires it, and a security assumption that does not rest entirely on the bank’s own operations.

Where could it be the best alternatives to existing blockchain solutions?

Banks should choose a bespoke rollup when they’re joining a shared, multi-bank network run by an operator that isn’t already a global systemically important bank or a large pre-formed consortium. 

A single global bank running its own deposit token doesn’t need this. Its name is already the security. Take JPMC or Citi for example. A large coalition of major institutions co-governing a shared network doesn’t need it either, since trust comes from shared ownership among already-trusted parties. For example, SWIFT. 

What a bespoke rollup solves is the middle case: a neutral operator, or a smaller or regional bank without the scale to build or validate its own chain, that needs a way to get verifiable settlement without either building years of reputation or joining someone else’s consortium on someone else’s terms.

In this setup, transaction data and execution stay inside the operator’s private environment, visible only to the parties involved. But every batch of transactions produces a cryptographic proof, and that proof settles on a public chain that’s already been running securely for years. A bank doesn’t have to trust the operator’s internal controls. It can check the proof itself, or have its own risk and audit teams check it, independent of anything the operator says.

How Would a Tokenized Deposit Rollup Work?

Consider a corporate customer at Bank A paying a supplier at Bank B.

• The deposit is prepared for tokenization. Bank A authenticates the customer, runs its controls, and moves or earmarks funds in a designated deposit account. The integration layer instructs the token contract to mint the corresponding amount.

• The customer sends a payment instruction. The instruction comes through the bank’s portal, API, ERP, or treasury system. The wallet is linked to a verified customer record; the user does not need a public, self-custodied crypto wallet.

• Policy is checked before execution. Identity, sanctions, limits, available balance, and recipient eligibility are validated. The ordering service accepts approved transactions and places them in a deterministic sequence.

• The EVM contracts execute the token transfer. The deposit-token contract updates balances. Additional contracts can support escrow, conditional release, or delivery versus payment.

• The batch is proven and anchored. The rollup generates a proof or state commitment. A privacy-preserving design can publish verification material without publishing customer names, balances, or transaction details.

• Bank records and interbank obligations are completed. The integration bridge updates core systems, performs continuous reconciliation, and calculates the fiat obligation between Bank A and Bank B. That obligation is settled through the agreed settlement bank, RTGS connection, wholesale CBDC, or another legally recognized mechanism.

There are therefore two finality questions. The token transfer may be final on the rollup within seconds. The underlying interbank obligation becomes final only at the point defined by the scheme’s legal and settlement rules.

Architecture of a Rollup-Based Tokenized Deposit Network 

A bank rollup shares roughly half its stack with any other rollup. The other half does not exist in consumer designs. A production bank rollup is best understood as a stack of five layers. 

Application layer. The deposit token contracts themselves, with controlled mint and burn functions, transfer restrictions, pause and freeze capabilities for compliance events,  hooks for programmable payment logic, and the APIs through which clients and partner institutions actually use the network. 

Rollup operator layer. The execution environment itself, plus the sequencer that orders transactions, the prover that generates validity proofs, and the data availability arrangement that determines where transaction data is stored. 

The integration and orchestration layer. It translates on-chain events into message formats the bank’s systems already process, such as ISO 20022, so that deposit ledger balances update in step with token movements. It routes events between the chain, core banking, and custody infrastructure. It runs continuous reconciliation between on-chain balances and deposit records. Banks must be able to coordinate real-time on-chain updates with the settlement finality of existing systems and with conventional payment messaging standards, or clients lose reach into today’s payment networks. 

Settlement layer. A public chain, usually Ethereum, that receives proofs or batched data and provides external verifiability of the rollup’s state. 

The access and reporting layer provides segregated views by role. The operator sees network-wide flows, each bank sees its own customers’ activity and its settlement obligations, and supervisors receive a read-only audit view. This layer has no equivalent in a public rollup. 

For transfers within the same bank, the fiat rail only requires internal ledger adjustments. For transfers between banks, the token can settle immediately on the digital rail while an interbank fiat obligation is created. These obligations are accumulated and settled periodically—usually on a net basis.

Which Banks Are Already Building Deposit Rollups?

The clearest current example is the Cari Network, a consortium formed by five US regional banks including KeyBank, Huntington, First Horizon, M&T Bank, and Old National. 

It runs a permissioned Layer 2 ZK rollup anchored to Ethereum. Its architecture matches the pattern described above. Deposit tokens are issued under ERC-20. Every token is backed one-to-one by a balance in a designated deposit account at a participating bank. 

Source: Cari Network

Wallets are whitelisted and bound to KYC-verified customers. Transaction execution and data storage stay inside the network, with only validity proofs posted to Ethereum. Supervisors receive a dedicated read-only view. Net fiat obligations settle through a hub-and-spoke model administered by a settlement bank. 

Deposits represented by Cari tokens remain regulated liabilities on the banks’ balance sheets and stay covered by FDIC insurance. The network is backed by the Mid-Size Bank Coalition of America and has joined the American Bankers Association’s Premier Partner Network. The API layer covers issuance, transfer between verified parties, and redemption back into dollars. As of July 2026, the network had expanded past 30 participating banks, with around 40 more in active discussions, representing combined assets above $10 trillion. Production launch is targeted for later in 2026. 

Another Bank Projects as Useful Evidence

Deutsche Bank’s Project DAMA 2 uses a comparable architecture for a different purpose. Its architecture uses a privacy-enabled institutional ZK rollup on Ethereum with a permissioned sequencer for tokenized funds, stablecoins and other assets. It validates the same institutional logic: standard public infrastructure at the base, controlled execution above it, and a bank-friendly application layer.

Zeeve for Unbiased Consultation and Privacy-Enabled Rollup Infrastructure 

Zeeve provides institutional-grade blockchain infrastructure for launching and operating bespoke rollups, including privacy-enabled tokenized deposit infrastructure designed for regulated environments. Zeeve Tegaris, the modular privacy layer, provides system-wide privacy, including the transaction layer and entire workflow. 

The platform is ISO 27001 and SOC 2 Type II compliant, and supports Bring Your Own Cloud deployment so institutions can run rollup infrastructure within their own security and data-residency perimeter. For banks already running earlier-generation DLT platforms, Zeeve also supports migration from legacy blockchain infrastructure. 

Zeeve has helped a big US bank with their tokenization initiative. Talk to Zeeve’s team for an unbiased architecture review of your tokenized deposit program. 

“Cosmos Labs“, the company behind the Cosmos digital ledger and interoperability technology, has partnered with “Zeeve“, a privacy-enabled enterprise blockchain infrastructure platform. Together, the companies will help financial institutions bring tokenized deposits and digital assets into production.

Through the partnership, Zeeve will offer solutions built on the Cosmos stack to its enterprise customers. Cosmos will provide the ledger and token issuance technology, while Zeeve will handle deployment, migration, production architecture, and ongoing operations.

Zeeve’s services include fully managed networks, dedicated node and validator operations, 24/7 monitoring, and system-wide privacy through the Zeeve Privacy Layer.

The Cosmos stack has been running in production since 2019 and now powers more than 150 independent blockchains. It supports over 10,000 transactions per second, sub-second transactions, and native interoperability between networks. This gives financial institutions a tested foundation for issuing tokenized deposits and digital assets.

Zeeve brings the operational capabilities needed to run that technology in regulated environments. The company is ISO 27001 and SOC 2 Type II compliant and offers enterprise SLAs, 99.99 percent uptime guarantees, and privacy across both transactions and application workflows.

“Zeeve brings the operational expertise that enterprise customers need to deploy blockchain infrastructure with confidence, Institutions get a robust DLT solution that uses the Cosmos ledger and tokenization stack and Zeeve’s proven engineering and operations capabilities.”

– Barry Plunkett, Co-CEO of Cosmos Labs.

“Enterprises want blockchain infrastructure that’s proven in production and a partner who can get them there without operational risk,Cosmos gives our customers the technology foundation they need, and Zeeve brings the deployment and operations expertise to put it to work.”

– Dr. Ravi Chamria, co-founder and CEO of Zeeve.

Together, Cosmos Labs and Zeeve give a complete path from blockchain planning to production. The partnership will make it easier for financial institutions to launch and operate tokenized assets, digital deposits, payments, and other digital ledger initiatives at scale.

For more information, visit Zeeve.

About Cosmos Labs

Cosmos Labs is the company behind Cosmos, a digital ledger technology stack that powers more than 150 blockchains across finance, payments, and global business. The Cosmos stack enables institutions and governments to build sovereign and interoperable blockchain networks and applications.

Cosmos Labs is a wholly owned subsidiary of the Interchain Foundation, the nonprofit organization that supports Cosmos and its decentralized technologies.

To learn more, follow “@cosmos on X” or visit “cosmos.network“.

About Zeeve

Zeeve provides privacy-enabled enterprise blockchain infrastructure for production-grade digital asset deployments. The company helps banks, fintechs, and other institutions launch and operate blockchain systems for tokenization, stablecoins, tokenized deposits, payments, and settlement.

Built for regulated environments, Zeeve is SOC 2 Type II and ISO 27001 compliant. Its infrastructure supports more than 25 production blockchain networks that process over two billion transactions each month.

To learn more, visit Zeeve.

In this article, we shall see how bank’s market share in global payments is threatened by emerging technologies like stablecoins, the challenges they face to compete with them  and the solution that blockchain can provide to banks  in this regard to resolve their existing issues; 

According to the IMF’s January 2025 report, banks have become the most expensive gateway for cross-border payments. With cross-border spending projected to reach $320 trillion by 2032, banks face existential pressure to innovate or lose market share.

The threat is real. Approximately $27 trillion remains trapped in correspondent banking accounts, creating a $1.22 trillion annual “liquidity tax.” Meanwhile, stablecoins moved $27 trillion in 2025 with 733% B2B payment growth, and Ripple secured 75+ global licenses in February 2026.

This article examines how stablecoins threaten banks’ market share, the structural challenges banks face, and how blockchain provides solutions.

Stablecoins: The Bullet Hard To Dodge For Banks To Dominate the Cross-Border Payments 

At the moment, more than 40% of the banks  are in the position to lose 5% of the market share to next gen payment advancements like stablecoins.  And this trend has already started in the US and the UK, where stablecoins  have already occupied  1% of the total remittance and moved  $27 T in value because they not only streamline faster cross border transfer but also help in  bearing yields while holding such tokens .  In the near future, it is expected that if banks fail to generate real-time impact like; 

• Near Instant Settlements 

• Less than $0.1  charges  for every cross border transaction undertaken

• Borderless, Minimal and non existent FX fees 

• Fully digital, smart-contract enabled programmability 

• Cryptographic security

• Fully transparent transaction reporting. 

• Full operationality  24*7 and 365 days in a year. 

They could risk losing the market in cross border remittance until and unless  they innovate to cover the  $250 Trillion remittance target set for  the next 5 years. But for banks to achieve that, they need to overcome the barriers that they face in the present while providing the remittance services for cross border payments; 

What are the Challenges Banks Face To Deliver Next Gen Innovation in cross-border payments? 

1. Transparency

The Remittance Transfer Rule which is predominantly known as US CFPB and India’s LRS  (RTR)  compels banks to provide the following details to the customers like: (i) clear and accurate fee disclosure (ii) data of delivery of funds (iii)  rights to error resolution and disputes (iv) cancellation and refund rights and (v) compliance monitoring for absolute transparency. 

But due to banks using SWIFT systems for transfers, it is very hard to easily track conversion fees or any other hidden charges that an intermediary banking network can impose while the funds are moving from one location to another. This transparency issue has caused a major trouble for banks because out of $17.9 billion in fees paid for remittance, $5.8 B goes into hidden charges. 

And in case, the banks are not able to provide justification for such charges due their transparency hurdles, they can be fined under the Consumer Financial Protection Bureau (CFPB) law under Regulation E in the US. An example for the same is  Bank of America facing a   $21 M in settlements due to their inability to provide complete transparency of charges to customers. 

2. Regulatory Pressure 

Regulatory frictions while sending money through banks becomes another major hurdle while undertaking cross border transfers because of: (i)   different levels of development of the financial market, (ii) lack of a global regulatory perspective, (iii) non collaboration with regulatory bodies  operating from different  jurisdictions and (iv) lack of public-private partnership among the financial players, pushing them into the dark world of fines and penalties. 

As a result, to prevent penalties and other subsequent charges for non-compliance, every year banks are spending  $206 B  annually setting up manual systems for checking AML/ CFT transactions. And there’s no end to this resulting in remitters having to bear the burden of compliance by seeing their  remittance value in cross border transfers diminishing under the cost pressure put on them especially for low value transfers undertaken under travel, payroll, remittance. 

3. High fees 

The global remittance in 2023 was hovering at around $656 B  and it is expected to reach $900 B by 2025. Though the market size of global remittance has increased significantly but not adequate work has been done to minimize the cost of sending the money. For example, the SDG target proposed by G-20 and G-8 nations was to limit the cost of sending foreign remittance via banks using the SWIFT system to 3%, but at this moment, they are nowhere close to their targets. 

As a result of this, remitters are looking for better options in the form of MTOs or Money Transfer Operators, who are not just providing faster single day settlements but even charging way less than their counterparts like banks.

How Can Blockchains Help In Providing Next-Gen Cross-Border Payment Innovation To Banks?

Fortifying  Provenance for Optimum Transparency 

Provenance or trail identification is not possible in a traditional banking infrastructure but blockchain can help trace movements due to its standardization and use of universal distributed ledger systems.  As a result, now it is possible to quickly flag scrupulous  fund movement or track inefficient transactions  moving across borders. 

Santander, a global retail bank operating in Spain, Brazil, Poland and the UK  has partnered with  the  RippleNet Infrastructure to launch One Pay FX, a platform that aims to streamline a smooth and efficient cross border transfer by providing provenance of the fund movement at every checkpoint.  Due to the One Pay FX platform, it is now possible to experience fast transfers, transparency on cost and rates and zero commissions for selective transactions. 

Sandboxing Compliance 

Banks can overcome the regulatory hurdles if they can make cross border payments easily interoperable, strengthen the regulatory collaboration across various stakeholders and build complementary public private partnerships among the financial services involved in streamlining cross border transactions. Blockchains help here because it can allow role based access and eliminate repetitive tasks which significantly inflate the regulatory compliance cost and automate adoption of new regulatory measures in the banking models to eliminate instances of fines and penalties. 

GoldMan Sachs has introduced the GS Digital Asset Platform (DAP)  to help banks fulfill the regulatory requirements.  Using the GS DAP, banks can not just  sandbox compliance but also let different players in the remittance market collaborate and operate with role based control and automate tracking and implementation of new regulations in their modus operandi. As a result, banks are now not  bound to choose between compliance, privacy, and control of permissioned ledger and automation  while operating on a public blockchain for trust and accountability to  optimize operations. 

Mathew McDermott, Managing Director & Global Head of Digital Assets, Goldman Sachs says, “Our goal from the outset has been to help our clients realize the benefits of end-to-end digital lifecycle processing across tokenized assets, digital currencies, and other financial instruments. We are pleased to bring this Daml-based solution to market and continue to find efficiencies that will improve the velocity of transactions.”

Optimizing Cost 

To optimize the cost of remittance, banks need the infrastructure that can help them overcome intermediary bank fees, settlement times, currency exchange fees.  But doing that would demand an infrastructure readily functional  to solve the interop challenges which the SWIFT system isn’t ready for. 

Blockchains provide a considerable advantage using a decentralized ledger network.  For example, Ripple has partnered with more than   300+ banks  allowing them to use its ODL or On-demand Liquidity Solution. Due to this, banks can  instantly  synchronize communication with all the partner networks using a decentralized ledger technology, or Ripple Net which not only passes messages but even moves value. 

Hence  streamlining   debits, credits and liquidity for banks which they couldn’t do using SWIFT previously in a fast and economical way. So far the Ripple Network has significantly cut down the cost and time-to-settlement using its ODL Network for cross-border payments.

It is expected that the global cross border spending will reach $320 T in the next 7 years. Keeping this trend in mind, now banks have more reasons to adopt innovative solutions and embrace the change  or risk being  left behind sticking to legacy rails. Blockchains end up as an amenable solution because they can easily blend with the  new ISO 20022 standards for banking streamlining interoperability and value transfer. 

Because, at this moment, the  ISO 20022 standards can only pass on the message and not the value; thereby still creating a never ending loop of Time-to -Settlement. So, if you want to build anything around the same or want to introduce new use-cases in banking wherein blockchain will have a role to play, Zeeve can help you. 

Pilot Your Banking Use-Cases Around Blockchain With Zeeve

For any of your banking use-cases that you are planning to launch on top of blockchain, compliance will be the most important aspect to avoid business disruption. Zeeve as an ISO 27001, SOC 2 Type II, and GDPR compliant platform makes sure that whatever product that you intend to launch around banking to streamline smooth cross border transactions, we are here to help you in undertaking everything from pilot to implementation to launch. 

With more than 40+ enterprises scattered across regulated and high scale environments, we can provide everything that you are looking for. Schedule a call with us today if you want to integrate blockchain in your existing banking stack for improvisation and better outcomes. 

That trust is eroding. A European Commission study found that 53% of environmental claims examined were vague, misleading or unfounded, while 40% were entirely unsubstantiated. With approximately 230 different environmental labels circulating across EU markets, consumers face a confusing choice where distinguishing genuine sustainability from marketing claims has become nearly impossible.

Meanwhile, consumers are increasingly mindful of what they buy. According to PwC's 2024 Voice of the Consumer Survey, which surveyed over 20,000 consumers across 31 countries, 85% report experiencing the disruptive effects of climate change in their daily lives, and they're willing to pay a 9.7% premium for sustainably produced goods.

But this willingness comes with a demand: verifiable proof.

The gap between consumer demand for verified sustainability and the prevalence of unsubstantiated claims is a trust crisis that threatens the credibility of the entire green economy. Digital Product Passports (DPPs) built on a blockchain technology stack could play a major role in solving this.

Digital Product Passports: Hard-Coding Circularity Into Markets

The European Union has moved decisively to address this trust deficit through the Ecodesign for Sustainable Products Regulation (ESPR), which introduces DPPs for virtually all physical goods placed on the EU market.

A DPP is a structured digital record that contains detailed lifecycle data, material composition, manufacturing origin, carbon footprint, recycling instructions and compliance certifications, accessible via standardized interfaces such as QR codes or NFC tags.

From February 2027, every electric vehicle and industrial battery with a capacity over 2 kWh sold in the EU must include a battery passport accessible via a QR code that contains information on carbon footprint, electrochemical performance, and durability. Textiles, electronics, furniture and construction materials are expected to follow between 2027 and 2030.

The regulation's Brussels Effect means global manufacturers must comply regardless of where they're headquartered. No major company can afford to bypass the European market, as it impacts both exports and imports.

In February 2024, the EU further strengthened its position by revising its blacklist of unfair commercial practices to explicitly prohibit misleading green claims, including generic terms such as "eco-friendly" or "climate neutral" unless backed by recognized certifications. Non-compliant companies face penalties of 4% of annual revenue.

How Blockchain Impacts DPPs

What distinguishes DPPs from previous labeling frameworks is the requirement for tamper-proof, interoperable records that survive product lifecycles spanning decades and multiple ownership transfers. This requirement inherently favors decentralized, immutable infrastructure, which makes blockchain a structural necessity.

The fundamental challenge with sustainability claims is verification. Traditional centralized databases allow retroactive modification: a manufacturer that hosts its own sustainability data can quietly alter records if compliance issues arise in supply chains where entities often compete and may not trust each other.

In such cases, a neutral, shared ledger becomes essential.

Toyota, for example, publicly described its Toyota Blockchain Lab initiatives, which include supply-chain use cases aimed at improving efficiency and traceability by recording and sharing information about parts manufacturing and shipping.

The Aura Blockchain Consortium—founded by LVMH, Prada, Cartier and OTB—announced in September 2024 that it had surpassed 50 million luxury products registered on its blockchain. Louis Vuitton now offers traceability for its LV Diamonds collection, tracking each stone's journey from mine to final setting.

In short, blockchain can address the core issues of traceability and trust through cryptographic immutability. Once product provenance data is recorded, altering it requires computational resources exceeding the combined computational resources of the network securing the chain. A product's manufacturing date, material composition and chain of custody become verifiable facts resistant to manipulation.

Smart contracts, which are self-executing code on blockchains, enable automated verification without human intermediaries. When a product changes hands, smart contracts can automatically verify authenticity against on-chain records, execute warranty transfers and trigger compliance checks based on predetermined criteria.

Creating A Phased DPP Strategy

If you place products on the EU market, you’re the economic operator responsible for ensuring a compliant passport exists at market entry.

The starting point is understanding the regulations and enforceable timelines. The good news is that we're talking mostly about existing data. The task is not building new data from scratch but standardizing and connecting data sets already sitting in your ERP, PLM systems and supplier records.

The logical next step is a gap analysis. Map ESPR-mandated data categories against your current systems. For each data point, determine: Do we have it? Where does it reside? Who owns its accuracy? Some data will come from your bill of materials and bill of processes. Some will require Life Cycle Assessment inputs from upstream suppliers.

Many suppliers will be hesitant to share proprietary information, so businesses need to begin supplier conversations early. Have data-sharing agreements that specify formats, update frequencies and verification protocols. For proprietary data protection, zero-knowledge proofs can be used. Sensitive information can be encrypted so that only authorized parties can access it upon verified request.

Once the data framework is defined, the technology layer becomes clearer. Barcodes, QR codes, RFID tags or NFC chips can make the passport accessible from the physical product. Blockchain’s role begins one layer below. It provides a tamper-evident trust anchor for key lifecycle attestations. You don’t have to replace ERP systems; you can have them publish verifiable updates into a shared integrity layer via middleware and APIs.

This level of integration is complex, so you may want to work with a partner familiar with supply chain complexities and strict regulatory compliance requirements. Either way, you will need a direct thread of data that links a raw material to a finished good. You will also need to ensure that the digital twin is compliant with the ESPR interoperability standards.

Conclusion

For businesses, the question is no longer whether to invest in traceability infrastructure, but how quickly they can build the systems to substantiate their claims. In a marketplace flooded with unsubstantiated green claims, the ability to provide cryptographic proof of sustainability is becoming a regulatory requirement as much as a competitive advantage.

Reimagining BFSI with Blockchain in the 21st Century

The banking, financial and insurance sector has been yearning for an innovation which blockchain has delivered by making way for the following use-cases to change the world in respective segments;

1. In Banking

Decentralized Reserve Currencies

Crisis situations have brought back the narrative that in times of uncertainty, you need a better way to prepare against the odds which might come in many forms from financial turmoils to sanctions or change in diplomatic equations. In such times, you need better ways to circumvent the odds when existing financial systems fail to deliver.

For example, during the Ukraine-Russia war, many Russian oligarch accounts were frozen because of sanctions. As a result, central banks across the globe are looking for an asset class that can bypass uncertainties and provide the perfect case to command control and challenge hegemonic rise.

Though gold is a good option to choose, but Bitcoin(BTC) wins here because whether it is about surviving financial sanctions or withstanding economic crises like bank runs, BTC has always performed better in all these situations as evident from the chart below.

As you can see, despite the SVB Bank Failure, BTC still continued an upward trend not just in 2023 but even at the time of pandemic in 2020 because of its structural engineering . Such records during crises have put the case for BTC to be used as a reserve currency, not just to hedge against inflation, economic risks and more, but also to protect the sovereignty of the country.

At the moment, there are three nations which have vehemently considered BTC as a reserve currency: the US, El Salvador and Czech Republic. The US has passed an executive order under the Trump administration to acquire more than 198,000 BTC, which shall act like a strategic reserve. Likewise, El Salvador and Czech Republic are using BTC to introduce tokenized finance in their economy for modernization and to boost economic inclusion.

Modernizing Foreign Remittance

Remitting payments through banks has ended up as widely expensive for users in 2025. For example, in comparison to MTO or Money Transfer Operators, the banks are charging 12.5%,whereas, MTOs are charging only 5.5%. And banks are compelled to do the same because of an imminent pressure to charge overhead, flat fees, intermediaries, and weak exchange rates. Due to this, banks are losing the battle with the MTO as evident from the chart below.

But blockchains can change the game for banks. For example, Santander, a major multinational Spanish Bank has partnered with Ripple Net. At the moment, after the integration of Ripple to launch One Pay FX, Santander has almost captured the Spain, UK, Brazil, and Poland market capturing 50% of international payments using stablecoins.

So far, not just Santander but other players in banking like Amina and more than 300+ are using Ripple because it has provided low cost, fast settlement and compliant options to banking institutions to challenge the rise of MTOs that are eating up the remittance share of the banking sector.

1. In Financial Services

Tokenizing Assets Under Management

Despite the AUM market reaching $147 trillion by June 2025, if someone says that it is going through a profitability pressure, it would ideally be surprising. But this is undoubtedly true as per Mackinsey report which says that AUM firms, which are using legacy systems, could only meet with periodic reporting, simpler regulatory guidelines (inability to do KYC, AML ) due to technological bottlenecks.

As a result, they are able to recover only 1/3rd of the profits, while the remaining 2/3rd of every revenue dollar has been absorbed by operational expenses to meet various regulatory and other operational challenges as per Mackinsey report.

But the scenario can significantly change upon using digital interfaces, multi-jurisdictional compliance ready infrastructure, richer data management, and enhanced cyber security measures to build trust.

JP Morgan, by using blockchain technology, is on the way to achieve this. So far, JP Morgan, by using blockchain technology, has been able to launch the tokenized money market fund with a $100 M listing initially in a matter of few months and by undertaking optimal investment to launch the same.

John Donohue, Head of Global Liquidity at J.P. Morgan Asset Management said: “Tokenization can fundamentally change the speed and efficiency of transactions, adding new capabilities to traditional products”. He added, “There is a massive amount of interest from clients around tokenization… [and] we have a product lineup that allows them to have the choices that we have in traditional money-market funds on blockchain”. Due to tokenization on blockchain, now these funds can easily enter restricted areas by adhering to all the compliance hurdles using technology as an underlying layer to mitigate the same

So far, not just JP Morgan, but some of its close counterparts, like Franklin Templeton have also used blockchain to enter and penetrate new markets using tokenization through the Benji Token. They are able to attract retail and institutions through this initiative. And presently, its FOBOXX fund has just entered the Asian market by making inroads in the Hong Kong region.

Trade Finance Optimization

Every year global trade is shrinking by a whopping $2.5 T because there’s no availability of technology in place to establish a mature business model to mitigate the challenges involved. For example, imagine trade happening between two parties located in two different locations with different jurisdictional limitations and regulatory challenges, there’s always a default risk involved in such a case.

Why so? Because, it is very hard to establish an enforceable contract to determine the risk sharing. One such incident occurred to demonstrate the same when an Istanbul based producer of textile exported knitted dresses to an importer in Italy, but the freight carrier didn’t adhere to the contract rules and delivered the goods to the importer before the payment.

Upon receiving the consignment, the importer refused to pay up because they claimed that the goods received were not in accordance with the requirements. In the absence of following problems like: (i) proper risk models, (ii) manual processing, (iii) legal misalignment, (iv) fragmented regulations, (v) siloed digital platforms and (vi) poor interoperability, it was very hard to prove who was at fault.

And this is not just a single incident but due to such events, as per reports, out of 80% of trade accomplished annually worldwide, 1% of the trade finance, which equals $2.5T figures remains doubtful . And out of that 1%, there’s a certainty that $50 billion in losses due to such frauds where either of the parties involved defaults due to complex paperwork or regional disparities and inability to enforce accountability.

Blockchains are fixing these problems and so far they have made considerable contributions. For example, Hong Kong-based MTC Electronic Co Limited (MTC) exported shipments of raw materials to its Shenzhen Based Partner by using Voltron, a shared blockchain platform co-founded by 8 member banks.

The process was completed in a matter of a few hours instead of 7 to 10 days with complete accountability. So far, using the Voltron, now called Contour, HSBC has facilitated Trade Finance amounting to $857 B to remain as the top banks using blockchain technology for trade financing and settlements. Other than HSBC, there other players as well like Standard Chartered, DBS, and Citi, MUFG, Crédit Agricole, Lloyds, and ABN Amro which are also a part of the Contour, a financial service initiative using blockchain to speed up payment settlements in a compliant and accountable manner.

1. In Insurance

Strengthening Farm Insurance

Farmers are the most vulnerable section of the society when it comes to availing insurance protection. For example, India, despite being an agriculture driven economy, only 30% of the farmers are insured. And these numbers are so low because of a few reasons (i) high premium of insurance (ii) extended time for claim settlements ( 5 months to 12 months). For example, at the time of writing, more than 5,405 crore of unpaid crop-insurance claims are still pending because of delayed relay of data required to process the same. And this problem is not only present in India alone, but it transcends beyond to other regions like Africa, where the farmers experience the same problems.

But blockchain solutions have provided a way out to not just expedite the claim process but even make the insurance protection affordable for the farmers in the agriculture sector. Lemonade Crypto Coalition, is a subtle example to quote here who are using Area Yield Index mechanism powered by blockchains to make insurance protection affordable and accessible.

In the Area Yield Index, specific territorial regions are marked on top of blockchain to estimate claim premiums and settlement scenarios. Subsequently, a claim is determined and farmers can form parcels to subscribe to the insurance. Upon identification of any unforeseen event or crop failure due to natural calamities, all the farmers are compensated nearly instantly without any failure. So far, under the Lemonade Crypto Climate Coalition, more than 7000 farmers have benefitted when it comes to receiving instant support during crop failures.

Bolstering Fraud Detection

Frauds have ended up as a major problem for the insurance service providers eating up their thin margins of 3% to 5% . For the record, every year the insurance industry in the US loses $308.6 billion or $932.63/ person to fraudulent claims. And this is happening primarily because of the use of AI systems to create fake bills and claim insurance in the process. And these are the sectors who are at the highest risk of frauds

As you can see in the above image, it is very hard for the operations, cyber & speciality lines, life & health sectors to easily identify the frauds in the insurance. But blockchains are making a world of difference. For example, RiskStream has been using blockchain technology to go past the traditional ways to mask and anonymize the data. In its stead, Risk Stream creates active data banks that are accessible by all network participants to detect frauds and prevent claims from happening.

Zeeve for BFSI Implementation

If you are facing any problems in the BFSI segment and you want an innovative way to overcome the issue, Zeeve, as an enterprise grade neutral blockchain platform can help you. We very well understand that compliance is of utmost importance to the BFSI segment and for that matter, we provide an ISO 27001, SOC 2 Type II, and GDPR compliant platform.

Due to this, whatever solution that you intend to implement for the BFSI sector to solve some of its innate problems would remain compliant and operational across different geographical regions. With more than 40+ integration partners, you can easily integrate anything as per your requirements. So, why wait? Our experts are here to help you understand where we can fit into your existing technology stack and modernise the same from the grounds up to meet incoming challenges.

Entry’s Avalanche L1 testnet is now live, and it’s the architectural solution to DeFi’s institutional problem. Built as a compliance-first protocol, Entry embeds regulatory logic into its core, turning legal requirements into programmable, automated, and privacy-preserving functions. Deployed and managed by Zeeve, this is the first live infrastructure where institutions can access DeFi yields and tokenized assets with cryptographic certainty and full regulatory alignment.

Entry’s Programmable Compliance is the Engine for Institutional DeFi

Entry redesigns the entire stack from scratch and makes compliance an asset. It introduces a protocol-agnostic compliance layer that bridges decentralized ecosystems with institutional needs through two core innovations:

• Zero-Knowledge Identity (zkID): This is the key to solve the privacy paradox. zkID allows institutions and users to prove their credentials like, KYC, jurisdiction, etc. without revealing any underlying personal data. It’s verifiable compliance without surveillance, and satisfy both regulators and users.

• The Regulation LLM: Entry use Zekret Labs’s AI-powered compliance engine acts as an interpretive layer trained on global frameworks like MiCA and FATF. It automates asset screening, transaction monitoring, and provides “explainable compliance,” ensuring every action is auditable and understandable to regulators.

Entry brings a new operating system for regulated finance, designed to cut compliance overhead by up to 60% and accelerate the launch of compliant tokenized assets.

“For too long, DeFi and TradFi have spoken different languages. Entry is the universal translator. We’re architecting a new financial operating system where privacy and compliance are native features. Our Avalanche L1 is the proving ground for this new era.”

— Rodney Prescott, CEO of Entry

Why a Sovereign Avalanche L1 is Non-Negotiable?

To build an infrastructure capable of handling institutional-grade finance, a shared, generic blockchain is a non-starter. The environment must be controlled, performant, and purpose-built. Entry’s choice of a sovereign Avalanche L1 was a strategic necessity.

This architecture provides:

• A Dedicated Economic Zone: Entry operates its own sovereign network, with full control over its validator set, gas fees (paid in its native token), and on-chain governance. This allows them to embed compliance rules at the consensus level.

• Capital Markets Speed: With sub-second finality, transactions are settled instantly. This raw throughput is essential for the high-frequency nature of financial markets and eliminates the risk of network congestion impacting critical operations.

• EVM-Native Interoperability: By remaining EVM-compatible, Entry ensures that trillions of dollars in existing assets and thousands of developers can seamlessly integrate with its compliance infrastructure.

Zeeve Provided that Utility-Grade Infrastructure for a Trillion-Dollar Chain

When the stakes are this high, infrastructure cannot be a variable—it must be a utility. Entry required a partner capable of deploying and managing a zero-failure network. Zeeve provided the enterprise-grade foundation for Entry’s Avalanche L1.

Zeeve’s role ensures institutional-grade reliability:

• End-to-End L1 Deployment: Zeeve managed the entire deployment and optimization of the Avalanche L1 stack, tailored for mission-critical financial operations.

• Hardened Security & Monitoring: The network is under 24/7 automated monitoring with enterprise-grade SLAs, providing the resilience and uptime demanded by financial institutions.

• Transparent Auditing: With dedicated RPC endpoints and the integrated TraceHawk block explorer, Zeeve provides the deep on-chain visibility and transparency required for regulatory audits and partner due diligence.

An infrastructure designed to secure trillions in institutional assets cannot run on ‘good enough.’ It demands absolute reliability. We engineered every component of Entry’s L1 for the data integrity, security, and uptime needed to power a new financial paradigm. This is the mission-critical infrastructure Zeeve was built to deliver

— Dr. Ravi Chamria, Co-founder & CEO, Zeeve

Entry testnet launch is a signal that the firewall between TradFi and DeFi is finally being dismantled. It provides the blueprint for a new generation of vertical-specific chains that solve real-world industry problems at scale. The future of every major industry will be built on its own sovereign, purpose-built blockchain.

If you’re ready to build yours, you need an infrastructure partner who has already done it.

The project has seen solid traction. The team has raised over 96M and was backed by major VCs like Paradigm, Polychain, Galaxy, Hack VC, Hashkey, and IOSG. They saw incredible demand, with nearly $7 billion in Bitcoin already staked on the protocol. Nearly 19% of floating $BABY supply is also staked.

This guide is designed to help you seize that opportunity. We’ll show you how to stake and delegate your $BABY tokens with Zeeve’s enterprise-grade validator and become a part of Babylon’s success story.

Let’s get started.

If you want a refresher on Babylon and $BABY token, read it here:

https://www.zeeve.io/blog/babylon-staking-explained-earn-baby-staking-rewards-with-zeeve-validator/

Why Stake $BABY with the Zeeve-run Babylon Validator?

Choosing a reliable validator is the most important decision you’ll make as a delegator. Zeeve is an active, institutional-grade validator node infrastructure provider with a proven track record of deploying over 6000+ nodes across 40+ protocols.

Here are some more reasons why delegators choose Zeeve:

• Lowest Commission, Higher Rewards: Zeeve charges only a 3% commission, one of the lowest among active validators. This means a larger share of the staking rewards goes directly to you.

• 99.95% Proven Uptime: Our enterprise-grade infrastructure, backed by strict SLAs, has multi-cloud, multi-region deployments with auto-failover to ensure consistent rewards and minimize any risk of missed blocks.

• Audited Security and Compliance: As a SOC 2 Type II and ISO 27001 certified provider, our infrastructure meets the highest global standards for security and data protection.

• Fully Non-Custodial: The asset owner always maintains full control and custody of their assets. Zeeve never accesses your private keys.

Before You Begin, Here are Some Prerequisites

Before you start the delegation process, let’s make sure you have everything needed for a successful BABY delegation.

1. Install Keplr Wallet: As the premier wallet for the Cosmos ecosystem, Keplr is our tool of choice. If you haven’t already, install the Keplr browser extension/ mobile app and create your wallet.

2. Buy $BABY Tokens: You’ll need some $BABY tokens in your Keplr wallet. If you’re doing it for the 1st time, the next section covers how you can do it.

3. Keep Gas Fee: Please keep a tiny fraction of $BABY (e.g., 0.01 BABY) in your wallet. This will cover the small network fees required to process transactions.

How to Buy $BABY Tokens?

If you don’t have $BABY tokens yet, you can get it through a Centralized Exchange (CEX) or a Decentralized Exchange (DEX).

Using a Centralized Exchange like Binance, BYBIT, OKX, or Kraken:

1. Create and Verify Your Account: Sign up on an exchange like Binance, Bybit, Gate, OKX, Kraken, and complete the necessary verification steps.

2. Deposit Funds: Fund your account using fiat currency or by transferring another crypto.

3. Purchase $BABY: Navigate to the spot market, search for the BABY trading pair (e.g., BABY/USDT, BABY/USDC, or BABY/USD), and place your buy order.

4. Withdraw to Keplr: Once purchased, go to your wallet on the exchange, select “Withdraw,” choose BABY, and transfer the tokens to your Babylon wallet address from Keplr.

Using a Decentralized Exchange like Osmosis:

• Navigate to Osmosis: Go to the https://app.osmosis.zone/

• Connect Your Keplr Wallet: Connect the Keplr wallet that holds the assets you want to swap or you have USDC/USDT to buy.

• Buy Tokens: Select USDC/USDT, whichever you hold, and enter the amount to see how many BABY you will receive and the fees for the transaction.

• Swap Tokens: Click on the Swap icon if you hold other assets, for example, BTC, and want to swap with BABY at very minimal fees.

• Approve the Transaction: Enter the amount, execute the swap or buy transaction, and approve the transaction in your Keplr wallet.

• Ready to Use: Once the process is complete, the total number of BABY available should be visible in your wallet. Now it can be staked.

Delegating Your $BABY with Zeeve: A Simple, Secure Process

Now let’s get into the main task. Zeeve has designed the delegation flow to be as seamless as possible. Here’s how you can put your tokens to work in just a few clicks and in just a matter of minutes.

Step 1: Begin at the Zeeve Staking Portal: Your journey starts on the Zeeve delegation page. Once there, you’ll see a prominent “Stake Now” button. Go ahead and click it.

Step 2: Choose Babylon: Once you have clicked on ‘Stake Now’, you’ll be presented with a list of top-tier PoS networks where Zeeve is currently accepting delegation.

Find the Babylon logo and click “Stake Now” to continue. This link provides direct access to our validator interface.

Step 3: Connect and Review: Your Keplr wallet will now ask for permission to connect. Once you approve it, a dashboard will appear showing the vital stats for Zeeve’s validator.

You’ll see our highly competitive 3% commission rate and the current 19.22% Annual Percentage Return (APR) for BABY staking and unbonding period, which is around 50H.

Take a moment to review, then click “Stake.”

Step 4: Specify Your Delegation Amount: A new field will appear where you can enter the amount of $BABY you wish to delegate to Zeeve-run Babylon validator node. Type in your desired amount and click the “Stake” button.

Here, we would be entering 100 tokens for this tutorial and then just click on ‘Stake’.

Step 5: Give Your Final Approval: Keplr will pop up one last time to show you a summary of the transaction. Give it a final check and click “Approve.”

You will see, the transaction will be processed and successfully executed as well instantly. Your delegation is now on its way to the Babylon network.

Step 6: Confirmation: Now we can head over to the Explorer. There, after refreshing it, you can see that our wrap delegation is already executed. But you won’t be able to see this delegation onto the validator itself right then, since it only occurs or only comes in after an epoch has passed through. And one epoch usually takes around one hour. So after an hour max, you will be able to see your delegation on the Zeeve’s validator node.

And that’s it! You’ve successfully delegated your $BABY. Your stake will become active and start earning rewards once the current network epoch concludes.

Ready to stake?

Use the “Stake Now” button from our delegation page, select the protocol, connect Keplr, enter the amount, and approve—done.

https://www.zeeve.io/delegation-service/

FAQs:

• Is staking with Zeeve non-custodial?

Yes. You retain full control of your assets and keys at all times. Delegation is done directly from your personal Keplr wallet.

• What is the unbonding period for $BABY tokens?

The unbonding period is approximately ~50 Hours / 2 days (around 300 Bitcoin blocks). During this time, your tokens are locked before they become liquid again.

• Is there a minimum staking amount with Zeeve?

No. While running your own validator requires a significant stake, there is no minimum amount required to delegate your $BABY tokens to Zeeve.

• How are my staking rewards calculated?

Rewards are calculated based on the Babylon protocol’s inflation rate and validator’s performance (uptime) and commission. Zeeve’s high uptime and low 3% commission are designed to maximize your share of the rewards. The current APR is approximately 19.22%.

• How often can I claim my rewards?

Rewards accrue with every block. You can claim them at any time through the Keplr dashboard, though it’s often more gas-efficient to let them accumulate before claiming.

• Can I compound rewards?

Yes. Claim then delegate again. Remember to leave a fraction for fees.

• What are the risks of staking?

All PoS networks have a slashing risk, where a validator can be penalized for significant downtime or malicious actions. Zeeve mitigates this risk with a robust, redundant infrastructure and 24/7 monitoring by SRE experts.

Due to this, institutions are now looking for alternatives to maximize their yields.  In this regard, crypto staking has ended up as an amenable option because almost all major protocols have surpassed what traditional investment vehicles are generating at the moment.

But crypto staking is not as simple as you might be thinking because you have to run nodes to validate the chain to gain returns. For that matter, you need an infrastructure supporting your pursuit. In this blog, we shall deep dive into understanding Staking-as-a-Service, how it works, and why it is trending in 2025. So, without any further ado, let’s get started.

What is Staking-as-a-Service (StaaS)?

Staking-as-a-Service allows crypto holders to delegate tokens to professional node operators without running the whole infrastructure themselves. In traditional staking, an individual locks up their holding to participate in network validation.

This helps the blockchain in maintaining its network security. In return, the holders are given staking rewards. However, to participate in the validation process, holders must set up infrastructure that enables them to run validator nodes. This process can be challenging for many individuals, and the setup costs are also high. This is where StaaS comes to the rescue.

In the StaaS model, a service provider handles all the technical and hardware requirements on your behalf. This includes the complex validator setup and the required maintenance activities. You simply lock your tokens through a web interface or API, and the StaaS provider stakes them into the network. In return, you earn a share of the block rewards, just as if you ran your own validator. That being said, let’s understand how this process works.

How Staking-as-a-Service Works?

Select a StaaS provider: The process begins by choosing a trusted StaaS provider that has the necessary infrastructure to handle the complex requirements.

Delegate tokens: Next, you delegate the desired amount of your tokens to the provider by connecting your wallet. Importantly, the custody of your keys lies with you. This is because the service only requires a validator key and not a withdrawal authority.

Validation: The provider then runs enterprise-level nodes to participate in the network validation of the blockchain. A great Staking-as-a-Service provider constantly monitors the performance of the infrastructure and manages upgrades in real time. They make sure that the node remains online to prevent downtime and any slashing penalties.

Earn rewards: As the blockchain generates new blocks, your delegated stake earns a pro rata share of the block rewards or transaction fees. The StaaS provider keeps back a percentage of the rewards as commission, and you get the majority in your account. These rewards accumulate in your staking account and can be seen in real-time on a dashboard.

Compound staking growth: Once you have received the staking rewards, you can either claim them or they will be automatically re-staked to generate additional returns for you. This way, you will also enjoy the rewards of compounding without putting any effort into it.

The StaaS process is where the real value is. It involves a bunch of complex steps, but a great provider has them automatically streamlined to make the whole experience smooth. The core advantage of StaaS is that your participation in the process is minimal without losing control over your funds.

Why  Staking-as-a-Service Could Be A Bridge Between DeFi and Institutions?

So, why is Staas ending up as a bridge between institutions and DEFi?   A few reasons driving the shift;

1.Institutional Participation

Several traditional finance players are actively participating in crypto staking. Even major institutions and banks now support PoS staking. For instance, Anchorage Digital, a federally chartered bank in the United States, now offers staking services for institutions.

Additionally, Switzerland’s SEBA Bank provides crypto custody and lending services to its clients globally. Moreover, Coinbase Custody also offers fully secure and compliant staking services.

Several asset managers are also catching up. Canadian fund 3iQ launched a Solana Staking ETF (SOLQ) on the Toronto Stock Exchange in 2025, highlighting demand for staking-backed yield in a regulated space.

This institutional momentum suggests that PoS rewards can be a valuable addition to modern investment strategies. One key reason for this increased interest is the current US Government’s positive stance towards crypto. Multiple ETF approvals, the GENIUS Act, and the recent SEC staff statement regarding staking activities are key examples.

Moreover, staking’s additional and predictable returns are becoming an attractive venture for institutions. As a result,  fund managers are taking staking as a gateway to diversify portfolios, making it a hot favorite in 2025 for institutions and DeFi bridging. In this pursuit, Staking-as-a-Service has ended up as an amenable solution because it abstracts all the complexities to set up your node and participate for benefits.

2. Staking Yields vs Traditional Finance

An important reason why staking-as-a-Service is attracting more investors is the high yields compared to traditional finance players. For instance, the US 5 Year Note Bond Yield is about 3.68% currently. This fails to beat inflation. Moreover, savings bank interest also hovers around 4-5% annually.

As evident from the graph above, in the last 10 years, the yield that crypto has generated has outsmarted traditional financial instruments like bonds and savings at around 7% and rising, pushing the narrative of staking yield to occupy center stage. With Staking-as-a-Service, institutions are getting the gateway to explore the hidden yields of DeFi in a low-yield traditional bond-bearing environment.

3. Complexity & Compliance

Running validators in-house is challenging, which keeps institutions away from staking. For example, if institutions want to integrate the same, they have to build everything from the ground up, like secure key management, a 24/7 validation system, monitor slashing risk, and meet regulatory KYC/AML audits. Moreover, institutions deal with huge amounts of capital, which increases the stakes and the seriousness regarding the risk of theft.

To outsource these complex yet important tasks, institutions choose StaaS providers. The latter helps them with the infrastructure to minimize technical and regulatory headaches. In addition to this, Staking-as-a-Service also helps in diversifying the use cases of DeFi, where, for the first time, institutions can tap unexplored goldmines like native staking, delegated staking, liquidity staking, and liquidity pool participations, which are advanced use cases attracting major institutions.

That’s why institutions are finding Staas as an effective gateway to explore the profitable realms of DeFi. But when they are doing the same, there are a few things that they should consider firsthand to explore them.

Top Determinants While Choosing a Staking-as-a-Service Provider

Before you make a move to choose a Staking-as-a-Service provider for your staking pursuits, there are  a few things that you should look into;

Custody Model: This is a very important factor. The custody of the key should remain with you so that you retain control. Look for a non-custodial StaaS provider that never takes possession of your tokens. This model ensures safety for your funds. For instance, if the infrastructure of the provider is compromised, your funds will remain safe if in your custody.

Security: While selecting a StaaS provider, you must make sure that they use enterprise-grade security measures. Check for industry certifications like SOC 2 Type II, ISO 27001, etc., and strong operational controls. For instance, you should look for platforms that provide 24/7 security monitoring and tools to manage your nodes. There are several privacy and compliance measures in place, too. In short, your provider should have rigorously audited multi-layer security and provide transparency.

Reliability & Uptime: Validator downtime results in lost rewards and potential slashing. Look for StaaS providers that guarantee 24/7 availability. Top providers deploy nodes across multiple cloud regions with automated failover. This, along with other factors, helps in maintaining a high uptime of 99.5%.

Fees: Then, you must be clear about the commission or fees charged by the StaaS provider. The core reason for staking is to earn returns on your funds. So, a transparent fee structure helps you in deciding whether you should go with a certain provider. Ideally, choose a provider with low commission to maximize your gains.

Support and Reputation: For large delegations, 24/7 support and a solid track record are particularly important. Research the provider’s reputation. Have they run validators for other projects or clients? Do they publicly share their uptime statistics or undergo regular audits? Community feedback can also give insight into the responsiveness and reliability of a provider.

By carefully looking for these factors while choosing a StaaS provider, investors can select a partner that understands their risk profile and supports their needs.

Delegate Your Tokens with Zeeve Staking–as-a-Service

Zeeve’s platform provides a well-engineered Staking-as-a-Service for investors. Here are some key features:

Non-custodial by design: Zeeve never asks for users’ tokens. Investors delegate their tokens from their wallet and maintain complete control of their funds. Zeeve only receives a validator key, not the private key to withdraw funds. You can check Coreum and Babylon.

1-Click Delegation: Just pick a network, choose Zeeve validator, and confirm. That is all you have to do to start earning your staking rewards.

Enterprise-grade infrastructure: Zeeve operates validators with institutional-grade reliability. The stack is SOC2 and ISO-27001 certified, with multi-layered deployment to maintain a 99.5% uptime guarantee.

Low commission: Zeeve charges a commission of 3%, which is the lowest among active validators. So, you retain more rewards to earn high long-term yields.

Transparent systems: Zeeve provides real-time analytics for investors to track important metrics like validator health, commission history, rewards, missed blocks, etc.

24/7 Support: You get constant support and continuous monitoring. For large or institutional delegations, Zeeve offers dedicated support, runbooks, and priority incident channels.

Automatic protocol support: Zeeve is already an active validator on multiple PoS chains. For example, Zeeve runs a Babylon ($BABY) validator on the Cosmos network and a Coreum validator on its BPoS network.

As you can see, Zeeve fulfills all the requirements of a great Staking-as-a-Service provider. It focuses on maintaining a safe, transparent, and reliable platform for investors.

For a sector that touches billions of lives daily, the lack of evolution in user engagement, monetization, and financial inclusion is stark. Even in Web3, where decentralization is meant to shatter barriers, telecom remains largely out of sync. Attempts to bring blockchain into telco apps often stop at SIM-linked wallets, token-based recharge offers, etc.

That’s where The Binary Holdings (TBH) enters. Their approach isn’t about layering crypto on top of telecom. They rebuilt the infrastructure stack that is the centrepoint of  user engagement within telco apps, the loyalty point program.

And now, they’re moving that Web3 Telecom infrastructure on Avalanche L1 using Cogitus by Zeeve.

With a user base of 169 million from Southeast Asia, Binary is leading the push to make Web3 Telecom a scalable, meaningful category.

But this isn’t just a telecom story. It’s a story of mass adoption also. A model that proves Web3 isn’t just for crypto-native builders, but for mobile-native billions. If you’re building Web3 telecom infrastructure that actually wants to scale, this chain might be your new reference design.

The Real Problem with Telecom Infrastructure in Web2 — and Web3

Let’s get honest about the issues first.

In Web2, telecom apps are static and transactional. The UX is stale. Engagement is minimal. There’s zero incentive to open the app unless you have to. For telcos, that means missed revenue, limited retention, and no real customer ecosystem.

In Web3, the problems are the opposite. The innovation is wild, but the friction is higher. Wallets, bridges, gas, private keys — it’s not just unfamiliar, it’s intimidating. And while Web3 devs build some of the most creative experiences in tech, most of their apps struggle to reach mainstream users because the distribution model is broken. If you don’t already use crypto, you’re locked out.

Now, stack the two problems together, and it’s clear why a bridge was needed. Not a metaphorical one — a real, integrated layer where user intent meets digital opportunity, without switching platforms or changing behavior.

The Binary Holdings (TBH) saw that gap, and they filled it with Web3 Telecom Infrastructure on Avalanche L1, and seamlessly connected telecom users to blockchain ecosystems.

“Telecom is an unconventional yet critical category that Web3 can cater to — and Binary has set the precedent. Their Avalanche L1 is a blueprint for enterprise-grade distribution, monetization, and on-chain service delivery at mobile scale. We’re excited to work with them again in bringing this new chain to life,”

Dr. Ravi Chamria, Co-founder and CEO of Zeeve.

How The Binary Holdings Is Bringing Web3 in the Phones of 169M+ Telecom Users?

Binary Holdings is building The Binary Network: a full-scale, production-ready blockchain designed to become the Web3 distribution layer for global telecom providers.

But what sets them apart is not just the technology. It’s their model.

Instead of asking users to download wallets, bridge funds, or understand tokenomics, Binary meets them where they already are—inside their telcom apps.

Imagine this: Your mobile carrier app has a playstore like interface. When you open it to check your data plan, instead of just a dashboard and a payment button, you see tokenized asset investments, loyalty NFTs, or even on-chain mini-games, with all activity rewarded in $BNRY tokens that can be redeemed for data or airtime.

This seamless experience is powered by Web3 Telecom Infrastructure on Avalanche L1, and enables blockchain integration within everyday telecom apps.

Binary’s telco partners—spread across Southeast Asia (namely Indonesia and Phillipines) for now and covering over 169 million users—are embedding The Binary Network into their existing infrastructure. That means Web3 isn’t a separate experience. It’s native.

Users can invest in real estate through fractional tokenization. Access DeFi tools for earning yield. Participate in DAO votes for app-level decisions. Or simply earn $BNRY by using telco services they were already going to use anyway.

And because it’s all backed by an Avalanche Layer1, the platform doesn’t rely on external bridges or centralized gateways. It’s composable, interoperable, secure by design, and showcases the power of Web3 Telecom Infrastructure on Avalanche L1 to drive mass adoption.

Why is Avalanche L1 the right move for Web3 Telecom Infrastructure?

Binary Holdings began its journey on the OP Stack—leveraging Ethereum’s scalability frameworks to launch a powerful Layer 2 experience. And to their credit, it worked.

Binary’s success with OP Stack proved product-market fit. But as their ecosystem evolved, so did the requirements. To scale further, they needed more — more control, more scalability, more sovereignty, greater customization. And an environment where appchains could be tuned for telecom-grade performance across diverse user bases and regulatory zones.

This shift necessitated Web3 Telecom Infrastructure on Avalanche L1 to meet web2-scale demands with unparalleled flexibility. The Avalanche L1 architecture offers The Binary Holdings what most modular chains can’t: customizable virtual machines, sub-second finality, native multichain support, and near-infinite scalability for high-volume consumer interactions.

In other words, the kind of infra muscle you need when your target audience is not 1M crypto users, but 1B mobile subscribers.

More importantly, Avalanche gave Binary the design space to turn their vision into a telecom-native chain, not just a Web3-native one. Their Avalanche L1 now has complete flexibility to support tokenized asset marketplaces, advanced loyalty mechanics, dApp distribution channels, staking programs, and future pathways to launch subnets for region-specific regulatory compliance.

With this shift to Avalanche L1, The Binary Holdings didn’t just upgrade their stack. They upgraded their ambition to build a Web3 Telecom Infrastructure on Avalanche L1 chain that’s not only tailor-made but also future-proof.

Why They Chose Zeeve for the Transition

“Zeeve has been with us since our OP Stack days — but with Avalanche L1, the ambition and complexity scaled up gradually. Their Cogitus platform allowed us to rapidly migrate from old infrastructure to Avalanche L1, with the performance guardrails and security guarentees we needed for telecom. Our partnership has co-engineered the backbone for everything TBH is building in Web3 Telecom Infrastructure today,”

Manit Parikh, CEO of The Binary Holdings.

This wasn’t Binary’s first deployment. Their OP Stack Layer 2 was also supported by Zeeve Rollups-as-a-Service, and when it came time to build their Avalanche L1, they didn’t look elsewhere because they didn’t need to.

Zeeve has already proven itself in navigating the complexities of launching, monitoring, and upgrading Web3 infrastructure in production. But Avalanche is a different beast. L1s require deeper orchestration, validator bootstrapping, customized consensus configurations, and region-specific compliance guardrails.

When the Avalanche shift was planned, Zeeve stepped in with its Cogitus platform, a dedicated Avalanche L1 launcher, delivering end-to-end infrastructure for their new L1 chain with zero friction. From testnet to mainnet, Cogitus provided the full Avalanche L1 lifecycle support, including:

• Chain deployment with tailored virtual machine configurations

• CI/CD pipelines for regular updates without downtime

• TraceHawk block explorer for fast, reliable insights into transactions, block data, and L1 network activity.

• Developer dashboards and analytics for app partners

• Security infrastructure aligned with ISO27001 and SOC2 standards

• Integrated explorers, faucets, and RPC endpoints for each environment

Infrastructure migrations are never easy, especially when they touch millions of users, telecom-grade SLAs, and mission-critical systems. The Binary Holdings needed a partner who could not only handle the technical lift but also understand the nuances of web3 Telecom infrastructure on Avalanche L1 stack.

Validator provisioning, full-node orchestration, VM configuration, staking support, custom APIs, and performance monitoring are all handled under Zeeve’s enterprise-grade SLA. More than just deployment, Cogitus powered by Zeeve provided The Binary Holdings with a foundation to build new business models.

More than just an infra upgrade, it was a business-critical transformation enabled by the right stack and the right partner.

There’s a lesson here—and it’s bigger than telecom.

We’ve spent a decade building tools for web3 natives. But the next billion users? They’re not coming from Discord. They’re coming from telco apps, mobile banking platforms, social commerce wallets, and offline communities that never opted into Web3—but are ready to benefit from it.

The Binary Holdings is rebuilding the market’s rails from the inside. And they’re doing it in a way that aligns with how people already interact with value. Their Avalanche L1 is a service chain. Designed to carry dApps, incentives, and assets to a mobile-first world. Web3 Telecom Infrastructure on Avalanche L1 is how that delivery system comes to life.

If you’re building anything remotely tied to real-world usage—whether that’s RWA tokenization, Web3 user acquisition, or cross-border transactions—you need to think about where the distribution is. And increasingly, it’s going to be chains like TBH’s that hold the keys.

And if you’re planning to launch your own Avalanche L1? You need infra partners who’ve been through this before. Who understands both frameworks, like OP Stack and Avalanche L1s. Who knows how to go from concept to scale without leaving holes in security, compliance, or observability.

Zeeve is that partner. Talk to us. Let’s build your Avalanche L1 next!

Now, 2025 is set to add another major sector to that list: mobility and vehicle finance. Toyota has already brought global attention to Avalanche by prototyping its Mobility Orchestration Network (MON) on the stack, showing how vehicles can be transformed into verifiable, finance-ready assets. At the same time, companies like CodeNekt, a Zeeve client, are using Avalanche L1s to tackle generational problems in vehicle data management, from fraud and traceability to compliance and fleet optimization.

What this signal is, Avalanche has the architectural mobility needs. In this blog, we’ll break down why legacy systems fail to support next-gen mobility and how Avalanche’s multi-L1 design is solving those structural gaps.

Limitations of Legacy Systems in Solving Next-Gen Mobility Barriers of Automotive Sector

The automotive industry is riddled with data silos and fragmented compliance rules. A single vehicle may pass through six or more hands (OEMs, fleet operators, insurers, regulators, drivers, service centers, and more maybe).  Yet the digital record that underpins its value remains fragmented, unverifiable, and non-portable

And unless mobility assets can become verifiable, finance-ready Real-World assets, the sector cannot scale into electrification, autonomy, or sustainable fleet operations. There are three major gaps that prevent mobility from becoming a trusted and liquid asset class:

First, the Organizational Gap. Vehicle registration, insurance, taxation, VIN and OEM data, and maintenance logs are all stored in isolated government or corporate databases. There is no Mobility Oriented Account (MOA) that bundles these institutional, technical, and economic claims into a tamper-evident identity. This leaves second-hand markets rife with odometer fraud, hidden liabilities, and scams, while manufacturers face massive recall costs because data trails vanish after the first ownership cycle.

Second, the Industrial Gap. Mobility is not one industry; it’s a mesh of capital networks (banks, securitization platforms), utility networks (ride-hailing, V2G, charging), and trust networks (registration, compliance). Yet there is no neutral digital layer to let them transact atomically. Fleet operators cannot refinance assets based on live operational data. Insurers misprice policies because they lack standardized, machine-verifiable safety and usage proofs. The absence of a multi-chain orchestration layer keeps mobility’s value locked.

Third, the National Gap. Vehicles are inherently cross-border, but compliance is regional. Registration certificates valid in one country lose legitimacy in another. Taxation and insurance proofs are regional. Used-car exports into developing markets often bypass safety and environmental checks, flooding roads with high emissions. Without a protocol for local-first, global-next compliance, mobility remains trapped in jurisdictional silos.

These issues create friction everywhere—from customers doubting vehicle history, to fleet operators struggling with refinancing, to OEMs navigating a maze of regulations when selling in new regions.

The answer isn’t just digitization. It’s a new trust layer that bundles institutional, technical, and economic proofs into a single, verifiable identity for every vehicle. And that’s where Avalanche L1s could shine.

How Avalanche L1s Ends Up as The Perfect Solution  For The Automobile Industry?

Avalanche L1s are making a difference because they provide the purpose-built stack to address the challenges mentioned above by providing:

Data Access and Control Layer For Privacy

With the public blockchains, you cannot integrate permissioned access. Which means anyone can see the transaction happening on the blockchain. This could be detrimental to using blockchains because your competitor can see the business secrets. But this is a double-edged sword, because if you do not launch on a public blockchain, instead, launch a consortium chain, even then, your problem will still remain because not every player will be using the same stack as you. In that case, you still face the problem of data silos.

That’s where Avalanche L1s are providing data access and control layers that car manufacturers can use to interact with their peers and share only whatever is necessary for the smooth operation of the business, irrespective of the stack they use.

To do that, Avalanche L1s allow setting up administrator nodes with full control over the stack, thereby ensuring role-based access for regulators and competitors who are willing to collaborate but don’t have the means to do that without jeopardizing operations due to privacy constraints. And its bridges can also help interact with different chains irrespective of the stack they use.

Native Interop through Multi-L1 Architecture

Interoperability is a challenge when there are various players in the industry using different stacks for operation. Avalanche L1s are using multichain support through Interop using Avalanche Warp Messaging and Teleporter to allow communication, especially in the Delivery-versus-Payment (DvP) transactions. Because you need instant interoperability irrespective of the stack that two different applications are using when interacting with each other, this is highly suited for use cases such as BEVs, monetizing energy storage, logistics efficiency, and green transition.

Toyota’s MON 4-L1 prototype architecture below illustrates how Avalanche L1s can be configured for mobility with dedicated L1s for trust, finance, utility, and stablecoin payments, all connected through Avalanche Interchain Messaging (ICM). This modular design makes Delivery-vs-Payment and cross-network coordination possible in a way legacy infrastructure never could.

Cross-Border Compatibility Via Custom VMs:

Compliance is another major battle that the automotive sector is wishful of winning, but they do not get the means to help achieve that when they are operating in different jurisdictions. With the help of Avalanche L1 chains, automobile companies can create built-in KYC/AML checks, specifically targeting financiers and insurers.

At the same time, it is also possible to create an administrator dashboard using the Avalanche L1 stack and give role-based access to regulators to access important information and when needed. At the same time, preserving privacy in the process through eERC-20 features that Avalanche L1s are using.

Building The Fungibility Ladder

Making vehicles fungible is a major bottleneck for fleet owners because they cannot set up standards where they can self-identify the vehicles and make them readily available for financing in cross border operations. Avalanche L1s provide a fungibility ladder for these fleet owners dispersed across different jurisdictions through a standardized access to overcome this. Using Avalanche L1s, the automobile players can spin up their own chains and set up specific traits for their NFTs that can be easily exchanged overseas/cross border in a near instant, scalable  cost-effective and compliant manner, eliminating the friction to manage cross border fleet management that automobile players are going through at the moment.

Optimizing Cost For Faster Deployment

This is the most important aspect to consider when launching a blockchain-based automotive business, as you do not want to overburden yourself with unnecessary technology. Avalanche L1s are purpose-built because there’s no compulsion to stake like 2000 AVAX to run your validators for your chain.

With that being said, you are getting a stable infrastructure cost to launch your automotive application on top of Avalanche L1s, and despite their rigorous increase in usage, the cost wouldn’t be inflating in the near future because the L1s have Pay-As-you-Go, custom gas tokens, and other specs to keep the operations optimized from a cost standpoint.

At the same time, the consensus mechanism of Avalanche L1s is purpose-built as well to accommodate a scaling automotive sector with transactions matching almost 4500 TPS due to the random sub-sampling consensus mechanism. Martin Eckardt, Senior Director of DevRel at Ava Labs, specifically emphasizes the role Avalanche L1s are playing in keeping the cost low for efficient operations despite the automotive business scaling in a podcast between Zeeve’s CEO, Dr Ravi Chamria, and Francis Hanchem, founder of CodeNekt:

Future Proofing Mobility

Avalanche L1s have an advantage when it comes to future-proofing the mobility sector because they have the capability to bridge finance, mobility, and IoTs under a common stack, which no other stack has delivered so far. Due to this trait only, the Togg ecosystem in Turkey has partnered with Avalanche to take mobility to the next level.

If you are someone in the automotive industry facing the problems mentioned in this blog, Avalanche L1s can rightfully address them.

But if you are bothered that all of these would amount to spending hours to integrate the same, Zeeve can help you in this regard to launch your Avalanche L1 for the Automotive Industry.

Avalanche L1

Is Avalanche L1 About to Become the Hotspot for Vehicle Finance & Mobility?

Dr. Ravi Chamria

• September 1, 2025

Avalanche L1s are making headlines due to the value they have captured in the last few months by providing a custom stack. Due to this, gaming,  stablecoins, DeFi, NFTs, manufacturing, and even government sectors are getting revolutionized by it.

Now, 2025 is set to add another major sector to that list: mobility and vehicle finance. Toyota has already brought global attention to Avalanche by prototyping its Mobility Orchestration Network (MON) on the stack, showing how vehicles can be transformed into verifiable, finance-ready assets. At the same time, companies like CodeNekt, a Zeeve client, are using Avalanche L1s to tackle generational problems in vehicle data management, from fraud and traceability to compliance and fleet optimization.

What this signal is, Avalanche has the architectural mobility needs. In this blog, we’ll break down why legacy systems fail to support next-gen mobility and how Avalanche’s multi-L1 design is solving those structural gaps.

Limitations of Legacy Systems in Solving Next-Gen Mobility Barriers of Automotive Sector

The automotive industry is riddled with data silos and fragmented compliance rules. A single vehicle may pass through six or more hands (OEMs, fleet operators, insurers, regulators, drivers, service centers, and more maybe).  Yet the digital record that underpins its value remains fragmented, unverifiable, and non-portable

And unless mobility assets can become verifiable, finance-ready Real-World assets, the sector cannot scale into electrification, autonomy, or sustainable fleet operations. There are three major gaps that prevent mobility from becoming a trusted and liquid asset class:

First, the Organizational Gap. Vehicle registration, insurance, taxation, VIN and OEM data, and maintenance logs are all stored in isolated government or corporate databases. There is no Mobility Oriented Account (MOA) that bundles these institutional, technical, and economic claims into a tamper-evident identity. This leaves second-hand markets rife with odometer fraud, hidden liabilities, and scams, while manufacturers face massive recall costs because data trails vanish after the first ownership cycle.

Second, the Industrial Gap. Mobility is not one industry; it’s a mesh of capital networks (banks, securitization platforms), utility networks (ride-hailing, V2G, charging), and trust networks (registration, compliance). Yet there is no neutral digital layer to let them transact atomically. Fleet operators cannot refinance assets based on live operational data. Insurers misprice policies because they lack standardized, machine-verifiable safety and usage proofs. The absence of a multi-chain orchestration layer keeps mobility’s value locked.

Third, the National Gap. Vehicles are inherently cross-border, but compliance is regional. Registration certificates valid in one country lose legitimacy in another. Taxation and insurance proofs are regional. Used-car exports into developing markets often bypass safety and environmental checks, flooding roads with high emissions. Without a protocol for local-first, global-next compliance, mobility remains trapped in jurisdictional silos.

These issues create friction everywhere—from customers doubting vehicle history, to fleet operators struggling with refinancing, to OEMs navigating a maze of regulations when selling in new regions.

The answer isn’t just digitization. It’s a new trust layer that bundles institutional, technical, and economic proofs into a single, verifiable identity for every vehicle. And that’s where Avalanche L1s could shine.

How Avalanche L1s Ends Up as The Perfect Solution  For The Automobile Industry?

Avalanche L1s are making a difference because they provide the purpose-built stack to address the challenges mentioned above by providing:

Data Access and Control Layer For Privacy

With the public blockchains, you cannot integrate permissioned access. Which means anyone can see the transaction happening on the blockchain. This could be detrimental to using blockchains because your competitor can see the business secrets. But this is a double-edged sword, because if you do not launch on a public blockchain, instead, launch a consortium chain, even then, your problem will still remain because not every player will be using the same stack as you. In that case, you still face the problem of data silos.

That’s where Avalanche L1s are providing data access and control layers that car manufacturers can use to interact with their peers and share only whatever is necessary for the smooth operation of the business, irrespective of the stack they use.

To do that, Avalanche L1s allow setting up administrator nodes with full control over the stack, thereby ensuring role-based access for regulators and competitors who are willing to collaborate but don’t have the means to do that without jeopardizing operations due to privacy constraints. And its bridges can also help interact with different chains irrespective of the stack they use.

Native Interop through Multi-L1 Architecture

Interoperability is a challenge when there are various players in the industry using different stacks for operation. Avalanche L1s are using multichain support through Interop using Avalanche Warp Messaging and Teleporter to allow communication, especially in the Delivery-versus-Payment (DvP) transactions. Because you need instant interoperability irrespective of the stack that two different applications are using when interacting with each other, this is highly suited for use cases such as BEVs, monetizing energy storage, logistics efficiency, and green transition.

Toyota’s MON 4-L1 prototype architecture below illustrates how Avalanche L1s can be configured for mobility with dedicated L1s for trust, finance, utility, and stablecoin payments, all connected through Avalanche Interchain Messaging (ICM). This modular design makes Delivery-vs-Payment and cross-network coordination possible in a way legacy infrastructure never could.

Cross-Border Compatibility Via Custom VMs:

Compliance is another major battle that the automotive sector is wishful of winning, but they do not get the means to help achieve that when they are operating in different jurisdictions. With the help of Avalanche L1 chains, automobile companies can create built-in KYC/AML checks, specifically targeting financiers and insurers.

At the same time, it is also possible to create an administrator dashboard using the Avalanche L1 stack and give role-based access to regulators to access important information and when needed. At the same time, preserving privacy in the process through eERC-20 features that Avalanche L1s are using.

Building The Fungibility Ladder

Making vehicles fungible is a major bottleneck for fleet owners because they cannot set up standards where they can self-identify the vehicles and make them readily available for financing in cross border operations. Avalanche L1s provide a fungibility ladder for these fleet owners dispersed across different jurisdictions through a standardized access to overcome this. Using Avalanche L1s, the automobile players can spin up their own chains and set up specific traits for their NFTs that can be easily exchanged overseas/cross border in a near instant, scalable  cost-effective and compliant manner, eliminating the friction to manage cross border fleet management that automobile players are going through at the moment.

Optimizing Cost For Faster Deployment

This is the most important aspect to consider when launching a blockchain-based automotive business, as you do not want to overburden yourself with unnecessary technology. Avalanche L1s are purpose-built because there’s no compulsion to stake like 2000 AVAX to run your validators for your chain.

With that being said, you are getting a stable infrastructure cost to launch your automotive application on top of Avalanche L1s, and despite their rigorous increase in usage, the cost wouldn’t be inflating in the near future because the L1s have Pay-As-you-Go, custom gas tokens, and other specs to keep the operations optimized from a cost standpoint.

At the same time, the consensus mechanism of Avalanche L1s is purpose-built as well to accommodate a scaling automotive sector with transactions matching almost 4500 TPS due to the random sub-sampling consensus mechanism. Martin Eckardt, Senior Director of DevRel at Ava Labs, specifically emphasizes the role Avalanche L1s are playing in keeping the cost low for efficient operations despite the automotive business scaling in a podcast between Zeeve’s CEO, Dr Ravi Chamria, and Francis Hanchem, founder of CodeNekt:

Future Proofing Mobility

Avalanche L1s have an advantage when it comes to future-proofing the mobility sector because they have the capability to bridge finance, mobility, and IoTs under a common stack, which no other stack has delivered so far. Due to this trait only, the Togg ecosystem in Turkey has partnered with Avalanche to take mobility to the next level.

If you are someone in the automotive industry facing the problems mentioned in this blog, Avalanche L1s can rightfully address them.

But if you are bothered that all of these would amount to spending hours to integrate the same, Zeeve can help you in this regard to launch your Avalanche L1 for the Automotive Industry.

Launch Your Avalanche L1 for Automotive Industry with Cogitus by Zeeve

Zeeve has a proven track record of launching more than 15 + Avalanche L1s in the last 90 days on its own platform. So, if you want to build your own purpose-built Layer 1 chain for your automotive business, Zeeve can help, from rapid node & network setup to RPC configurations to validator node settings, integrations, and more.

We also acknowledge the fact that you would like to continuously monitor your Avalanche L1 node, the Avalanche L1 dashboard that we provide will help you continuously monitor all the activities. In addition to this, you also get the benefits of 55+ integration partners that we bring on Zeeve.

Zeeve now supports $BABY delegation on enterprise-grade infrastructure, with 99.95% uptime, backed by SOC 2 Type II and ISO 27001 certifications.

This article focuses on $BABY delegation—what Babylon is, how it actually works under the hood, the numbers that matter right now, why staking BABY makes sense, and why delegating to Zeeve is the most pragmatic way to do it if you care about uptime, fees, and operational discipline.

What is Babylon?

Babylon is a Bitcoin-secured security layer that extends Bitcoin’s credibility to PoS chains and decentralized applications.

The protocol achieves this by separating the provider of security from the location of the throughput. Security comes natively from Bitcoin; throughput and coordination happen on the Babylon Genesis chain (a Cosmos SDK chain using CometBFT).

That split keeps Bitcoin where it excels, enabling economic finality and credible neutrality while allowing PoS systems to scale and interoperate.

This chain introduces a dual-staking design:

• BTC staking: Bitcoin UTXOs achieve finality for client chains; slashing enforcement occurs on Bitcoin.

• BABY staking: $BABY secures the Genesis chain, the control plane that routes Bitcoin-backed security and manages fees/governance. Earns rewards in return.

This transforms Bitcoin into a reusable finality anchor, making Babylon a security/liquidity coordination layer for Bitcoin-secured networks.

How Babylon Works? The Roles and the Flow

BABY-staked CometBFT Validator produces/validates blocks on the Genesis chain, runs governance upgrades/params, and keeps the control plane live. Delegators stake BABY to these validators and earn a share of the protocol’s rewards, minus the commission.

Finality Providers sign finality for blocks using BTC-secured credentials. Misbehavior can trigger on-Bitcoin slashing via EOTS (Extractable One-Time Signatures). No custodians. No wrapped BTC.

A block is final when a dual-quorum is achieved. This means that both validators and finality providers attest.

$BABY Value Accrual: Why the Token Matters?

Fees: BABY is the gas token for transactions and smart contracts on Genesis.

Security coordination premium: As more client chains subscribe to Bitcoin-anchored finality and liquidity routed through Genesis, the control plane accrues activity, captured in fees and validator economics.

Governance: BABY holders (directly or via delegation) set parameters that determine the price and scale of the security marketplace.

Staking rewards: BABY emissions/rewards compensate for validator work and delegator capital that keeps the plane reliable.

Why Delegate $BABY to Zeeve-run Babylon Validator?

Zeeve is an active Babylon validator with a track record of running institutional validators across multi-cloud, multi-region deployments.

Here are some more reasons to choose us:

Lowest commission among active validators: 3%

More rewards stay with you, compounding your long-term yield.

Proven uptime: 99.95%

High availability = more consistent rewards and fewer missed blocks.

Non-custodial by design

Delegate from your own wallet or regulated custody. Your keys, your control.

Enterprise-grade ops

Multi-cloud, multi-region, Sentry & backup nodes, auto-failover, 24/7 SRE monitoring, and enterprise SLA.

Security & compliance you can audit

SOC 2 Type II and ISO 27001 controls, strict IAM, continuous monitoring, audit-grade logs.

Full transparency

Track validator health, commission history, missed blocks, and reward accruals—export-ready for finance/compliance.

Frictionless flows

delegate/claim/compound/unbond flows with clear timelines, plus API access for institutions.

FAQs

1. What does it mean to “stake BABY”?
   You delegate BABY to a validator (e.g., Zeeve). Your stake increases validator security weight; you earn a share of protocol rewards, minus the validator commission.

2. Is staking with Zeeve non-custodial?
   Yes. You can delegate from your own wallet or a regulated custody account. Zeeve never takes possession of your keys.

3. Is there a minimum to delegate?
   Not with Zeeve. Running your own active validator requires 75,978 BABY (~$3,724), but delegators face no minimum.

4. How are rewards determined?
   Rewards depend on network parameters (inflation, distribution rules) and validator performance. The current APR is ~20.56% (with a recent 1-month delta of ~0.54 percentage points). Zeeve’s 3% commission is among the most delegate-friendly.

5. How long does unbonding take?
   Around 2 days (≈300 BABY blocks). Unbonding is an on-chain process; once complete, your tokens are once again liquid.

6. What makes Babylon’s “Bitcoin security” credible?
   EOTS ties slashing to Bitcoin UTXOs; penalties are enforced on Bitcoin, not via wrapped assets or custodians. The Genesis chain then uses a dual quorum (CometBFT validators + Bitcoin-staked finality providers) for block finality.

7. What about risk and slashing?
   All PoS networks carry operational risk. Zeeve minimizes it with redundancy, continuous monitoring, strict IAM, incident runbooks, and SLA-backed processes.

8. What if I want to run my own validator?
   Zeeve offers white-labeled Babylon validators for those who wish to run their own validator nodes, featuring the same enterprise-grade features and 99.95% uptime guarantees. Join the Discord to connect with the community, get support, and stay updated on the latest validator developments.

We’ve heard it all before—“healthcare needs transformation.” But after years of promises, patients are still locked out of their own data. Cross-border care remains a bureaucratic maze. And infrastructure that actually puts patients first is still rare.

Ulalo started with a vision to change that with a sovereign Blockchain. Live now on its own sovereign Avalanche Layer 1, Ulalo is powering a production-grade health wallet where patients own, control, and share their data — across languages, across borders, across devices. And it’s already doing what most healthtech platforms only promise—giving people true ownership of their medical records. Without delays, silos, and compromises.

Ulalo is a global health passport for the on-chain age—powered by AI, built for privacy, and now running on a sovereign Layer 1 chain built and managed by Zeeve Cogitus.

“ULALO’s vision is simple: to bridge people and the world. Our chain lets patients globally access top-tier healthcare and regain control of their data. Partnering with Zeeve and launching on Avalanche made this possible, providing the scale and integrity necessary to make a real-world difference in healthcare.”

— Fabrice Kwetchet, Founder & CEO, Ulalo

Avalanche L1 Gave Ulalo What Healthcare Demands

In Ulalo’s world, a patient scans a diagnostic report, the system runs AI classification, stores the result on IPFS, verifies it on-chain, and lets a doctor in another country review the data—all in seconds. That kind of real-time, cross-border flow can’t depend on a congested public chain or someone else’s mainnet rules.

Ulalo chose Avalanche L1 stack for its sovereign Blockchain because it offered deterministic finality, low and predictable fees, and the ability to control everything—from token logic to governance rules. As a sovereign chain, Ulalo could hardwire its healthcare logic directly into the infrastructure without compromise. No external dependencies, no cohabiting apps, no resource contention. Just a clean, scalable, healthcare-grade chain that doesn’t blink—even under pressure.

It also meant the Ulalo team could natively embed things like biometric authentication, real-time syncing across mobile devices, and multilingual interfaces—without having to ask permission from anyone.

That’s how you build infrastructure for 400 million underserved patients.

What’s Live on Ulalo Mainnet Right Now

Everything Ulalo promised on testnet is now live, running, and already in use.

Users open the wallet, scan a report, and AI classifies the data. It’s encrypted, stored off-chain, and the proof is logged immutably to Ulalo’s L1. The hash is verifiable. The access is controlled. And the data is shareable instantly — no silos, no follow-ups, no risk of leakage.

Doctors get reliable histories. Patients stay in control. Insurers get integrity. And it’s already powering:

• Multilingual, patient-facing health wallets

• Live biometric-auth syncing across devices

• AI-based health alerts with structured record analysis

• Smart record-sharing with expiry and permission controls

• $ULA-based insurance and ecosystem interactions

The foundation is now real. The user journey is real. And the infrastructure is ready for scale.

Zeeve and Cogitus Made Mainnet Feel Like Mission Control

Ulalo didn’t just need help launching a chain. It needed production-grade reliability with zero learning curve and zero fragility.

With Zeeve Cogitus, Ulalo got a chain that behaves like a backend platform — not a lab setup.

Zeeve took full charge of the infrastructure — from provisioning to production — with:

• Custom Avalanche L1 deployment, tuned for AI, healthcare ops, and global sync

• Dedicated RPC infrastructure to handle wallet and app usage at scale

• TraceHawk Explorer integration for network transparency, data verification, and audit trails

• 24/7 monitoring and observability, with health dashboards and real-time alerts

• Critical path support, ensuring every component stays up — even in high-dependency environments

“Ulalo’s chain had to meet a higher bar. It’s not about performance metrics. It’s about being unbreakable when lives are on the line. With Cogitus, we didn’t just power a mainnet — we operationalized trust.”

— Dr. Ravi Chamria, Co-founder & CEO, Zeeve

Ulalo is now mainnet live. $ULA is preparing for its next exchange listing. Strategic partners are coming on board. But more importantly, the chain works. Right now. In production. And it shows what’s possible when builders go full-stack with the right infra partner.

So if you’re building for healthcare, digital ID, public health systems, or global data sovereignty—Ulalo’s path is now open. And Zeeve’s Cogitus stack is ready to get you there.

Let’s build the next real use case. For patients. For people. For production.

• Arbitrum Orbit Rollups

• Arbitrum Orbit AnyTrust chains

• Custom Orbit chains

These solutions are solving some of the pressing challenges of different projects, and their choice can fundamentally define a chain’s security, cost, and performance profile.

In this blog, we’ll highlight the challenges that these stacks are purpose-built to solve, and which use-cases must pick them as their go-to stack. So, without any further ado, let’s get started.

Top-3 Arbitrum Orbit Solutions, their features, and real projects built using them

1. Arbitrum Orbit Rollups:

Orbit Rollups are the most secure variant within the Arbitrum Orbit family. They follow the classic optimistic rollup model, where transactions are sequenced, compressed, and posted on Ethereum as calldata. Now, with the implementation of Ethereum’s EIP-4844, it is more cost-effectively posted as data “blobs”.

This on-chain data posting is the bedrock of Arbitrum Orbit Rollup’s security model. Because all transaction data is publicly available on the parent chain, any participant in the world can independently download it, reconstruct the L2’s state, and verify its correctness.

I) This enables a system of permissionless validation where any honest actor can detect fraud and challenge an incorrect state assertion. This challenge is resolved through Arbitrum’s battle-tested, multi-round, interactive fraud-proof system, which efficiently narrows down a dispute to a single computational step that is then verified on-chain.

II) By inheriting the full data availability and security guarantees of its settlement layer, an Orbit Rollup makes no additional trust assumptions beyond those of Ethereum itself.

III) The trade-off, however, is that Ethereum DA comes with higher posting costs and longer withdrawal times, especially for Orbit L3s that must pass through Arbitrum One before final settlement.

IV) While this model is the most expensive due to L1 data posting costs, this expense is best understood as a premium paid for unparalleled security. The Ethereum Dencun upgrade, which introduced EIP-4844, served as a crucial defensive measure for the Rollup model. By creating a separate, cheaper data market in the form of blobs, it significantly lowered this security premium, ensuring that Rollups remain an economically viable and competitive option for their target market.

Key Use-Cases that can be built as Arbitrum Orbit Rollups:

The Rollup model is the definitive choice for applications where security is paramount and cannot be compromised. These are typically protocols that secure immense value or operate in environments with stringent regulatory and compliance requirements, where any additional trust assumption can be costly.

For example,

• High-Value DeFi:

Protocols such as decentralized exchanges (DEXs), lending markets, and perpetual platforms that manage billions of dollars in TVL/TVS require the unassailable security of Ethereum to protect user assets.

For these applications, the term “Rollup” has become a brand synonymous with “Ethereum-grade security,” and definitely signals trust to users and liquidity providers.

• High Value Real-World Assets (RWAs):

Platforms tokenizing assets like real estate, private credit, or government treasuries must present a clear and defensible compliance posture to attract institutional capital and people’s trust.

The transparency and verifiability of posting all transaction data on-chain are fundamental requirements for this sector.

• Bridges and Core Infrastructure:

Most of the TVS is held in bridges. Such kind of foundational protocols that are responsible for securing assets from numerous other chains cannot afford to introduce new vectors of trust.

Some Projects Successfully Deployed As Orbit Rollups Chains

AnimeChain

Animechain is specially designed for the Anime community, where they can enable on-chain licensing, monetization, and creation of anime characters. For this purpose, they sought very high TPS and faster finality, while also inheriting security for users in a trust-minimized manner.

Orbit rollups with ETH as the settlement layer delivered to meet this demand for Anime. Through Orbit rollups,  Anime was able to clock 40,000 TPS with a 250 ms blocktime. Moreover, they were also able to do gasless onboarding, transparent right management, and so on and so forth.

Reya Chain

Another project using Orbit rollup is ReyaChain, which aims at unifying the CeFi, DeFi, and Tradfi ecosystems into a single hub. Besides leveraging the common Orbit’s features like speed, scalability, and throughput, the extended customization has allowed Reya to adopt an architecture with financial logic integrated directly into the network. This enables liquidity flow to be accessible by various applications all at once.

Also, Reyachain could fulfill its requirement for a different DA, which is a hybrid DA setup. Within this, the orders and executions get posted on Celestia (external DA), and account data is pushed to the Ethereum Layer 1. For settlement, Reyachain uses Ethereum.With this support, ReyaChain is hitting 200k+ trades a week, multiple collateral & instruments for 60 markets through 100ms blocktimes, MEV-free trades, deep liquidity, high availability, and more.

2. Arbitrum AnyTrust Chains

The Arbitrum AnyTrust protocol offers an equal alternative to the traditional public rollups. These AnyTrust chains are designed to drastically reduce costs while maintaining strong security guarantees.

For AnyTrust chains, instead of posting full transaction data to Ethereum, the sequencer sends the data to a permissioned Data Availability Committee (DAC).

The members of this committee run specialized Data Availability Server (DAS) software to store the transaction data off-chain, and collectively sign a Data Availability Certificate (DACert).

I) The security model of AnyTrust is built on a ‘minimal trust assumption’.

II) The system remains secure as long as a small minority of DAC members (for example, 2 out of a committee of 20) are honest and will provide the data when requested.

III) In specific use cases, this is a significantly more robust and easier-to-satisfy assumption than the supermajority (e.g., 14 out of 20) required by conventional public rollups.

IV) However, the most interesting feature of AnyTrust is its “fallback to rollup” mechanism.

If the DAC fails to cooperate and does not produce a DACert for a batch of transactions, the protocol forces the sequencer to post the full transaction data on-chain, exactly like a standard Rollup.

V) This one security step ensures that the chain’s liveness is always preserved and that its security is ultimately tethered to Ethereum. This makes AnyTrust a “conditionally secure rollup” if we want to say so.

VI) Plus, this minimal on-chain footprint of AnyTrust enables powerful features that are difficult for Orbit Rollups to support, like the ability to use a custom ERC-20 token for gas fees and fast withdrawals that can bypass the standard 7-day challenge period.

Key Use-Cases That Can Be Considered for Building on Orbit AnyTrust Chains

AnyTrust is perfect for solutions for applications where high throughput and ultra-low transaction costs are critical for delivering a viable and engaging user experience.

The sectors below represent the largest untapped markets for Arbitrum AnyTrust and are poised to drive the next wave of adoption.

Web3 Gaming:

On-chain games often require thousands of low-value, high-frequency actions, such as minting in-game items, updating character states, or executing small moves.

The sub-cent transaction fees offered by AnyTrust make complex and immersive on-chain game logic economically feasible for gaming chains.

Consumer Facing Applications:

• Social Apps: Social apps are looking for low-fee messaging and micro content sharing in a scalable and verifiable manner. AnyTrust chains are built to deliver transactions at scale because they can use their own DAC committee for data posting and achieving near infinite scale.

• Payments & Microtransactions: For consumer payment apps, AnyTrust architecture can be a perfect fit. The ultra-low fees enable use cases like in-app purchases, tipping, and other such small-value transfers in-expensive.

DePIN & High-Frequency DeFi:

Sectors like Decentralized Physical Infrastructure Networks (DePIN), which rely on frequent micro-transactions from a large number of devices, or decentralized derivatives exchanges with high-frequency order book updates, find a perfect technical and economic fit in AnyTrust’s performance profile.

AI Agents & Web3 x AI Applications:

The rise of AI Agent uses on-chain creates an immense demand for high-frequency, low-cost transactions. These agents signal, transact, and respond hundreds of times per session. AnyTrust provides the cheap and predictable data availability needed for such AI agent markets. This makes it an ideal infrastructure for the emerging DeFAI sector, also.

Some Project That Successfully Deployed As AnyTrust Rollups

XAI Games

XAI Games wanted to solve the problem of gameplay in the Web3 space. For example, most of the games are lacking experience; rather, they delve more into economies. But with that model in mind, it is hard to onboard the AAA games, the OGs of the Web 2 gaming world. XAI games solve this by providing a ready-to-deploy environment for game builders.

They use AnyTrust chains for that because it provides lightning-fast transaction speed, as platforms like STEAM, the Web 2 gaming launchpads have 100 M users. To compete with them and onboard all of them to Web 3 as a launchpad, XAI needs lightning-fast transactions, a fully gasless experience,  seamless onboarding, and quick settlements. Orbit AnyTrust chains were purpose-built for that.

SkyNet

The core challenge of an AI economy is handling millions of microtransactions at extreme scale with predictable, low costs. Skynet is building an AI-optimized L3 Arbitrum Orbit chain with a goal to be the transactional backbone for a future where AI-agents can outnumber humans.

They choose AnyTrust model for this ‘cheap & predictable’ data availability, which is essential for such high-frequency AI agent markets.

Launched with the expertise of Zeeve Rollups-as-a-Service, Skynet chain is highly customized with features like a SKYUSD gas token for its AI-driven ops.

Learn More Here: Skynet’s New Blockchain on Arbitrum Orbit will Scale AI Agents at Warp Speed

PropFTX

PropFTX combines AI with Orbit functionalities to offer fractional ownership for real estate industry and allows users to buy, sell, and invest in tokenized shares of high-value commercial properties.

For a consumer-facing investment platform that requires frequent, low-cost interactions and a seamless UX, AnyTrust DAC model is an ideal choice. It provides the necessary scalability and affordability to make fractional investing accessible, and RaaS support from Zeeve ensures a robust and reliable infrastructure.

3. Custom Arbitrum Orbit Chains

Custom DA chains are in support of the modular thesis and allow Arbitrum Orbit chains to integrate with external, specialized data availability networks. Here, the Orbit chain’s sequencer posts transaction data directly to a third-party DA layer.

In return, it receives a cryptographic proof of publication, which is then posted to the settlement layer (like Arbitrum One) to be included in the state root.

Though this model introduces a new set of trust assumptions, as the security and liveness of the Orbit chain become coupled with the cryptoeconomic security of the external DA network’s validator set as well.

Here are some DA layers that can be integrated with the Arbitrum Orbit chains:

• Celestia: The first modular DA network to integrate with Orbit, Celestia uses Data Availability Sampling (DAS) and Namespaced Merkle Trees (NMTs) to allow light clients to verify data availability without downloading entire blocks. Its integration with Orbit relies on Blobstream to relay data commitments back to the parent chain.

• EigenDA: Eigen layers DA solution leverages Ethereum’s economic security through EigenLayer’s restaking primitive. Orbit chains using EigenDA can achieve massive throughput secured by a decentralized network of operators restaking billions of dollars worth of ETH.

• Avail DA: Originating from within Polygon, Avail focuses on validity proofs (specifically, KZG commitments) for data availability, which can offer faster finality guarantees without the need for extended challenge periods.

The choice between these providers is a strategic alignment with a specific security philosophy. It can be the independent proof-of-stake security of Celestia or the Ethereum-aligned restaking security of EigenDA, or maybe the extremely cheap cost of NEAR DA.

Read More About Data Availability Solutions Used in Layer2/ Layer3 Chains:

1. Alt DA Solutions Changing the Cost Game for L2 Rollups: Spotlight on Key Players

2. Data Availability Layer in Rollups: What is it and why do we need one?

Key Use-Cases That Can Be Considered for Building on Orbit Custom Chains

Applications here have the requirements that exceed even the high performance of AnyTrust; those who seek a greater degree of sovereignty and deeper integration with a broader modular ecosystem can look into this category.

So in one line, we could say, this category is ideal for those who are willing to accept a more complex and novel security model in exchange for ultimate flexibility and the lowest possible costs.

Fully on-chain Gaming:

For games that aim to put every action and asset on-chain, the extreme cost reduction offered by Celestia or other AltDA platforms in combination with the Nitro stack is a necessity. Because they might need a massive volume of transactions to be virtually free, this goal can only be achieved by moving data availability to a hyper-optimized additional chain.

High Value DeFi & RWAs

DeFi and RWAs are looking for high-value trade, but for that matter, they don’t want to be restricted by the limitations of storing data only on Ethereum or to a limited set of DAC nodes; rather, they want other custom economic data storage solutions, KYC, and other compliance.

Interoperability Hubs

Interops hubs unify security at a single checkpoint; as a result, they cannot operate in a trust-minimized manner. Custom rollups give them an edge to choose a DA layer that can be trusted, and at the same time, it is cost-effective as well.

Some Projects That Successfully Deployed As Custom Rollups

These categories of applications often have requirements that exceed even the high performance of AnyTrust, or they seek a greater degree of sovereignty and deeper integration with the broader modular ecosystem.

Though the custom Orbit rollup is new, it’s been adopted by some of the innovative and new-age projects, such as;

Kinto

Kinto, the modular exchange, has migrated to Arbitrum Orbit to seek a better level of security, data integrity, and regulatory compliance matching traditional finance. It uses Arbitrum Nitro Stack to operate as a rollup operating in parallel with Arbitrum One and Nova while being fully compatible with the Ethereum Virtual Machine (EVM), and settles transactions on Ethereum Mainnet.

Kinto uses Celestia as its external DA layer. The network collects all sequencer fees (gas) from network transactions, and its revenue comes from the spread between these fees and the cost of settling the batched transactions on Ethereum Mainnet. Regarding the token, Kinto uses $KINTO as its governance and utility token. With all these features, Kinto has been able to build a fully KYC-compliant L2 that can support both the modern finance and decentralized DeFi protocols.

Alpha Dune Network

Alpha Dune Network is a Layer3 solution built with an Orbit stack for ultra-fast and low-cost transactions that is integral in DeFi. Built as a custom chain, Alpha Dune has integrated Celestias as the DA layer while still using Ethereum-level security.

Other features that Orbit offers to the network are modular, on-chain scaling, and decentralized governance. Regarding the token, Alpha uses the DUNE token as its native gas token to power every transaction and interaction, including asset transfers.

Plume Network

Plume is an RWA / real-world (RWA) focused project to ensure 100% compliance in RWA activities like earning yield, trading, speculation, lending/borrowing, etc. Built as a modular & permissionless L2, Plume uses Orbit as its custom rollup stack and Celestia as an off-chain DA layer.

Plume is home to 80+ RWA (Real World Assets) and DeFi projects. Orbit’s customization features allow Plume to manage its projects and high-traction network seamlessly. Speaking about token, Plume Network utilizes PLUME for transaction fees, staking, governance, and various incentives within the ecosystem.

The ecosystem also features Plume USD (pUSD), which is a stablecoin wrapper for USDC, and Plume ETH (pETH), a liquid staking token that is pegged to Ethereum.

Which of These 3 Types of Arbitrum Orbit Chain Could See More Adoption?

First, the largest addressable markets for new blockchain applications are in consumer-facing sectors like gaming, payment, and social media, which are fundamentally incompatible with the fee structures of the Rollup model.

Second, while Custom DA chains also meet this demand, AnyTrust is a more pragmatic and lower-risk path for the majority of developers. It offers the ultra-low costs needed for consumer applications while retaining a native, battle-tested security backstop in the form of the Arbitrum protocol’s fallback mechanism.

For a new project launching in 2025, choosing this tightly integrated, in-house solution is a more conservative and predictable path to scalability than adopting an external dependency on a separate, still-maturing DA network.

Though we feel all three chains will see adoption, with the highest possibility being for AnyTrust & Custom Orbit chains.

Build Any of These 3 Types Arbitrum Orbit Solution with Zeeve RaaS

The whole explanation in this article highlights the rising demand for the Arbitrum-powered solutions. If these features align with your project requirements, Zeeve RaaS is your ideal partner to build your own sovereign, performant, and customizable chain as per your needs: Be it Orbit rollup, AnyTrust Chain, or Custom Orbit chains.

With support for AnyTrust mode, Stylus (Rust/C++), and 55+ third-party integrations, Zeeve gives you the tools to design, deploy, and evolve your Orbit chain your way. And when you’re ready to go beyond the testnet, Zeeve offers you smooth mainnet migrations with your default settings and required integrations in the fastest possible time.

Talk to our experts to discuss your requirements. We’re here 24/7 to help you go from idea to execution — faster, cheaper, and fully in control.