DEV Community: Azalea

What Changed in Crypto Product Design in 2026?

Azalea — Wed, 23 Sep 2026 14:48:18 +0000

Crypto apps are becoming easier to use because more blockchain complexity is moving out of the interface.

Users still interact with wallets, networks and transactions, but the product increasingly handles the technical steps behind them. A broader overview of what changed for everyday crypto app users in 2026 points to the same shift across authentication, custody and payments.

Key Takeaways

Passkeys and embedded wallets simplify onboarding.
Smart accounts can combine several blockchain actions into one flow.
Gas sponsorship reduces the need to manage network tokens manually.
Chain abstraction hides some multichain complexity.
Stablecoins are being integrated into familiar payment flows.

Passkeys Are Changing Onboarding

Crypto onboarding has often required passwords, email verification and separate wallet setup.

Passkeys offer a simpler authentication flow based on public-key cryptography. Users can authenticate with a device PIN, fingerprint or face recognition instead of entering a password. Google documents passkeys as a phishing-resistant alternative to traditional password login.

Embedded wallets take this further by putting wallet functionality inside the application. A user can create or access an onchain wallet without starting with a separate wallet installation and connection flow.

For developers, authentication and wallet creation are becoming part of the same product experience.

Smart Accounts Reduce Manual Steps

Traditional Ethereum wallets expose many blockchain operations directly to the user.

Smart account infrastructure allows developers to combine transactions, sponsor gas and introduce more flexible permissions.

A flow that previously required several approvals can sometimes become a single user action. The underlying transactions still happen, but the interface can present the whole operation as one task.

This makes the application responsible for more of the transaction flow.

Gas Can Move Into the Background

Users should not need to understand gas mechanics just to complete a basic action.

Account abstraction supports sponsored transactions, allowing an application or another party to cover transaction costs in supported flows. EIP-7702 also introduces mechanisms for sponsored execution.

The fee still exists. The product can decide how it is handled and presented instead of forcing every user to maintain a balance of the network's native token.

Chain Switching Is Becoming Less Visible

Multichain products add another layer of friction. An asset can be available on one network while the user needs it on another.

Chain abstraction and intent-based systems aim to hide some of this complexity. Instead of selecting networks, managing bridges and handling routing manually, users can express the outcome they want while the infrastructure handles execution.

For developers, this means designing around the user's goal rather than exposing every blockchain step.

Stablecoin Payments Look More Like Fintech

Stablecoins are increasingly being integrated into payment products rather than presented as a separate crypto experience.

Stripe, for example, is expanding infrastructure around stablecoin payments, payouts and cards. The customer-facing flow can remain familiar while blockchain settlement happens underneath.

A payment interface does not need to expose every wallet, network and settlement detail to the customer.

Compliance Is Part of the Product

Regulation also affects product design.

Jurisdiction, identity verification, asset availability and transaction limits can change what a user is allowed to do. Those requirements appear directly in onboarding and transaction flows.

Developers therefore have to account for compliance when designing the product itself, not only during backend implementation.

The Design Problem Has Changed

Crypto products are moving toward a simple model:

User chooses the outcome.
The product handles more of the mechanics.

Passkeys handle authentication. Embedded wallets reduce onboarding friction. Smart accounts handle more complex transactions. Sponsored gas removes one manual step. Chain abstraction hides network differences. Stablecoin infrastructure can make blockchain payments look like ordinary fintech.

The challenge for developers is deciding what to hide and what users still need to see before they approve an action.

The blockchain can stay in the backend without making the product feel opaque.

Your Crypto Wallet Is Not Your Account: Understanding What the App Actually Controls

Azalea — Mon, 21 Sep 2026 23:23:13 +0000

A crypto wallet can look a lot like a regular banking app. You open it, see a balance, copy an address, and press Send.

But your wallet app is not your blockchain account, and your crypto is not literally stored inside the app.

Understanding this difference makes crypto much easier to reason about – especially when something goes wrong.

The wallet is the interface

On Ethereum, an account is an on-chain entity that can hold ETH and tokens and interact with smart contracts. An externally owned account (EOA) is controlled by private keys.

The wallet app is the software you use to interact with that account.

It can:

show your balance by reading blockchain data;
create transactions;
ask you to approve an action;
sign transactions;
broadcast them to the network.

The assets themselves remain recorded on the blockchain. Ethereum's documentation puts it simply: users don't store the cryptocurrency inside the wallet – they control the keys that allow them to act on the account.

So deleting a wallet app does not automatically delete your crypto.

Then what actually gives you control?

For a typical self-custodial wallet, the important pieces are the Secret Recovery Phrase and the private keys.

A recovery phrase can be used to restore the wallet and generate its accounts. Each account has its own private key, which is used to control that particular account.

That's why your wallet password is not the same thing as ownership of the assets.

For example, in MetaMask, a password can unlock the wallet on a device, while the Secret Recovery Phrase is what allows the wallet to be restored.

A useful mental model is:

Wallet app → interface
Account → blockchain identity
Private key → authorization
Blockchain → asset state

Self-custody changes the model

This is also why a self-custody wallet feels different from an exchange account.

With a self-custody wallet, you control the private keys. With a custodial exchange, the platform manages the keys and processes transactions on your behalf.

That creates a very different recovery model.

Forgot your exchange password? There may be a standard account recovery process.

Lost the credentials that control a self-custodial wallet? There may be no company that can simply reset access for you. MetaMask explicitly warns that it cannot recover a wallet when the required recovery credentials are lost.

What happens when you press Send?

The wallet does not physically move coins from one app to another.

Instead, it prepares a transaction and asks you to authorize it. For a traditional Ethereum account, the transaction is signed with the account's private key and then submitted to the network.

The blockchain processes that transaction and updates its state.

This is why crypto security is about more than protecting an app password. The bigger question is:

What exactly are you authorizing with your wallet?

A wallet may be just the interface, but the signature you approve can change what happens to your assets.

One more complication: smart wallets

The private-key model is not the only approach anymore.

Ethereum also supports contract-based accounts, where authorization can be defined by smart-contract code rather than a single traditional private key. This is part of the broader account abstraction model.

So the statement “your wallet is your private key” is useful as a beginner's shortcut, but it is no longer a complete description of every modern wallet.

The simplest way to think about it is this:

Your wallet is the tool you use to access and authorize actions. Your account is the identity on the blockchain. The blockchain records the assets and transactions.

Once these pieces are separated, crypto wallets become much less mysterious – and the security risks become much easier to understand.

What a Crypto App Should Do Before You Press “Send”

Azalea — Tue, 15 Sep 2026 17:22:35 +0000

A crypto transfer can look almost trivial on a phone.

Choose an asset. Enter an address. Type an amount. Press Send.

The blockchain sees something very different.

On Ethereum, a transaction is a signed instruction that can contain a recipient address, value, nonce, gas parameters and input data. Once signed and broadcast, it enters the transaction pool and waits for a validator to include it in a block. Eventually, the block can become finalized.

The interesting part is that the blockchain cannot tell whether the user meant to send the funds to that particular address.

That decision happens before the transaction reaches the network.

This makes the wallet interface more than a convenient way to access a blockchain. It is one of the last places where a human can catch a mistake.

The address is not enough

Wallet addresses are not exactly designed for humans.

An Ethereum address is a hexadecimal string. Copying one from a previous transaction is easier than trying to read it character by character. That convenience creates an opportunity for attackers.

A technique known as address poisoning exploits this behavior.

An attacker creates an address that looks similar to one the victim has used before and sends a transaction designed to make the malicious address appear in the victim's transaction history. If the victim later copies the wrong address from that history, the funds go somewhere else.

A 2025 study that measured address poisoning on Ethereum and BSC over two years identified 270 million attack attempts targeting 17 million victims. The researchers linked 6,633 incidents to at least $83.8 million in losses.

That's a useful reminder that "the user entered the wrong address" is not always a user problem.

Sometimes the interface has made the wrong address too easy to trust.

A wallet should make the recipient difficult to misread.

That can mean showing a recognizable name when one is available, making the beginning and end of the address easy to compare, supporting verified address books, and warning users when a destination looks suspicious or has not been used before.

The final confirmation screen should also show the actual destination, not just a shortened label.

The network should be impossible to miss

"Send USDT" is not enough information.

The asset and the network are separate pieces of information, and the same token can exist across multiple networks.

A useful confirmation screen should therefore make the combination explicit:

500 USDT
Ethereum
To: 0x71...92F4

That seems like a small interface decision, but it removes an entire category of ambiguity.

The same principle applies to mobile apps. A smaller screen creates pressure to hide information behind menus, but transaction confirmation is probably the wrong place to optimize for minimalism.

For a practical look at how mobile crypto apps combine wallet access, transfers, QR codes and transaction management, the ChangeNOW guide to mobile crypto app features is a useful reference.

The goal isn't to show every technical detail.

It is to show the details that can change the outcome.

Show what the transaction will actually cost

Fees are another part of the transaction that should not be left for the user to decode.

On Ethereum, gas measures the computational work required to execute a transaction. A simple ETH transfer requires 21,000 units of gas, while interactions with smart contracts can require considerably more.

The fee also isn't just an arbitrary number produced by the wallet.

Ethereum's fee model includes a base fee and a priority fee. The amount a user ultimately pays depends on gas used and the applicable fee parameters.

A good interface should translate that into something a person can understand:

Sending: 1 ETH
Network fee: 0.00025 ETH
Total deducted: 1.00025 ETH

The user shouldn't have to understand maxFeePerGas before sending money.

That's the wallet's job.

"What am I signing?" is a better question

There is another problem that becomes more important once a wallet does more than simple transfers.

A transaction doesn't necessarily mean:

Send this amount to this person.

It can also mean:

Interact with this smart contract.

Ethereum documentation distinguishes ordinary transfers from transactions that execute deployed smart contracts. In the latter case, the to address can belong to a contract, while the transaction's input data determines what the contract is asked to do.

That changes the UX problem.

Showing a contract address and a button labeled Sign doesn't tell most users much.

For a swap, approval, DeFi interaction or other contract call, the wallet should explain the intended effect in human-readable terms whenever it can.

For example:

You are authorizing:
Swap 500 USDC for ETH

Estimated result:
≈ 0.18 ETH

Network fee:
≈ $1.40

Contract:
Verified contract name, if available

That is much more useful than presenting a wall of hexadecimal data.

Simulation is useful, but it isn't magic

Transaction simulation is becoming an important part of wallet security.

Instead of asking the user to sign first and find out what happened later, a wallet can simulate the transaction and estimate the expected balance changes or contract effects before broadcasting it.

That is a significant improvement in the user experience.

But simulation shouldn't be treated as a guarantee.

A 2026 study of transaction simulation phishing found more than 4,000 phishing contracts deployed between August 2024 and June 2025. The researchers identified more than 5,700 victims and approximately $3.48 million in losses, with 91.5% of those losses occurring on Ethereum.

The problem is subtle.

Some malicious contracts can behave differently during simulation and actual execution because their behavior depends on changing blockchain state. A simulation can therefore show a benign result while the eventual transaction behaves differently.

So the lesson isn't that simulation doesn't work.

It's that one security signal shouldn't become the entire security model.

Simulation is one layer. Address checks, contract reputation, readable signing information and user confirmation are other layers.

Warnings need to tell the user what to do

A red warning isn't automatically a useful warning.

Compare these two messages:

⚠️ Suspicious transaction

and:

⚠️ This is the first time you've sent funds to this address. Verify the full address before continuing.

The second one gives the user a decision to make.

That's important because security warnings often appear at exactly the moment when the user wants to finish the task. If the warning is vague, people are more likely to treat it as another piece of interface noise.

Research on wallet usability shows that this is still a real problem.

A 2025 study evaluated 53 popular Ethereum wallets specifically in the context of address poisoning. The researchers found that 16 wallets created a high risk by displaying fake token phishing transfers, while only three wallets displayed an explicit warning when users attempted to transfer funds to a phishing address.

That doesn't mean those three wallets are universally safe or that the other wallets are universally insecure.

It does show how much room there is for improvement in the way wallets communicate transaction risk.

The confirmation screen is a security feature

The best confirmation screen doesn't need to expose every blockchain parameter.

It needs to answer the questions a user actually has before signing:

What am I sending?

500 USDC

Which network?

Ethereum

Where is it going?

Alice
0x71...92F4

What will it cost?

Estimated network fee: $2.14

What am I authorizing?

Transfer / swap / approval / contract interaction

Did the wallet detect anything unusual?

First-time recipient / suspicious contract / simulation result

Then comes the final action:

Review and Sign

This is a better model than treating confirmation as the last visual step before a button click.

It is a checkpoint.

Good crypto UX should slow you down at the right moment

Most of the time, a wallet should feel fast.

You shouldn't need three screens to send funds to an address you've verified dozens of times.

But when something changes – a new address, a different network, an unusual contract interaction or a potentially risky approval – the interface should become more deliberate.

That's where good crypto UX differs from simply making transactions faster.

The objective isn't to remove friction everywhere.

It is to remove unnecessary friction while keeping the friction that helps a user catch an expensive mistake.

A blockchain will execute a valid signed transaction because the signature is valid. It doesn't know what the user intended to do.

The wallet sits between those two worlds.

That makes the Send screen one of the most important security surfaces in a crypto application.

The best crypto app isn't necessarily the one that gets you from balance to transaction hash in the fewest taps.

It's the one that gives you a good reason to pause before the tap that actually matters.

AI Agents Can Make Payments. The Hard Part Is Proving They Should.

Azalea — Mon, 14 Sep 2026 15:58:13 +0000

AI agents are moving beyond answering questions and recommending products. They can already search for items, compare options, interact with merchants and, in some cases, complete purchases on a user's behalf.

That creates a problem payment systems were not originally designed for: how does a merchant know that an AI agent is actually authorized to make a particular payment?

This is becoming an infrastructure problem, not just an AI problem.

In September 2026, Ant International, Mastercard and Visa announced that they had started working on a shared Know Your Agent (KYA) interoperability framework. The goal is to help payment networks, wallets, agent platforms and marketplaces identify and verify AI agents while allowing each participant to maintain its own risk and approval processes.

The interesting part is not the name KYA. It is the trust layer that has to sit between an AI agent and a financial transaction.

The payment flow is changing

A conventional online purchase is relatively straightforward:

User → Merchant → Payment Provider → Bank/Card Network

An agentic transaction adds another layer:

User → AI Agent → Merchant → Payment Infrastructure

The agent may be acting on the user's behalf, but the merchant still needs to understand what that authority actually means.

Suppose a user tells an agent:

Find a laptop under $1,500 with at least 16GB of RAM and buy it if you find a suitable one.

The agent has to search, compare products, choose an option and potentially complete the purchase without asking the user to approve every step.

The payment system needs more than an answer to “Is this a real agent?”

It needs to know who authorized it, what it was authorized to do and whether the final transaction stays within those limits.

Identity is only the first layer

Visa, Mastercard and Ant International already have technologies aimed at different parts of this problem.

Visa's Trusted Agent Protocol is designed to help merchants verify AI agents and establish the context of their requests.

Mastercard has been developing Verifiable Intent, which focuses on verifying that an agent's action corresponds to an instruction authorized by the user.

Ant International has developed its own Agentic Mobile Protocol for transactions involving digital wallets.

The new KYA initiative is therefore not simply about creating another payment method. It is about making different agent ecosystems work together.

That interoperability could become important for developers. If every payment network, wallet and marketplace uses a different system for agent identity and authorization, developers could end up maintaining another fragmented set of integrations.

A common set of trust signals could reduce that complexity while allowing individual networks to keep their own risk controls.

Authentication does not mean authorization

This is where the architecture gets more interesting.

Imagine an agent is successfully authenticated. The payment system knows which agent it is and who operates it.

That still does not answer the most important question:

What is the agent actually allowed to do?

A useful way to think about the problem is to separate four layers:

Agent Identity
      ↓
User Authorization
      ↓
Transaction Intent
      ↓
Execution + Monitoring

Each layer answers a different question.

Identity: Who is this agent?

Authorization: Which user or organization delegated authority to it?

Intent: What action was the agent authorized to perform?

Execution: Did the final transaction stay within those limits?

This separation matters because a legitimate agent can still make an unauthorized transaction.

For example, an agent might have permission to spend up to $1,500 but attempt to complete a $1,900 purchase after the final price changes.

The identity check would pass. The authorization check should not.

Spending permissions may become part of the API

For developers, this could eventually mean that an AI agent's payment credentials look less like a traditional card number and more like a set of constrained permissions.

Conceptually:

Agent: shopping-agent-42
User: verified-user
Maximum transaction: $1,500
Allowed category: Electronics
Allowed merchants: Approved merchants
Expiration: 24 hours
Additional approval: Required above limit

The exact implementation will vary by payment network, and the KYA framework is still being developed. There is no universal schema that developers can simply implement today.

But the underlying design problem is already clear.

Agents need enough authority to be useful without receiving unrestricted access to a user's money.

The same problem is appearing elsewhere

This is not limited to Visa and Mastercard.

India's National Payments Corporation is reportedly developing a registry for AI agents that will make transactions through UPI. The initial focus is on frequent, relatively small payments, with more complex use cases potentially coming later.

The direction is becoming clear: once an AI system can initiate financial transactions without a user manually approving every step, agent identity and delegated authority become part of payment infrastructure.

That also changes the security model.

A compromised card is one problem. A compromised agent with permission to make hundreds of transactions could be a very different one.

What happens when the agent gets it wrong?

This may be the hardest part of the problem.

Authentication and authorization can be implemented as technical mechanisms. Liability is harder.

Imagine an agent follows a user's instruction but misunderstands the product. Or a merchant's page contains content designed to manipulate the agent. Or the agent makes a purchase after its authorization should have expired.

Who is responsible?

The user?

The agent provider?

The merchant?

The payment network?

The answer will influence how these systems are designed.

There are other open questions too: how quickly permissions can be revoked, how transactions are audited, what information merchants actually need to see and how privacy is maintained when several systems exchange identity and authorization data.

These issues become more serious when agents operate at machine speed.

A human might notice a suspicious purchase after one transaction. An automated system could repeat the same mistake many times before anyone intervenes.

The next payment layer may be a trust layer

Payment infrastructure is starting to account for an actor that is neither a traditional customer nor simply a machine.

An AI agent represents a person or business, interprets their instructions and takes actions on their behalf.

Payment systems therefore need to establish more than whether a transaction is technically valid.

They need to establish whether the agent had the right to make it.

That is why KYA is worth watching. The framework is still being developed, and there is no universal standard yet. But the direction is clear: agent identity, authorization, intent, permissions and auditability are becoming part of the conversation as AI moves from recommending actions to executing them.

The difficult part of agentic payments may not be teaching AI how to transact.

It may be building systems that can prove when it should.

MiCA After July 2026: What Actually Changes for Crypto Users and Developers

Azalea — Thu, 10 Sep 2026 15:26:35 +0000

MiCA After July 2026: What Actually Changes for Crypto Users and Developers

For a long time, MiCA was something crypto companies talked about as a future compliance problem.

That future has arrived.

The EU's Markets in Crypto-Assets Regulation has been fully applicable since December 2024, but 2026 was an important transition point for crypto-asset service providers. By July 1, 2026, the transitional period for firms operating under previous national regimes had ended at EU level. After that date, a provider offering crypto-asset services in the EU generally needs to operate under the MiCA framework or another applicable legal basis.

For developers, this changes the way compliance fits into a crypto product. It is no longer something that can sit entirely with the legal team. In many cases, regulatory requirements eventually become product requirements, database fields, API checks and user flows.

And for users, those changes are much more visible than the regulation itself.

MiCA is more than a licensing framework

MiCA creates a harmonised EU framework for crypto-assets and the companies that issue them or provide related services. It covers areas including crypto-asset service providers, stablecoins, disclosure, market conduct and consumer protection.

A developer does not need to read hundreds of pages of regulation to understand the practical idea.

If a platform is doing something with crypto on behalf of its users, the first question is increasingly:

What exactly is the service, and under which regulatory framework is it allowed to operate?

That question affects exchanges, custodians, brokers, wallet-related services and other crypto businesses.

It also affects how products are designed.

Consider a simple withdrawal flow.

Before regulatory requirements become product requirements, the flow might look like:

User → Enter address → Confirm → Transaction sent

In a regulated environment, the actual flow can be more complicated:

User
↓
Enter destination
↓
Compliance checks
↓
Additional information if required
↓
Risk decision
↓
Transaction processing

The blockchain transaction itself has not changed.

The surrounding software has.

July 1, 2026 changed the practical landscape

The end of the transition period is one of the most relevant dates for anyone building or using a crypto service in the EU.

ESMA stated that the transitional period would expire across the EU on July 1, 2026. After that point, firms providing crypto-asset services without the required authorisation can no longer rely on the old transitional arrangements.

That does not mean every crypto company suddenly disappeared on July 1.

It means the legal basis for providing regulated crypto services became much clearer.

For product teams, that creates a fairly practical task: the service needs to know where it is allowed to operate, what authorisation covers it, and what happens when a user falls outside the supported regulatory scope.

This is where regulation starts looking less like a legal document and more like system architecture.

What does this mean for crypto users?

The biggest change for an ordinary user is not likely to be a message saying "MiCA compliance enabled."

It is more likely to be another verification step.

A platform may ask for additional information during onboarding. A transaction may require an additional compliance check. A withdrawal to a self-hosted wallet may involve questions that did not appear in the same form before.

These processes are not all caused by MiCA alone. Crypto businesses also operate under broader AML/CFT and transfer-of-funds requirements.

But from a user's perspective, they can appear in the same place: the interface.

That is why understanding the practical side of MiCA is often more useful than simply knowing what the acronym stands for. A practical overview of the regulation, its licensing framework, stablecoin rules and the way compliance can affect users is available in this guide to MiCA.

The important part is not that users should expect every transaction to trigger a check.

They should understand why a regulated platform may sometimes need more information before processing one.

Self-custody is a different case

One of the easiest things to misunderstand about European crypto regulation is self-custody.

If you hold the private keys to your wallet, that does not automatically turn your wallet into a regulated crypto service.

MiCA is primarily concerned with regulated activities and intermediaries. A user controlling their own assets is different from a company holding or transferring crypto-assets on behalf of clients.

This distinction becomes especially important when designing wallet products.

A developer building a non-custodial wallet is not necessarily building the same regulatory product as a company providing custody.

The interface may look similar.

The legal responsibilities can be very different.

There is also another layer to consider: a self-hosted wallet does not make compliance obligations disappear when it interacts with a regulated service. A user may still encounter additional checks when moving assets between a regulated provider and a self-hosted address, depending on the transaction and the applicable AML/transfer-of-funds requirements.

So "self-custody" should not be treated as a synonym for "outside regulation."

Stablecoins have their own regulatory logic

MiCA also treats stablecoins differently from many other crypto-assets.

The framework distinguishes between asset-referenced tokens and e-money tokens, with specific requirements around issuance, governance, reserves and information provided to users. The European Commission describes these requirements as part of MiCA's prudential and consumer-protection framework.

This matters technically because stablecoins are increasingly used as infrastructure rather than simply as trading assets.

They can sit inside:

payment flows
treasury systems
exchange infrastructure
settlement systems
trading applications
automated financial workflows

When an asset becomes part of infrastructure, its regulatory status becomes an engineering concern too.

For example, a payment application may need to know whether a particular token can be offered to EU users, whether the relevant issuer meets the applicable requirements, and what restrictions apply to the service built around it.

The smart contract does not answer those questions.

The product architecture has to.

Compliance becomes an engineering problem

This is probably the most interesting consequence of MiCA for developers.

Regulatory requirements eventually become software.

A legal requirement can turn into:

if provider_is_authorized:
allow_service()
else:
restrict_service()

A reporting obligation can become an event pipeline.

A customer verification requirement can become an onboarding state machine.

A risk-control requirement can become a transaction screening service.

An audit requirement can become structured logs that cannot simply be deleted after the transaction is complete.

None of this means developers should try to translate legislation into code by themselves.

It means engineering teams increasingly need to understand the assumptions behind the systems they are building.

A compliance rule that arrives at the end of development is expensive.

A compliance requirement considered during architecture is usually much easier to handle.

How should developers think about a MiCA-ready product?

I would start with four questions.

1. What service are we actually providing?

"Crypto platform" is too vague.

Are you providing custody? Exchange? Execution? Transfers? Advice? Something else?

The answer determines which regulatory questions matter.

2. Who is the user?

Geography is not just a marketing parameter anymore.

If the product is available to EU users, the team needs to understand whether the service falls within MiCA or another regulatory framework.

3. Where does compliance happen?

If the answer is "somewhere in the backend," that is probably not enough.

Developers should know which API, service or workflow makes the relevant decision and what happens when the decision is negative or inconclusive.

4. Can the system explain what happened?

This is easy to overlook.

A compliance system that simply returns true or false may not be enough for a real production environment. Teams may need an auditable record of which checks were performed, when they were performed and what information was used.

That is where good engineering practices become particularly valuable.

MiCA is not finished yet

There is another reason not to treat MiCA as a completely finished rulebook.

The European Commission is currently reviewing the regulation and is consulting stakeholders on whether MiCA remains fit for purpose in light of implementation experience and developments in crypto markets and policy. The Commission's targeted consultation is open until September 30, 2026.

So the regulatory environment is still evolving.

That is not necessarily a bad thing.

Crypto infrastructure is changing quickly, and regulation built around an earlier version of the market will inevitably need to be tested against new products, stablecoins, tokenisation models and financial applications.

For developers, this means one thing above all: avoid building compliance assumptions too deeply into the product.

Make them configurable where possible.

Keep regulatory logic separate from core transaction logic.

Document why a particular restriction exists.

And make it possible to update the system when the rules change.

The practical takeaway

MiCA is often discussed as a question of licences and regulation.

For developers, the more interesting question is what happens after the licence is obtained.

The real work moves into product design.

Who can access the service?
Which assets can be offered?
When is additional verification required?
How are transactions screened?
What information has to be stored?
How can the system demonstrate what happened?

Those are software questions as much as legal ones.

And that may be the biggest shift MiCA brings to European crypto infrastructure: compliance is becoming part of the product itself, rather than something that happens around the product.

Claude in Fintech: 5 Workflows Where AI Agents Can Actually Save Time

Azalea — Wed, 09 Sep 2026 17:12:06 +0000

Financial teams have plenty of work that looks small on paper and takes hours in practice.

A compliance analyst may need to review a customer file, collect information from several documents, check transactions, prepare a case summary, and then pass everything to another person for review. The same pattern appears in financial research, fraud investigations and reporting.

This is where AI agents are becoming more interesting than a basic chatbot.

Anthropic has introduced financial-services agents that can work across multi-step tasks, use external tools and data, and keep a human involved before an important action is taken. The company has also announced integrations with financial data providers and examples involving KYC, fraud, financial research, modelling and AML investigations.

Here are five workflows where that approach can reduce manual work.

1. KYC and customer due diligence

KYC is a natural candidate for workflow automation because the work often starts with documents and ends with a reviewable case.

Anthropic lists KYC screening among its financial-services agent templates. The workflow can involve building an entity file, reviewing source documents and preparing an escalation package for a compliance professional.

The interesting part is what happens between those steps.

An agent can work through the available material and organize the relevant information before a compliance analyst makes the final call. That leaves the person with a prepared case instead of a collection of documents that still needs to be sorted manually.

There is a concrete example from Parcha. According to Anthropic, the company used Claude for customer due diligence and reduced one workflow from three months to five minutes.

That figure comes from a specific customer case, so it should not be treated as a general benchmark for KYC teams. Still, it shows why document-heavy compliance work is being considered for agentic systems.

2. Fraud investigation

Fraud detection is another area where the investigation itself can involve a lot of repetitive work.

A suspicious case may require looking at transaction information, documents and other risk signals before an analyst can understand what happened. An AI agent can help assemble that context and produce a case summary for review.

Inscribe is one example cited by Anthropic. The company uses Claude for fraud detection, document verification, risk analysis and KYC/KYB checks. Anthropic reports that the time required for a fraud review went from 30 minutes to 90 seconds in the cited case.

In another customer example, Inscribe reported a 70-fold increase in processing output.

Again, these are company-specific results rather than an industry-wide measurement. They are useful mainly because they show the type of work being delegated to an AI system: collecting and assessing information around a fraud case, rather than simply generating a piece of text.

That distinction matters.

A fraud analyst still needs to understand the evidence and decide what should happen to the case. The agent can take care of part of the preparation.

3. Financial research

Financial research presents a slightly different problem.

The difficult part is often not writing the final report. It is getting the right information first.

Anthropic has connected Claude with financial research and data platforms including FactSet, S&P Capital IQ, MSCI, PitchBook, Morningstar, LSEG and Daloopa. Other connectors include Dun & Bradstreet, Fiscal AI and Financial Modeling Prep.

A research workflow can therefore look something like this:

Research question → financial data → analysis → draft report → analyst review

The model does not need to rely entirely on information already inside the model. It can work with external sources provided through the available tools.

This also connects with research from the Bank for International Settlements. BIS has discussed the use of generative AI in economic analysis, financial supervision and payment oversight, and has pointed to retrieval-augmented generation (RAG) as one way to improve the reliability of outputs by connecting models with verified and specialized information.

Cabe destacar one practical point here: source access does not remove the need to check the result. It changes where some of the manual work happens.

Instead of searching through several systems and then starting the analysis from scratch, an analyst can review the material assembled by the workflow.

4. Financial models and reporting

Spreadsheets are another place where AI assistance can fit into an existing financial workflow.

Anthropic says Claude can work with Excel, PowerPoint and Word through Microsoft 365 add-ins. Context can also move between applications. For example, work started in a financial model can continue when preparing a presentation.

Citadel is one of the examples Anthropic gives. Its investment professionals use Claude for Excel to create and update coverage models, separate signal from noise and pressure-test their work.

The useful part here is not simply asking an AI to “analyze an Excel file.”

A more practical workflow is closer to:

Financial model → analysis → scenario work → checks → summary → presentation

Some of those steps are repetitive. Others require financial judgment.

The division between them is important. A model can help with the preparation and analysis while the professional remains responsible for the financial interpretation.

5. AML and compliance investigations

AML investigations combine several of the problems found in the other workflows: large amounts of information, repeated checks and a need to document what happened.

Anthropic says FIS is working with the company on an agent intended to reduce AML investigations from days to minutes. The companies are also working on agents for areas including credit decisioning, fraud prevention and deposit retention.

The proposed workflow is fairly straightforward:

Alert → gather relevant information → review transactions and context → organize evidence → prepare the case → compliance review

The last step should not be overlooked.

Financial institutions operate in an environment where decisions can have regulatory and customer consequences. An agent preparing an investigation is a different proposition from an agent independently deciding what happens to an account.

That is one reason human review remains part of the financial-services agent model described by Anthropic.

Where should the human stay in the workflow?

This is probably the most important part of the discussion.

The Financial Stability Board has identified several risks associated with AI in financial services, including model risk, data quality, cyber risk, third-party dependencies and concentration around service providers.

The FSB has also noted that generative AI in financial institutions has so far been used heavily for operational efficiency.

That suggests a practical way to think about agentic AI in finance.

For a lower-risk task, an agent might prepare a draft that someone checks.

For an investigation, it might gather evidence and organize the case before a specialist makes the decision.

For a consequential financial or compliance decision, the level of human oversight needs to be much higher.

The Office of the Comptroller of the Currency, together with the Federal Reserve and FDIC, issued revised model risk management guidance in 2026. The guidance emphasizes areas such as validation, monitoring, governance, access controls, data management and auditability. It also notes that generative and agentic AI are developing quickly and are not directly within the scope of that particular guidance.

So the regulatory picture is still developing.

What makes a good fintech AI workflow?

Looking at these examples, a pattern appears.

The strongest candidates for agentic workflows tend to involve:

repetitive manual steps;
large amounts of financial or documentary information;
several tools or data sources;
outputs that can be reviewed;
a clear point where a human takes responsibility.

That does not mean every financial process should become autonomous.

Quite the opposite. For regulated work, knowing where the agent stops can be just as important as knowing what it can do.

The practical takeaway

Claude's financial-services use cases are mostly interesting when they are treated as workflows rather than isolated AI features.

KYC can involve document review and case preparation. Fraud teams can use AI to speed up investigations. Researchers can connect Claude with financial data providers. Analysts can work with financial models and reporting tools. AML teams can use agents to prepare investigation material.

The common thread is fairly simple: the agent handles part of the work around a decision, while the professional remains responsible for the decision itself.

For fintech teams, that may be a more useful starting point than asking whether AI can replace an entire role.

Sometimes saving time means removing the five steps nobody wanted to do manually in the first place.

When AI Agents Start Moving Money: Who Controls the Wallet?

Azalea — Fri, 04 Sep 2026 16:14:21 +0000

AI agents are getting better at doing things on their own.

They can search for information, call APIs, compare options, run workflows and make decisions without someone sitting there approving every step.

But there is one step that makes all of this much more interesting:

What happens when the agent needs to pay for something?

Imagine an agent that needs a data API. The API costs a few cents per request.

A human could create an account, add a card and manage a subscription.

But if the whole point of the agent is to work independently, asking a person to approve every $0.05 payment doesn't make much sense.

This is where agent payments and crypto wallets start to get interesting.

The wallet changes the equation

With protocols such as x402, an agent can request a paid resource, receive the payment requirements and make a stablecoin payment as part of the request flow.

That sounds convenient.

And technically, it is.

But I think the more interesting question is not:

“Can an AI agent pay?”

It is:

“How much should an AI agent be allowed to pay?”

Those are very different questions.

Giving an agent access to a wallet doesn't mean it should have access to everything in it.

A more reasonable setup might look something like this:

Main wallet
↓
Limited agent wallet
↓
Spending rules
├── $5 per transaction
├── $20 per day
├── USDC only
└── Approved services

The agent gets enough freedom to do its job, but not enough freedom to drain the account if something goes wrong.

And something can go wrong.

AI mistakes become financial mistakes

An AI agent can misunderstand instructions.

It can follow a malicious prompt.

It can interact with the wrong service.

It can make a bad decision based on incorrect information.

Normally, the result might be a bad answer or a failed task.

Give the same system access to money, and the failure mode changes.

Now the agent can make a transaction.

That makes financial permissions a different kind of AI safety problem.

A useful way to think about it is:

The agent shouldn't own the money. It should operate within a set of permissions.

That could mean transaction limits, approved addresses, specific assets, spending periods or human approval for unusual transactions.

Small recurring payments could happen automatically.

Larger or unusual payments could require a person.

That gives the agent autonomy without making it financially unrestricted.

What about one agent paying another?

This gets even more interesting.

Imagine two agents.

Agent A needs market data.

Agent B provides it.

Instead of a human creating an account and paying a monthly subscription, Agent A could simply pay Agent B for the data it actually uses.

Agent A
↓
requests data
↓
Agent B
↓
$0.05 payment
↓
data returned

This is one reason agentic payments are being discussed alongside technologies for agent identity and reputation.

Payment answers one question:

“Did the money move?”

It doesn't answer:

“Who am I paying?”

“Should I trust this agent?”

That's where projects such as ERC-8004 become relevant. The standard focuses on identity, reputation and validation for agents that need to interact without relying entirely on pre-existing trust.

So the architecture starts looking less like a simple wallet and more like:

Agent
├── Wallet
├── Permissions
├── Identity
├── Reputation
└── Spending limits

And there is still one question that is harder than all of these.

Who is responsible?

Suppose an agent is allowed to spend $20 per day.

It makes a mistake and spends the full amount on the wrong services.

Who is responsible?

The user?

The developer?

The wallet provider?

The payment provider?

There isn't always an obvious answer.

And this is why I think autonomous payments are less about giving AI access to money and more about designing boundaries around that access.

We already know how to make software execute transactions.

The harder part is deciding what software should be allowed to do.

For me, the interesting architecture is not:

AI → unlimited wallet

It's:

Human → controlled wallet → limited permissions → autonomous agent

The agent gets enough freedom to be useful, but the financial consequences of its mistakes remain bounded.

Maybe that's what agentic payments will ultimately need.

Not completely autonomous money.

Controlled autonomy.

What would you personally allow an AI agent to pay for without asking you first?

An API call?

Cloud compute?

A subscription?

Or would you still want to approve every transaction?

ai #crypto #fintech #web3

ZEN in Practice: How the Horizen Token Fits Into the Ecosystem

Azalea — Wed, 02 Sep 2026 23:19:48 +0000

In my previous post, I looked at Horizen from a technical perspective and focused on its move toward an EVM-compatible Layer 3.

This time, I want to look at the other side of the network: what ZEN is actually used for and how it fits into the current Horizen ecosystem.

There is one detail worth clearing up first.

ZEN and Horizen are not the same thing.

Horizen is the network and infrastructure. ZEN is its ecosystem token.

That distinction becomes more important after the project's move to Base.

ZEN is no longer a traditional mining coin

Older Horizen guides often talk about mining ZEN with GPUs and the Equihash Proof-of-Work algorithm.

That information is now outdated.

In July 2025, ZEN was migrated from the legacy Horizen mainchain and EON to Base as an ERC-20 token. The old chains were subsequently discontinued.

The maximum supply remains capped at 21 million ZEN, but the way the token is used has changed along with the network.

So if you find an old tutorial explaining how to mine ZEN, it's worth checking the publication date before following it.

What is ZEN used for?

ZEN has several roles within the current ecosystem.

It serves as the main ecosystem and governance token and can be used in applications built around Horizen.

More recently, staking has also become part of the network's current model. ZEN staking on Horizen Mainnet opened in July 2026. Users can move ZEN to Horizen and stake it there, while the network uses ETH rather than ZEN for transaction fees.

That last part is easy to miss.

You don't need ZEN to pay gas on Horizen. You need ETH.

This is similar to what users may already know from other EVM networks.

ZEN has its own role in the ecosystem, while ETH handles transaction fees.

Holding ZEN is a little different now

Because ZEN exists within an EVM environment, it can be held using wallets that support Base and Ethereum-compatible assets.

But there is an important distinction between holding ZEN on Base and using it on Horizen.

ZEN can be bridged between Base and Horizen, including through Stargate and LayerZero's Omnichain Fungible Token infrastructure.

So before sending ZEN, the network matters.

It's not enough to check that the wallet address looks correct. You also need to make sure the destination network and token version match what you're trying to do.

This is one of those small details that can prevent a very expensive mistake.

What about the ecosystem?

The interesting part of Horizen isn't just the ZEN token.

The network is being positioned around applications that need a combination of EVM compatibility, privacy and compliance-oriented functionality.

That gives ZEN a role inside a broader ecosystem rather than making the token the whole story.

For developers, this is probably the more useful way to look at it.

Instead of asking only:

“Why would someone hold ZEN?”

it's worth asking:

“What applications actually need the Horizen ecosystem?”

If privacy-focused DeFi, payments, identity or other onchain applications gain traction, the utility of the surrounding infrastructure becomes much more relevant.

Storage is mostly about the network, not just the wallet

When people talk about storing a crypto asset, they often focus on the wallet itself.

With ZEN, the network is just as important.

ZEN on Base is an ERC-20 token. When using ZEN on Horizen, the token can be bridged to the Horizen environment.

That means a wallet can show a ZEN balance while the user still needs to understand which network that balance belongs to.

The same wallet address format can make this less obvious than it should be.

For anyone moving ZEN between networks, checking the network, token contract and receiving address before confirming a transaction is a basic but important step.

So, is ZEN still a privacy coin?

Not in the way older descriptions might suggest.

ZEN itself is now an ERC-20 token on Base and does not provide private transactions simply because someone holds or transfers it.

Privacy is instead part of Horizen's broader application and infrastructure direction.

That's an important distinction because searching for information about ZEN can still bring up older explanations based on the project's previous architecture.

The bigger picture

What I find interesting about ZEN is how much the token's role has changed without changing its basic identity.

It started as the native asset of a Proof-of-Work blockchain.

Today, it exists as an ERC-20 token connected to an EVM-compatible Layer 3 ecosystem built on Base.

The practical questions are therefore different now:

Where is the token held?

Which network is it on?

What does it do inside the ecosystem?

And which applications actually create demand for the infrastructure around it?

Those questions are probably more useful than simply looking at ZEN as another crypto asset.

For anyone who wants the broader background on the token, its history, current network setup and practical considerations, I also put together a more detailed Horizen (ZEN) review.

crypto #blockchain #web3 #fintech #ethereum #developers

Horizen (ZEN): Why This Blockchain Is Taking a Different Approach

Azalea — Tue, 01 Sep 2026 22:58:40 +0000

When people hear “Horizen,” privacy is probably one of the first things that comes to mind.

That makes sense. Privacy has been a central part of the project's identity for years.

But Horizen has changed quite a bit, and its current architecture looks very different from the network many people may remember.

Today, Horizen is an EVM-compatible Layer 3 built on Base using the OP Stack. That shift makes it interesting not only as a crypto project, but also from a developer's perspective.

From a standalone blockchain to an Ethereum-based L3

Horizen originally developed its own blockchain infrastructure around a mainchain and sidechains, with a strong focus on privacy and scalability.

The project later moved toward an EVM-based ecosystem and eventually migrated ZEN to Base.

The current Horizen Chain is an L3 that settles on Base, which itself is an Ethereum Layer 2.

The idea is fairly straightforward: instead of building every part of the infrastructure from scratch, Horizen can use an existing Ethereum-compatible stack while focusing on features specific to its own ecosystem.

For developers, that means a much more familiar environment.

The EVM part is important

One of the biggest practical advantages is compatibility with the Ethereum Virtual Machine.

Horizen uses a near-standard EVM, so developers can work with familiar tools, smart contracts and development frameworks.

That matters more than it might sound.

A new blockchain can have interesting technology, but if developers have to learn an entirely new programming model and tooling ecosystem, adoption becomes much harder.

With an EVM-compatible environment, developers who already know Ethereum or Base can transfer much of that knowledge to Horizen.

So where does privacy come in?

This is probably the most interesting part.

Horizen hasn't simply abandoned its original focus on privacy. Instead, privacy is being approached more as an application-level capability.

The goal is to make it possible to build applications where transactions or computations can remain verifiable without necessarily exposing every piece of underlying information.

That can be useful for areas such as:

financial applications
identity
payments
compliance
confidential data
DeFi

This is becoming a bigger issue across the blockchain industry.

Public blockchains are excellent at transparency and verification, but complete transparency isn't always desirable.

A financial application, for example, may need to prove that a transaction follows certain rules without making every piece of sensitive information publicly available.

That's where privacy technologies and zero-knowledge proofs become particularly interesting.

What about ZEN?

ZEN is the native token associated with the Horizen ecosystem.

Its infrastructure has changed alongside the network.

Following the migration, ZEN is represented as an ERC-20 token on Base, rather than operating as the native asset of the old Horizen mainchain.

That change is significant because it places ZEN inside a much broader Ethereum-compatible environment.

It also makes the distinction between the token and the underlying network more important.

ZEN is the asset, while Horizen is the infrastructure being built around it.

Why the L3 model is interesting

The L3 approach isn't simply about adding another layer to the blockchain stack.

It allows Horizen to specialize.

Base provides the underlying settlement environment, while Horizen can focus on its own execution environment and privacy-oriented functionality.

The OP Stack also separates different parts of the system, including execution, sequencing, data availability and settlement.

For developers, this modularity can make the architecture easier to reason about than a completely independent blockchain with every component designed from scratch.

But technology alone isn't enough

This is where I think Horizen becomes particularly interesting to watch.

The technical architecture is only one part of the equation.

An EVM-compatible L3 can provide familiar tooling. Privacy technology can solve real problems. Lower transaction costs can make applications more accessible.

But ultimately, developers need reasons to actually build on the network.

The interesting question isn't whether Horizen has a different architecture.

It's whether that architecture can support applications that benefit from combining EVM compatibility with privacy and compliance-oriented features.

That's something adoption will have to answer.

The bigger picture

Horizen is a good example of how blockchain projects can evolve rather than remain tied to their original architecture.

The project started with a strong focus on privacy and its own blockchain infrastructure.

Today, it is building an EVM-compatible L3 on Base while continuing to focus on privacy-oriented applications.

For developers, that makes Horizen less about “another cryptocurrency” and more about an experiment in combining familiar Ethereum tooling with a different approach to privacy.

Whether that model becomes widely adopted remains to be seen.

But the direction is definitely worth watching.

crypto #blockchain #web3 #ethereum #fintech #developers

What a Public Crypto Wallet Can Reveal

Azalea — Tue, 18 Aug 2026 10:51:10 +0000

A public crypto wallet can become much more than a place to hold funds.

Changpeng Zhao recently said he would stop using a wallet that had become closely watched by traders. The address attracted attention because people were tracking its activity and trading around token burns made from the wallet. One trader reportedly turned a small position into a much larger one by following those transactions.

The interesting part for developers is how little information is required to create this kind of trading signal.

A blockchain address does not need to reveal a person's name. Once the address becomes associated with a known person, company or project, its transaction history can be monitored automatically.

The data is already public.

A simple monitoring service can watch an address for incoming and outgoing transactions. It can record the asset, amount, destination and timestamp, then send an alert whenever something changes.

The difficult part is often the interpretation.

A transfer to another wallet does not necessarily mean a sale is coming. A transfer to an exchange may have several possible explanations. A token burn can have a clearer market effect, especially when other traders already know who controls the address.

This is what happened around CZ's wallet.

According to reporting on the incident, traders were watching his activity closely enough to react to token burns almost immediately. One trader reportedly made around $282,000 after buying a token shortly after CZ burned tokens from the wallet.

For a developer, the basic monitoring code is fairly easy to imagine.

Subscribe to new blocks or transactions. Check whether the wallet address appears. Store the event. Compare it with previous activity. Send an alert when the transaction matches a predefined rule.

The same pattern can be used for portfolio tracking, compliance monitoring, treasury management or market research.

It can also turn a public wallet into a source of trading signals.

That creates an unusual privacy problem.

The blockchain itself may contain no personal information about the wallet owner. Applications built around the blockchain can add that context from other sources.

A public ENS name can connect an address to a person. A social media post can reveal which wallet belongs to a project. An exchange transaction can provide another link between an address and an identity.

Once several pieces of information are connected, the transaction history becomes much easier to interpret.

Developers building wallet-based applications should account for this from the beginning.

A product that displays a user's wallet address alongside their profile may expose more information than the user expects. A portfolio tracker that makes wallet activity searchable can make years of transaction history easier to analyze.

The underlying blockchain does not change in either case.

The application changes the accessibility of the data.

This is also why public addresses should be treated differently from ordinary usernames.

A username can be changed. A blockchain address carries its history with it. Once an address is publicly associated with someone, moving to a new address may stop future activity from appearing there, but the old history remains available.

CZ's decision shows how this can play out in practice. His old wallet became so closely watched that routine token activity could attract traders almost immediately. He has now said he will stop using the address and transferred its remaining assets to Giggle Academy.

For developers, the case raises a useful question: how much context should an application add to data that is already public?

Blockchains provide the transaction history. Developers decide how easy it becomes to search, connect and act on that history.

That distinction matters for both security and privacy.

Sources

Disclosure: AI was used to assist with the initial draft. The final text and factual claims were reviewed by the author.

Tags: #blockchain #web3 #security #cryptocurrency

Stablecoin Payments Are Becoming a Developer Problem

Azalea — Fri, 14 Aug 2026 11:19:22 +0000

Stablecoins have spent years inside crypto trading. Their role in payments is becoming much more interesting.

Yellow Card recently raised $40 million to expand its stablecoin infrastructure across Africa. The company provides infrastructure for businesses that need to move money across markets, where traditional payment systems can be fragmented and expensive.

The funding itself is less interesting than the type of infrastructure being built around stablecoins.

A cross-border payment starts with a simple requirement: move a specific amount of value from one party to another.

The underlying system has to deal with several more problems.

Which stablecoin should be used? Which blockchain should carry the transaction? How does the recipient receive the funds? Where does the conversion into local currency happen?

These decisions become part of the software architecture.

A developer building a stablecoin payment system therefore has to think beyond the token contract.

The application needs to identify the network used for each transaction and monitor the blockchain for incoming transfers. It needs to distinguish a confirmed payment from a transaction that has only been broadcast.

The accounting layer has another job.

A merchant may price an order in local currency while the customer pays in USDT or USDC. The system needs to record the original amount, the asset, the network and the exchange rate used for settlement.

A payment can look simple from the user's perspective while several separate systems process it underneath.

The conversion step can create another dependency.

A merchant accepting stablecoins may eventually need local currency. That requires access to liquidity and an off-ramp capable of settling funds into the merchant's banking system.

This is where stablecoin infrastructure starts looking more like traditional fintech infrastructure.

Wallets and blockchains handle the movement of value. Payment processors handle transaction logic. Liquidity providers and exchanges connect digital assets with local currencies. Compliance systems monitor transactions and screen counterparties.

The developer has to connect these pieces without making the user understand how each one works.

Africa provides a particularly useful environment for testing this model because cross-border payments involve many currencies and financial systems.

A stablecoin can provide a common settlement asset across those markets. The application still has to solve the local part of the transaction.

That means stablecoins do not remove the need for payment infrastructure. They change where some of the infrastructure sits.

The blockchain handles settlement. The application handles routing, accounting, verification and the user experience.

This also changes how developers should evaluate blockchain networks.

Transaction fees matter. So do confirmation times, wallet support, liquidity and the availability of reliable APIs. A network with low fees can still create problems if exchanges, wallets or payment providers do not support it.

The same applies to stablecoins.

USDT and USDC may both represent a dollar value, but they can exist on different networks and have different liquidity depending on the market.

A payment application cannot treat the asset name as sufficient information.

It needs to know the asset, the network and the destination.

That sounds like a small implementation detail. At scale, it becomes part of the entire payment flow.

The $40 million raised by Yellow Card points toward a market where stablecoins are becoming infrastructure for moving money between financial systems.

For developers, the interesting part is what gets built around the stablecoin once the token itself becomes easy to move.

The next generation of crypto payment products may depend less on creating new assets and more on making existing digital dollars work smoothly across wallets, blockchains, exchanges and local financial systems.

Sources

Yellow Card, Yellow Card Raises $40M Series C to Expand Stablecoin Infrastructure

Reuters, Stablecoin payment infrastructure and African fintech

Chainalysis, The State of Stablecoins

Circle, Stablecoin and Payments Infrastructure

Disclosure: AI was used to assist with the initial draft. The final structure, wording and factual claims were reviewed by the author.

TRON’s USDT Growth Is Changing What Developers Build Around

Azalea — Tue, 11 Aug 2026 15:41:21 +0000

TRON processed $2.1 trillion in USDT transfers during Q2 2026, according to Messari.

During the same quarter, circulating USDT on TRON reached $87.9 billion, putting it ahead of Ethereum.

Those numbers point to something developers working with stablecoins have to consider more carefully: the blockchain underneath a token can shape the entire payment experience.

USDT on TRON uses the TRC-20 token standard.

That means a USDT transfer is a smart contract transaction rather than a native TRX transfer. The wallet signs the transaction, the network executes the token contract and the resulting balance change is recorded on-chain.

For an application accepting USDT, this creates several technical requirements.

The system needs to identify the correct token contract, monitor the relevant transfer events and wait for sufficient confirmation before crediting the user's balance.

Checking the address balance alone is not enough.

TRON's developer documentation provides APIs for retrieving TRC-20 transaction history and filtering transfers by contract address. A payment system can use this data to monitor incoming USDT deposits and associate them with the correct customer account.

The transaction also has a resource cost.

TRON uses Bandwidth and Energy to process transactions. Regular transactions consume Bandwidth, while smart contract execution requires Energy. When an account does not have enough available resources, TRX is burned to cover the remaining cost.

This creates an operational detail that users may never see.

Someone can hold USDT in a wallet and still need TRX to send it.

A payment provider can handle this in several ways. It can maintain TRX balances, stake TRX for resources or use delegated Energy. Another design can leave the requirement with the user.

The choice affects the product.

The amount of Energy required can also change depending on the destination account. TRON's documentation notes that a USDT transfer to an address that already holds USDT generally requires less Energy than a transfer to an address with no USDT balance.

That makes testing more complicated than sending one successful transaction between two prepared wallets.

A production system needs to account for different recipient states, estimate resource requirements and set an appropriate transaction fee limit before broadcasting.

These details become more relevant when the underlying asset is moving at the scale reported by Messari.

TRON recorded an average of $22.8 billion in daily USDT transfer volume during Q2. USDT represented 98.5% of the network's stablecoin supply at the end of the quarter.

The network has developed around a very specific use case.

Ethereum still has a much broader smart contract ecosystem, while TRON has become a major settlement network for USDT. Developers choosing between chains therefore need to look at the infrastructure surrounding the asset as well as the capabilities of the blockchain itself.

A payment application may need wallet support, exchange liquidity, reliable transaction monitoring and predictable operating costs.

The token may be the part users see.

The network determines much of what happens underneath.

TRON's Q2 results show how closely a blockchain can become tied to one stablecoin. They also show why stablecoin integrations require more than adding a token contract to a wallet or payment interface.

The difficult parts often sit underneath the transaction button: network selection, contract monitoring, resource management and making sure users know which chain their USDT is actually using.

Sources
Messari, State of TRON Q2 2026
TRON Developer Documentation, TRC-20 Transaction History
TRON Developer Documentation, Resource Model
TRON Developer Documentation, FAQ: Bandwidth and Energy

Disclosure: AI was used to assist with the initial draft. The final structure, wording and factual claims were reviewed by the author.