• 35M+ x402 transactions processed on Solana since launch
• 97%+ of tracked agentic transactions in Q2 used x402
• 90%+ of agentic stablecoin volume happened on Base
• 99%+ of agentic commerce was settled in USDC

It's needless to say that within the next few years. Scratch that…Within the next few quarters, the AI agent txn pie is about to grow exponentially.

And driving this growth are some of the most talented teams in the industry.

In this feature piece, we will spotlight some of the teams that continue to generate arguably the highest numbers in 2026 so far.

Revenue here refers to the subset of fees the protocol keeps for itself after paying out to liquidity providers.

Strictly NFA. For information purposes only.

Starting with:

1. Virtuals Protocol​

A launchpad where anyone can spin up an AI agent and give it its own token, so the agent can earn and be co-owned by holders. Built for creators monetizing agents and traders who want exposure to them.

Operating across Base, Robinhood Chain, Solana, Ethereum

Revenue in last 30 days - **$2.0M + ** Revenue to date - $73M

2. Clanker​

An AI bot that deploys a token for you when you describe one in a post on X. The bot handles the contract, the liquidity pool and the fee split. Built for creators and communities who want to launch a token without touching code.

Operates on Base

Revenue in last 30 days - $45,000+ Revenue to date - $15M

3. Bankr​

A chat-based agent you talk to on X or Farcaster to swap tokens or launch one, with fees split between the creator, the protocol and a burn. Built for retail traders who don't want to open a DEX, and for agents deploying tokens programmatically.

Revenue in last 30 days: $750K + cumulative revenue: ~$13M

4. Almanak​

A platform where a swarm of AI agents researches, simulates and runs quant DeFi strategies inside secured vaults. Built for depositors who want automated yield and quants who want to ship strategies without running infra.

Revenue to date: $500K+ (peak quarter was Q4 2025 at $1.52M gross)

5. Capx AI​

Infrastructure for running whole companies on agents deployment, orchestration, governance and on-chain settlement in one stack.

Capx Chain, an Ethereum L2

Revenue, last 30 days: $30,000+

Primarily EVM

6. ZyFAI​

A yield agent that moves your stablecoins across whitelisted DeFi protocols to chase the best risk-adjusted APY, while you keep custody. Built for passive depositors and treasuries.

Revenue, last 30 days: $10,000+

Source: DefiLlama

What does this tell us?​

The Onchain agentic economy is growing. And this is just one vertical of the broader Crypto × AI convergence.

Micropayments, x402, ERC-8004, and other emerging mechanisms are being built to make onchain infrastructure capable of supporting potentially billions of autonomous agents.

The signals are already visible

As the infra becomes more reliable, interoperable and secure for high-intensity autonomous activity the volumes of agentic commerce will soar automatically.

Watch this space.

Want to know more about how AI agents operate? Read this and this

Today, crypto agents are initiating more than 25% of all onchain trades. 3X JUMP from the last two years!!

These agents have already crossed $3 billion in market cap and are processing over $100 million in volume every week.

So how is the infrastructure, which was originally built for manual human actions like browser wallets and manual txn signing is able to reliably support and power autonomous agents operating 24/7 across multiple chains??

Time to find out how.

Quick TL;DR:

What Is Inside a typical onchain Transaction?​

On an EVM chain, a standard transaction usually contains:

• to → Contract or recipient address
• value → Native asset being transferred
• data → Encoded smart-contract function call
• nonce → Sender’s transaction sequence number
• gasLimit → Maximum computation allowed
• maxFee → Maximum gas price the sender will pay
• chainId → Network on which the transaction is valid
• signature → Cryptographic authorization

On non-EVM chains like Solana, the packaging is different. A transaction contains signatures and a message composed of account addresses, a recent blockhash and one or more program (smart contract) instructions.

Let's walk through an example:

“Swap 0.4 ETH for USDC with a maximum slippage of 0.5%.”

The AI model decides that a swap is required. A predefined swap tool then converts that decision into contract-compatible data.

The tool identifies the relevant contract, calculates the minimum acceptable output and encodes the function call. The blockchain never sees the original prompt; it only receives transaction data.

How Does an AI Agent Sign Transactions?​

There are two common architectures.

1. Direct wallet signing​

The agent controls an externally owned account or a managed wallet. The signing key may be stored in secure infrastructure rather than directly inside the AI model. The model proposes the action; the wallet system performs the cryptographic signing.

BUT THIS IS A VERY INSECURE METHOD!

An EOA private key grants unlimited, overarching spending authority. If an AI agent is given a raw private key and suffers a prompt injection attack, software bug, or dependency compromise, the attacker gains full access to drain the wallet.

EOAs do not natively support spending limits, recipient whitelists, or time delays. To safely deploy agents that handle real value, the spending logic must be enforced at the blockchain level, not just within the application code.

To give agents secure wallets, developers utilize ERC-4337 Account Abstraction. This standard replaces raw private keys with smart contract accounts.

2. Smart-account execution​

Over 40 million of these smart accounts have been deployed across Ethereum and Layer 2 networks. Instead of broadcasting standard transactions to the mempool, agents generate UserOperations. A UserOperation is a pseudo-transaction object that contains the sender's details, the action to execute (calldata), gas limits, and custom validation fields. This architecture allows the smart account to run programmable verification logic before authorizing the spend.

Session Keys for Granular Control​

To operate autonomously without requiring a human to sign every micro-transaction, an agent uses Session Keys. A session key authorizes specific transaction types without giving the agent root control of the wallet.

A platform can provision a session key for an agent with strict parameters:

• Maximum spend per transaction: e.g., capped at $50.
• Approved recipient lists: The agent can only interact with pre-vetted smart contracts (like a specific DEX router or yield protocol).
• Time boundaries: The session key expires after exactly 24 hours.
• Total budget: The agent can only spend a cumulative $500 before requiring a human to re-authorize.

How Agents Pay for APIs and Other Agents​

Machine-to-Machine Payments are enabled by the x402 Protocol

Agents cannot realistically stop to navigate a checkout flow or input credit card details for every offchain purchases like API credits or online shopping.

The x402 protocol solves this by repurposing the standard HTTP "402 Payment Required" status code for machine-to-machine crypto payments.

The transaction flow works like this:

1. Request: The agent requests a resource from a server.
2. Payment Required: The server rejects the request with a 402 status, attaching a header that details accepted payment networks, token prices, and destination addresses.
3. Payment Signature: The agent automatically builds and signs a payment payload matching one of the server's accepted options, then resubmits the request with the payload.
4. Verification and Settlement: The server (often using automated payment facilitators) verifies the payload, settles the payment on-chain, and delivers the requested data to the agent.

Summary:​

AI agents do not directly “talk” to blockchains.

They:

1. Interpret an objective
2. select an approved tool
3. construct a chain-specific transaction
4. validate it against deterministic policies
5. sign it through a wallet or smart account
6. submit it through an RPC or bundler
7. observe the resulting state change

• There are more than 600,000 active agents currently operating on-chain across various ecosystems
• In april x402 ecosystem alone recorded: 480,000+ transacting agents
• That executed over 165 million+ transactions with over $50 million in payment volume

We are entering a period of massive opportunity for both developers and users. By building and using onchain AI systems, we can automate complex workflows, improve operational efficiency, and unlock entirely new revenue models.

To participate in this shift, however, you need at least a high-level understanding of how onchain AI agents work.

P.S. They are very different from the everyday AI tools and chatbots most of us currently use.

What makes this article different?​

• A purely educational piece. No project or tool shilling. Strictly NFA
• A complete overview of the crypto AI agent stack in under 500 words.
• Written for both users and builders, regardless of technical background.

Crypto AI Agent Stack Explained Layer-wise​

Layer 1: User and application​

This is where a human or another application gives the agent a goal. Eg: “Always balance my portfolio 60% ETH and 40% USDC.” “Pay for a market-data API and prepare a report.” “Find the best USDC lending yield on Solana and bridge and deposit the 100 USDC from my Base Metamask Wallet”

User specifies intent through an interface like an app frontend or a messaging app, rather than manually executing every step on the blockchain.

Layer 2: Agent runtime​

Think of the runtime as the operating system of the AI agent. It orchestrates the entire execution loop: Receive goal → Collect context → Ask the model to decide → Select a tool → Execute the tool → Observe the result → Stop or continue

Frameworks such as elizaOS organize agents around runtimes, plugins, providers, actions and services. Providers give the agent information, while actions let it do something.

Coinbase AgentKit focuses heavily on adding wallets and onchain actions to different agent frameworks.

Layer 3: AI model and planner​

This is the agent's reasoning engine. It interprets natural language, breaks complex objectives into executable steps, decides which tools to call, and generates a plan. Models could include GPT-5, Claude, Gemini, DeepSeek or specialized home trained models. Eg: Current ETH allocation: 70% Target ETH allocation: 60% Action required: Sell some ETH for USDC

model doesn't execute transactions itself. It simply decides what should happen next. The runtime and tool layer translate those decisions into deterministic blockchain actions.

Layer 4: Memory and knowledge​

Memory allows the agent to remain stateful instead of treating every request as a brand-new conversation. Most agents maintain three kinds of memory:

1. Working Memory: temporary context for the current task.
2. Long-term Memory: persistent user preferences, transaction history, and learned behaviours.
3. Knowledge Base: could include external references such as protocol documentation, governance rules, whitepapers, APIs or trading strategies.

Agent frameworks commonly provide persistent conversation, knowledge and state storage so agents can retrieve past context before choosing an action.

Layer 5: Data and perception​

This is how the agent observes the world. Reading raw blockchain history directly is difficult. Indexers organize events into queryable datasets. Depending on the task, it continuously consumes both onchain and offchain data: like balances, liquidity, market prices, active positions and news/social sentiments. This is where indexers and oracles come into play. This layer is typically powered by RPCs, indexers like The Graph, oracle price feeds like Chainlink, , external APIs and universal execution layers like Push Chain.

Layer 6: Tools and action adapters​

If the model is the brain, tools are its hands. The AI never directly interacts with a blockchain. Instead, it invokes predefined tools that safely translate its decisions into deterministic operations. An abstract decision could look like: “Reduce ETH exposure.” Tool call: swap( token_in = ETH, token_out = USDC, amount = 0.4 ETH, max_slippage = 0.5% )

Typical crypto tools include: Register an agent, Transfer tokens, Mint an NFT, Bridge assets, Create a limit order Push Chain’s TAP, Coinbase AgentKit, for example, exposes wallet operations and onchain actions through action providers and integrates with several agent frameworks

Layer 7: Wallet, identity and policy engine​

A wallet gives an agent the power to

• Hold assets
• Maintain an identity
• Sign Transactions
• Receive payments

The policy engine sits between the AI and the wallet, enforcing deterministic guardrails such as:

Maximum per transaction: $100 Maximum per day: $500 Allowed tokens: ETH, USDC Allowed protocols: Uniswap, Aave Maximum slippage: 0.5%

There are more than 250,000 ai agent agents in crypto, but today NONE OF THEM can easily operate cross-chain because there isn't any way to:

• preserve an agents identity across chains
• have an aggregated reputation score

Trustless Agent Plus (TAP) framework on Push Chain fixes this

Layer 8: Blockchain and smart-contract execution​

This is the execution and settlement layer. The AI usually thinks offchain, while the blockchain handles:

• Asset ownership
• Balances
• Transaction ordering
• Contract execution
• Settlement
• Receipts

It is very crucial for the agent as well as the projects building such agents to measure their performance to ensure transparency.

Moving forward, as crypto becomes an ai dominated industry, performance benchmarking will be an integral part of the industry. Assisting everyone, from retail to B2B as well as institutions.

Layer 9 - Agent Economies​

This layer allows agents to participate in more complex economic activities beyond executing one-off transactions for a single user. Once an agent has a wallet, identity and access to tools, it can:

• Pay for APIs, data or compute.
• Receive payment for completing tasks.
• Hire another specialized agent.
• Participate in marketplaces or service networks.

In the coming weeks we'll dive deeper into crypto ai agents and understand how they work behind the scenes, what are the untapped building opportunities in this space and how can you make the most of it, both as a dev and a user!

Watch this space.

Consider you’re building a tokenized treasury fund.

Let's call it YieldVault.

YieldVault launches on Ethereum. It tokenizes short-duration U.S. Treasuries, issues yield-bearing tokens, and reaches $200M in AUM within six months. (Bravo!!!)

Then the requests start coming in.

• A DeFi lending protocol on Arbitrum wants YieldVault tokens as collateral.
• A payments company on Solana wants to integrate them into stablecoin yield strategies.
• An institutional desk running on Robinhood needs them for cross-border settlement.

This sure sounds like the road to PMF, right?

But do we (as an industry) have the right infra to fulfil all of the above requests? Without practically rewriting and re-deploying your product from the ground up?

YieldVault now has a choice to make: do you stay on one chain and limit your addressable market, or do you go multi-chain and inherit a coordination problem that gets exponentially harder with every deployment?

Let's assume YieldVault deploys on four different chains. Each deployment gets its own liquidity pool, which needs to be bootstrapped because the $200 AUM liquidity was localised to a single chain.

This is where the liquidity fragmentation problem starts to kick in.

• Liquidity coordination
• Slippage issues
• Price discrepancies in assets now listed across different chains

A fund manager running a $500M allocation across tokenized treasuries cannot tolerate a world where the same instrument prices differently depending on which chain they're looking at. That's not a market. That's four separate markets we say are one.

Every deployment is a separate product.​

Four chains means four codebases, four audits, four oracle setups, four upgrade paths. When the yield rate updates or redemption logic changes, it has to land on all four. This is where Push Chain does it differently.

Push Chain is a universal Layer 1 blockchain designed from the ground up to solve the exact problem of liquidity fragmentation and siloed execution across all chains, both EVM and non-EVM.

YieldVault deploys once, on Push Chain and instantly becomes universally accessible to all EVM and Non-EVM chains like Solana.

A wallet on Solana, Arbitrum, or Ethereum interacts with that single deployment directly from their own wallet, paying gas in their own token, in one signature. No wrapping, no bridging, no second deployment.

And the contract doesn't see a bridge or a relayer as the sender. Push Chain maps every external wallet to a persistent account on Push Chain, so the contract sees a stable address that traces back to the origin wallet controlled by the user.

Does YieldVault need to forgo its $200M Ethereum Liquidity after porting to Push Chain?​

No. Not at all.

This is where most of you get it wrong. Migrating to the Push Universal Chain does not mean that you need to wind up your current deployments and liquidity strength. Your app or in this case YieldVault can choose to exist on Ethereum with all of its liquidity + coexist on Push Chain with a new universal liquidity pool which can now be accessed by users of Ethereum, Arbitrum, Robinhood, Base and even Non-Evm chains like Solana.

If you’re curious to know more about universal execution and a bridgeless cross-chain usage experience universal apps and read more about Push Chain here.

Dive straight into the docs to know more about a single-deployment universal setup.

Push Chain is a complex system - it lets users from any chain, settled in one place. No bridges, gas in any token. Behind the scenes it means coordinating contracts and infrastructure across several networks at once.

A system with that many moving parts deserves rigorous, independent scrutiny to protect user funds, and launch with confidence. So we partnered with Hacken, a leading web3 security firm that has audited major ecosystems including NEAR, Solana, MetaMask, BNB Chain, ByBit, Base and TON. Hacken’s smart contract audit combines senior-led code review, structured testing, and real-world exploit analysis – trusted by 1,500+ projects securing over $180B+ in digital assets.

Between March and June 2026, Hacken conducted a full security audit program across Push Chain - covering our cross-chain gateway contracts on both EVM chains and Solana, our core contracts on Push Chain, and a protocol-level assessment of the Push Chain node itself.

Today we're sharing the results.

The most important result: no critical-severity findings were identified across any of the four audit engagements.

Key Outcomes​

• Zero critical-severity findings across any audit
• 3 smart contract and full chain audit was completed across Push Chain infrastructure
• All High and Medium findings resolved, mitigated, or formally acknowledged
• Final audit reports delivered by Hacken
• Dual Defense bug bounty launching soon with rewards of up to $100,000

The Security Audit Scope​

The audit program spanned four separate engagements, each with its own scope, methodology, and report:

1. EVM Gateway contracts. The UniversalGateway and Vault contracts deployed on external EVM chains such as Ethereum, Base, Arbitrum, etc. These are the contracts that accept user deposits, hold bridged assets in custody, enforce per-transaction and per-block value caps, and release funds on TSS authorization. This is the highest-value custody surface in the system.
2. SVM Gateway contracts. The Solana-side gateway program, written in Rust with the Anchor framework. It mirrors the EVM gateway's role for Solana users - locking deposits in a PDA-controlled vault and releasing them through TSS-signed outbound operations.
3. Core contracts. The contracts deployed on Push Chain that make universal execution work, including UniversalCore, the UEAFactory and CEAFactory, the Universal and Chain Executor Account implementations, and the PRC20 synthetic token standard.
4. Push Chain node. A protocol-level assessment of the Cosmos SDK and EVM node (pchaind), covering the custom universal modules - registry, validator voting, on-chain execution, and threshold-signing coordination - and the EVM precompiles that let Solidity verify signatures from other chains.

Across these engagements Hacken applied manual review by senior security researchers alongside property-based fuzzing and fork testing.

The smart-contract suites carried strong automated coverage going into the audit, with line coverage above 95% on the SVM gateway and high branch coverage on the core and EVM contracts.

The protocol-level review followed recognized standards including NIST SP 800-115 and the Penetration Testing Execution Standard.

Audit Findings​

The most important result first: No critical-severity issues in any of the four audits.

Across the three finalized smart-contract audits - EVM Gateway, SVM Gateway, and Core Contracts and Push Chain Node - every High and Medium severity finding was resolved, mitigated, or formally acknowledged before the reports were finalized.

We treat that distinction honestly: most findings were fixed in code and re-verified by Hacken; a small number of low or informational issues were formally accepted as intended design decisions, with the reasoning documented; and a few were mitigated where a complete fix sat outside the audited scope.

We don't view the findings that surfaced as a problem to hide. We view them as the entire point of the exercise. A few examples of how the review made the system stronger:

• Granular role separation across the contract suite. The audits prompted us to move to a production-grade access-control model - a layered role hierarchy where role management, configuration, operations, and pause authority are held by distinct roles rather than a single key, limiting the blast radius if any one key is ever compromised.
• Stronger custody and authorization guarantees. Findings on the SVM gateway led us to enforce canonical vault token accounts so bridged liquidity can't be fragmented, to authenticate previously unsigned cross-chain revert data, and to separate pause authority from unpause authority so re-enabling the system after an incident requires higher assurance.
• Safer administrative operations. We introduced two-step authority transfers so a privileged role can never be handed to an uncontrollable address by a single mistaken transaction, and we bounded protocol-fee configuration to remove the possibility of an unbounded fee.

The full reports document every finding, its severity, and its resolution. We're publishing them so that anyone - users, builders, or other auditors - can read the complete picture rather than take our summary on faith. Specifically for builders, it means you're deploying on a chain whose universality layer has been reviewed by people outside our team. The parts of Push Chain you can't audit yourself - the cross-chain custody, the signature verification, the executor account model - are exactly the parts Hacken focused on.

The review of the fixes done by the Push Chain team is now complete.

After a final re-verification and extensive review, Hacken has now provided the Final Audit Reports.

Beyond the Audit: A Bug Bounty of Up to $100,000​

An audit is a point-in-time review of a specific commit. It is necessary, but it is not sufficient - and Hacken's own guidance is explicit that no project should rely on an audit alone.

So alongside the completion of this audit program, we'll soon be launching a Hacken-hosted bug bounty for Push Chain, with rewards of up to $100,000 for qualifying vulnerabilities. This turns security from a milestone into a standing invitation: the more eyes we have on the code as we move toward mainnet, the safer the system becomes for everyone building and transacting on it.

What's Next​

Now that the security audit program is complete, the work doesn't stop here.

The audit and the bug bounty program that now sits alongside it are part of the same goal: ensuring that Push Chain's contracts and the chain itself remain secure, reliable, and dependable for everyone who builds and transacts on them.

With security as a foundation, our focus now shifts to the ecosystem. We're working to onboard flagship applications so that when mainnet goes live, there are real products and use cases available from day one.

The completion of this audit program marks an important milestone for Push Chain, bringing us one step closer toward our broader goal: making blockchain feel universal.

The full audit reports are linked below - we encourage you to read them.

Read the full Hacken audit reports

• EVM Gateway report
• SVM Gateway report
• Core Contracts report
• Push Chain node report

Meet Zappi, our newest inductee in the Push Chain Universal App ecosystem!

Zappi is an anychain to anychain payments app built for freelancers, creators, and business owners of all sizes to request, receive, and settle invoices onchain.

Zappi is powered by PUSD - A universal stablecoin on Push Chain that unifies USDC and USDT liquidity across all major EVM, non EVM chains.

Here’s what it unpacks…

Under the hood, Zappi uses PUSD as its stablecoin layer.

PUSD is a universal stablecoin on Push Chain that provides a common dollar layer on top of crypto unifying fragmented liquidity from USDC, USDT across all popular chains.

Users can deposit supported stablecoins, mint PUSD 1:1, use it across Push Chain apps, and redeem into supported stablecoins.

This matters because payments need a common dollar layer.

Without PUSD, every payment app has to think through different versions of the same dollar: USDC on one chain, USDT on another, wrapped assets, bridge flows, liquidity routes, and withdrawal preferences.

Read more about PUSD here

What exactly does Zappi do?

Global digital payments are now being taken over by Stablecoins.

These solutions are fast, secure, instant and incredibly cheaper than traditional SWIFT/ACH counterparts. And they run 24x7.

But stablecoins are still isolated within chain boundaries. USDC on Solana and USDC on Ethereum may represent the same dollar value, but they are not automatically interchangeable in practice.

And this is a huge bottleneck that very few teams are trying to solve.

A user might have USDC on Base. The recipient might prefer USDT on another chain. The app might support only one network. The payment might need a bridge, a swap, multiple approvals, extra gas, and a lot of waiting.

That is too much friction for something as simple as “send $100.”

Stablecoin payments should feel simple: create a request, share a link, receive funds.

Paid from any supported stablecoin, through any chain.

That is what Zappi is designed for.

How can I use Zappi?

Where can I use Zappi?

Zappi makes stablecoin payments easier for:

• freelancers collecting payments from global clients
• businesses accepting crypto payments
• creators receiving tips or support
• teams splitting bills or collecting contributions
• apps and communities that need simple stablecoin checkout flows

Join our merchant network today!

Start using Zappi

With Zappi, users can create payment links, accept supported stablecoins, settle in PUSD, and earn safest yields through PUSD+.

It is a simple idea: global payments should not break because the sender and receiver are on different chains.

If you're a developer building in the payments or other cool industries and want to build using Push Chain and PUSD, reach out to us here.

PUSD is a universal stablecoin that unifies fragmented USDC, USDT liquidity from any chain to enable bridgeless, cross-chain asset movement. Every PUSD is backed 1:1.

This blog covers what PUSD is, why we need it, what it is not, its unique features, and how it aims to power the next generation of universal apps and blockchain-native payments, while also enabling passive income opportunities for users.

Challenges users and businesses face​

Stablecoins are everywhere in crypto, but using them is still not as simple as holding a “digital dollar.”

One has USDC on Base, USDT on Ethereum, or USDC on Solana, but the dilemma is always multifold

• Does the app support it?
• Do I need to bridge first?
• Will the recipient /vendor accept this version of the stablecoin?
• Can I withdraw into the chain I actually want to use?
• Are stablecoin yield platforms safe enough?

So even when the user already has stablecoins, they still have to think about bridges, supported assets, approvals, destination chains, withdrawal routes, and whether the stablecoin in their wallet is the “right” one for the action they want to take.

Now, if you zoom out and try to apply this workflow for bigger organizations, teams and events, the implications are massive: both in terms of time and resources wasted.

That is the problem PUSD is built to solve.

Missed opportunity:​

PS: There's over $320 billion in stablecoin liquidity across 50+ chain-token pairs. But none of it is shared. An app on Arbitrum can't tap USDC liquidity sitting on Solana. A prediction market on Base can't settle with USDT locked on Ethereum.

PUSD is designed to remove that problem at the application layer.

The goal is simple: make stablecoin usage feel less fragmented for users and easier to build around for developers by utilizing Push Chain’s universal execution layer

What is PUSD?​

1:1 stablecoin minting Users deposit USDT, USDC from any supported EVM, non-EVM chain into the PUSD App and receive an equivalent amount of PUSD on Push Chain.

Once minted, PUSD can be used for payments, trading, app interactions, or converted into PUSD+ for yield. Read more use cases below.

Backed by reserves, not printed from thin air Every PUSD is backed by reserve assets. The system is designed around reserve accounting, not speculative expansion.

Universal stablecoin liquidity for Push Chain apps Instead of every app needing to support every chain-specific version of USDC or USDT, apps can integrate PUSD as the common stablecoin layer.

Integration takes a few hours, not months. Refer the guide here.

Instantly redeemable into chain-specific stablecoins Users can burn PUSD and redeem it back to required stablecoins.

Universal means Universal: PUSD is built for a multi-chain world. A user may enter with stablecoin liquidity from one chain and redeem into another supported chain, depending on available reserves and routing.

PUSD+ for yield-bearing exposure PUSD+ is the yield-bearing side of the system. Yield comes from activity around internal stablecoin swaps and rebalancing, with fees distributed back to PUSD+ holders.

How to mint PUSD?​

Mint here: http://pusd.push.org

Safest Stablecoin Yield​

PUSD+ is the yield-bearing version of PUSD. Because PUSD pools stablecoins from multiple chains, Push creates Uniswap-style swap pools (e.g., USDC.eth ↔ USDC.sol pairs) via Ramen.fi. Swap fees from these pools flow back to PUSD+ holders

The yield is not based on aggressive farming, leverage, volatile collateral, or uncertain hidden DeFi strategies making it the safest yield strategy 100% backed by stablecoins.

How to earn yield on PUSD?​

Early Usecases​

Pay anyone, on any chain: You have USDC on Solana. The person you're paying needs USDT on Arbitrum. With PUSD, the chains don't need to match and the stablecoins don't need to match. Deposit, send, the recipient redeems on their chain.

Check out Zappi.to: An instant payment app for inide hackers and freelancers. Receive payments in stablecoins in seconds instead of weeks.

Predict and trade across chains Prediction markets today only accept stablecoins on their native chain, which cuts out users on every other chain.

A prediction market settling in PUSD lets anyone from any supported chain place a bet with whatever stablecoin they already hold. No bridging before every trade.

This is just a glimpse. PUSD is more than a stablecoin, it’s the liquidity layer designed for a multi-chain, blockchain native payments future.

TLDR;​

Following the launch of Donut Testnet and $PC ticker reveal, Push Chain has continued to gain strong momentum. Over the past few months, we’ve seen increasing activity across users, developers, and validators as the ecosystem around universal apps begins to take shape.

Push Chain has processed 15M+ transactions across 400k+ active addresses, secured by 35+ validators. We’ve seen massive developer interest in building DeFi, RWAs, and AI Agents. With over 25 universal apps already live like RamenFi, PUSD, and Degen Chess, users from Ethereum, Solana, Arbitrum, BNB, and Base are interacting seamlessly without needing complex and unsafe bridging to get started.

Rewards Portal https://portal.push.org/

A program beyond social farming​

With the launch of Season 3, we wanted to avoid the typical incentivized testnet playbook. Most campaigns often resort to social farming where users click buttons to join Discord or post on X for points that are pointless. Participating without ever meaningfully touching the network.

Testnets exist to stress test real infrastructure with real users. With Push Chain S3 you are using the actual network with EVM and non EVM wallets on the exact same platform in realtime. Every point in Season 3 flows from on-chain activity and the usage of $PC.

Leaderboards reflect who is actually putting the network through its paces and instead of a static points system, Season 3 introduces a fully gamified reward loop.

Enter Push Chain Pass (Rare/Shinies)​

Rare Passes are collectibles earned purely through active testnet participation. They are your ticket to the endgame of Season 3. At TGE, users will burn their Rare Passes for a chance to mint and convert them into a Shiny Pass, maxed with rewards for Push Chain supporters. But even if you miss the Shiny, every burned pass guarantees a boost.

Hit your daily spins, grind your levels, score $PC and stack as many passes as you can. The bigger your stash, the better your odds.

Season 3 is Open: Here’s how it works​

Season 3 is now open to everyone. No invite codes, no waitlists. Here is how you play the meta:

• Weekly Airdrops: Every week, a new universal app built on Push Chain drops into the rotation.
• Quest loops: Complete on-chain tasks on Push Chains testnet portal (providing liquidity, swapping, playing, or predicting) to earn XP.
• Progresssion: Level up to score 2 Rare Passes, Points, Buffs, and more.
• Spins: Hit the daily Spin 2 Win wheel to score more Rare Passes, $PC and hoard your stock.
• Referral System: Invite your friends using your special link and earn a chunk of any points your invites earn.

Early access users already have a head start, leaderboards are live, and a new banger app drops every week. Dive in and claim your spot on the board.

Head over to Push Chain Portal, login using your favorite socials or wallet, and start collecting.

⚠️ Note: The token is currently live on testnet and not in mainnet. $PC is the only official token that will power all native functionalities on Push Chain. As a reminder, $PUSH holders will be able to migrate their tokens to $PC.

Multihop allows you to compose multiple cross-chain operations into a single signed transaction. Ordered and tracked end-to-end.

Cross-chain today is still manual and bumpy

For users:​

Try doing anything non-trivial across chains right now. Swap ETH for a Solana token. Move collateral from BNB to Ethereum and deposit it into a lending protocol.

Every step is a separate transaction. And every transaction needs a separate signature. This means multiple interruptions, multiple clicks and many minutes wasted in preparing a transaction before actually executing it.

The question worth asking is: why do users have to heavy lift all these precursor steps? Shouldn’t the underlying tech handle everything on its own!?

Take a cross-chain yield balancing app as an example:

For developers:​

Today, building cross-chain apps is 30% business logic and 70% orchestration and plumbing. Instead of focusing on app features and logic, devs are forced to integrate multiple SDKs and interop protocols with a bumpy learning curve.

Then comes another headache. Cross-protocol compatibility and debugging hell. Writing complex retry handles, timeout watches and manual rollback scripts

What devs often fail to understand is that the cross-chain part of their codebase isn't the true product. It’s just plumbing. Which (again) should be abstracted and handled by the underlying protocol itself.

What multihop changes?

For users:​

Multihop lets you compose multiple cross-chain transactions into a single ordered flow.

You simply specify your steps or intent and watch Push Chain execute them all at once, with just one signature.

Push handles all the cross chain coordination across multiple chains (be it EVM, Solana, or Push Chain itself).

For devs:​

The API surface is two functions. That's it.

prepareTransaction takes a transaction description, target address, calldata, chain, optional fund movement and returns a PreparedUniversalTx object. This object contains the resolved route (where does this hop execute?), estimated gas, nonce, deadline, and the encoded payload. You don't need to inspect any of this. You just pass it forward.

executeTransactions takes an ordered array of prepared transactions and submits them as a single cascade to Push Chain. One signature. The SDK figures out the routing: which hops stay on Push Chain, which go outbound to external chains via CEAs, which move funds between chains.

Refer to the docs for more detailed insights.

Routing is automatic: You don't think about routes. Pass a plain address in to and the hop stays on Push Chain. Pass { address, chain } and it goes outbound (from push to ext chain) via CEA.

Need a hop to originate from an external chain? Set from: { chain } and the SDK handles the rest.

Funds can move with any hop Any hop can carry token movement alongside its contract call via the funds parameter. Bridge ETH into Push Chain and call a contract in the same hop. No separate bridging steps needed.

Multiple calls can be batched into a single hop The data field accepts either a single calldata or an array of calls. So approve + deposit can be one hop instead of two. Fewer hops, tighter cascades.

Try It

Multihop is live on testnet. Experience it through our ecosystem apps like RamenFi.

Multihop docs also include playground environments where you can test directly in your browser, no local setup needed.

This is one of our biggest security upgrades to date. Must read if you're a cross-chain user or a dev.

CEAs are per-user smart accounts that live on external chains and act on your behalf while keeping your funds and unified crosschain identity separate from everyone else.

Every cross-chain protocol routes your transaction through a shared gateway address.CEAs fix that by giving every user their own isolated smart account on every external chain.

Let's discuss about the darkest cross-chain secrets you’re probably unaware of.

Open any cross-chain protocol today. Bridge some tokens. Execute a swap. Deposit into a lending pool on the destination chain.

Now check the block explorer. Who made that deposit?

It's not you! It's either a gateway contract or any other intermediary relayer contract that deposits on your behalf.

And not just you, all the other users are mostly sharing the same gateway address for such actions. Using the same pipeline.

This creates two problems, both serious enough to keep you up at night.

Identity Collapse:​

The target protocol can't distinguish between users. Your lending position, your collateral, and all are attributed to a shared gateway address.

msg.sender = 0xGateway for everyone.

Shared custody risk​

Every user's funds sit under one contract.

A single exploit doesn't drain one user; it would drain everyone who had pooled their funds in the gateway.

How do CEAs work?

A Chain Executor Account is an isolated smart account deployed on an external chain, derived deterministically from a user's UEA on Push Chain.

In plain English: instead of everyone sharing one gateway address on Ethereum, every user gets their own contract. Bob gets Bob's CEA. Alice gets Alice's CEA. The gateway routes to them without touching the target protocol directly.

Here's how the execution actually flows

CEA’s objective is not only to patch the identity problem but make unified onchain identities a first-class architectural primitive.

How does CEA impact your security?

Identity is half the story. The other half is what happens when something goes wrong.

Without CEA, the gateway holds every user's funds, approvals, and positions under one address. It's a single point of failure with maximum blast radius. One vulnerability in the gateway contract and every user who ever routed through it loses everything.

for instance:

We've seen this movie before. Bridge exploits have drained over $2.5 billion since 2021. The root cause is almost always the same: shared custody.

CEA breaks the blast radius at the account level.

Deterministic Mapping​

One UEA, one CEA per chain. The mapping is 1:1 and deterministic. If you have UEAs derived from wallets on Ethereum, Solana, and Base, you get three CEAs, one on each respective external chain. No ambiguity, no collisions.

Fund withdrawal. Assets locked in a CEA can always be moved back to the user's UEA on Push Chain. No funds get stuck.

Deterministic derivation​

Each CEA is derived from its underlying UEA. One UEA maps to exactly one CEA per external chain. You can't deploy a counterfeit CEA that claims to be Bob's since the derivation is verifiable.

Strict access control​

CEA.execute() only accepts calls from the Universal Gateway on that chain. Nobody else can trigger it. Not an EOA, not another contract, not another CEA. The gateway, in turn, only routes to a CEA after resolving which UEA initiated the call. Bob's UEA can only trigger Bob's CEA. The resolution is deterministic and verifiable on-chain.

With CEA, a compromised account means one user is affected and not the entire user base.

Token approvals are scoped per-CEA. Fund isolation is structural. There's no shared pool to drain because there's no shared pool!

One wallet. One signature. Universal identity preservation. Isolated risk.

Refer this integration guide to make your app universally accessible and secure in hours not months.

Got any Questions? Reach out to us via our Dev Telegram Chat or community Discord.