{ "version": "https://jsonfeed.org/version/1", "title": "Push Chain — Universal Blockchain for Apps Blog", "home_page_url": "https://pushchain.github.io/push-chain-website/pr-preview/pr-1235/blog/", "description": "Push Chain — Universal Blockchain for Apps Blog", "items": [ { "id": "https://pushchain.github.io/push-chain-website/pr-preview/pr-1235/blog/ai-agent-identities-in-crypto/", "content_html": "

\"Cover

\n

Consider an open marketplace of thousands of AI agents. Where one agent can employ other agents to coordinate given tasks.

\n

Let's say agent A is looking for an agent that provides smart contract auditing services.

\n

Another agent, say agent B, says \"I can analyze this smart contract for $5.\"

\n

Now on what basis would Agent 'A' decide whether Agent 'B' is the best choice for the job?

\n

Can't just assume word for word, right !?

\n

Agent 'A' still needs answers to questions like:

\n\n

It all boils down to one empirical question: How should we (humans) and agents find and trust other agents?

\n

This is exactly what ERC-8004 solves.

\n

What is ERC-8004?​

\n

ERC-8004 is an Ethereum standard for discovering agents and creating trust signals about them.

\n

It gives AI agents a common on-chain system for identity, reputation, and validation. Its goal is to let agents work across different organizations without pre-existing trust.

\n

ERC-8004 consists of three main components (or registries):

\n
    \n
  1. Identity Registry
    2. \n
  2. Reputation Registry
    3. \n
  3. Validation Registry
    4. \n
\n

Caveat: ERC-8004 does not put a complete AI agent onchain. The agent can still run on a server, in a Trusted Execution Environment, or in another computing system.

\n

The blockchain stores the parts that need a common and public source of truth.

\n

Decoding ERC-8004 Registries​

\n

Identity Registry​

\n

The Identity Registry gives each agent a unique on-chain identity. This identity is minted as an ERC-721 NFT.

\n

Each registered agent gets an agentId. The NFT owner controls the agent identity. The owner can also transfer the identity to another owner.

\n

This NFT points to a JSON file, also commonly known as an Agent Card, which includes all the metadata about the agent, including its name, service endpoints (A2A, MCP), payable address, functionalities and more.

\n

Reputation Registry​

\n

The Reputation Registry stores feedback about an agent's past performance.

\n

Any client can submit feedback for a registered agentId. The agent owner and approved operators cannot review their own agent.

\n

Feedback can be provided in two ways: Numerical and Categorical (tags).

\n

For numerical, example:

\n
Quality       = 87 / 100
Uptime        = 99.77%
Success Rate  = 89%
Response Time = 560 ms
\n

And categorical tags could be: \"uptime\", \"month\"

\n

Caveat: ERC-8004 does not define one universal reputation score.

\n

It stores standardized feedback signals. Applications can decide how to filter, weight, and combine them.

\n

Validation Registry​

\n

Provides a standardised mechanism for evaluating and recording the agent's work as an onchain verifiable evidence.

\n

The registry stores independent checks of an agent's work.

\n

The registry does not check the work itself. A separate validator does the check. The registry records: What was checked, who checked it and what the result was.

\n

How does ERC-8004 work?​

\n

\"Diagram

\n

A typical ERC-8004 flow has four stages:

\n

Step 1: Register the agent​

\n

The agent owner registers an agent in the Identity Registry, which then creates an ERC-721 token and assigns an agentId. The owner also provides an agentURI.

\n

You can track and discover ERC-8004 registered agents at: 8004scan.io

\n

Step 2: Use the agent​

\n

A client discovers the agent.

\n

The client can then call its MCP endpoint, send an A2A task, use its web service, or interact through another supported method.

\n

Step 3: Add reputation​

\n

After the interaction, the client can submit feedback to the Reputation Registry.

\n

As discussed in the article above, the Reputation Registry can accept feedback in both numerical and categorical forms.

\n

Step 4: Validate important work​

\n

Here the agent can ask a validator of its choice to vet its work. Validators can use different verification methods.

\n

For example:

\n\n

The validator returns a value from 0 to 100.

\n

A validator can use 0 for failure and 100 for success. It can also use values between them when the result is not binary.

\n

What ERC-8004 does not do​

\n\n

Why does it matter?​

\n

The internet has many ways to identify people, websites, and companies.

\n

AI agents need a similar system. But agents also need something more. They need machine-readable trust.

\n

An agent cannot read hundreds of human reviews before every transaction. It needs structured data that software can inspect. ERC-8004 provides the foundation for this model.

\n

If you want to dig deeper into the AI x crypto rabbit hole, read about the AI agent stack and how agents transact onchain.

", "url": "https://pushchain.github.io/push-chain-website/pr-preview/pr-1235/blog/ai-agent-identities-in-crypto/", "title": "AI Agent Identities in Crypto - Everything You Need To Know", "summary": "Learn what ERC8004 is and what makes it a revolutionary standard for defining, identifying and tracking the reputation of onchain AI agents", "date_modified": "2026-08-17T00:00:00.000Z", "author": { "name": "Push Chain", "url": "https://x.com/PushChain" }, "tags": [ "Key Features", "Deep Dives" ] }, { "id": "https://pushchain.github.io/push-chain-website/pr-preview/pr-1235/blog/highest-revenue-generating-crypto-ai-agent-protocols-of-2026/", "content_html": "

\"Cover

\n\n

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.

\n

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

\n

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

\n

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

\n

Strictly NFA. For information purposes only.

\n

Starting with:

\n

1. Virtuals Protocol​

\n

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.

\n

Operating across Base, Robinhood Chain, Solana, Ethereum

\n

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

\n

2. Clanker​

\n

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.

\n

Operates on Base

\n

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

\n

3. Bankr​

\n

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.

\n

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

\n

4. Almanak​

\n

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.

\n

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

\n

5. Capx AI​

\n

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

\n

Capx Chain, an Ethereum L2

\n

Revenue, last 30 days: $30,000+

\n

Primarily EVM

\n

6. ZyFAI​

\n

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.

\n

Revenue, last 30 days: $10,000+

\n

Source: DefiLlama

\n

What does this tell us?​

\n

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

\n

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

\n

The signals are already visible

\n

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

\n

Watch this space.

\n

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

", "url": "https://pushchain.github.io/push-chain-website/pr-preview/pr-1235/blog/highest-revenue-generating-crypto-ai-agent-protocols-of-2026/", "title": "Highest Revenue Generating Crypto AI Agent Protocols of 2026", "summary": "Find out the highest revenue generating crypto AI agent protocols of 2026", "date_modified": "2026-08-10T00:00:00.000Z", "author": { "name": "Push Chain", "url": "https://x.com/PushChain" }, "tags": [ "Key Features", "Deep Dives" ] }, { "id": "https://pushchain.github.io/push-chain-website/pr-preview/pr-1235/blog/how-do-ai-agents-transact-onchain/", "content_html": "

\"Cover

\n

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

\n

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

\n

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??

\n

Time to find out how.

\n

Quick TL;DR:

\n

\"AI

\n

What Is Inside a typical onchain Transaction?​

\n

On an EVM chain, a standard transaction usually contains:

\n\n

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.

\n

Let's walk through an example:

\n

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

\n

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

\n

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.

\n

How Does an AI Agent Sign Transactions?​

\n

There are two common architectures.

\n

1. Direct wallet signing​

\n

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.\nThe model proposes the action; the wallet system performs the cryptographic signing.

\n

BUT THIS IS A VERY INSECURE METHOD!

\n

An EOA private key grants unlimited, overarching spending authority.\nIf 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.

\n

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.

\n

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

\n

2. Smart-account execution​

\n

Over 40 million of these smart accounts have been deployed across Ethereum and Layer 2 networks.\nInstead 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.

\n

Session Keys for Granular Control​

\n

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.

\n

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

\n\n

How Agents Pay for APIs and Other Agents​

\n

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

\n

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

\n

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

\n

The transaction flow works like this:

\n
    \n
  1. Request: The agent requests a resource from a server.
    2. \n
  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. \n
  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. \n
  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.
    5. \n
\n

Summary:​

\n

AI agents do not directly “talk” to blockchains.

\n

They:

\n
    \n
  1. Interpret an objective
    2. \n
  2. select an approved tool
    3. \n
  3. construct a chain-specific transaction
    4. \n
  4. validate it against deterministic policies
    5. \n
  5. sign it through a wallet or smart account
    6. \n
  6. submit it through an RPC or bundler
    7. \n
  7. observe the resulting state change
    8. \n
", "url": "https://pushchain.github.io/push-chain-website/pr-preview/pr-1235/blog/how-do-ai-agents-transact-onchain/", "title": "How Do AI Agents Transact Onchain?", "summary": "Find out how crypto AI agents transact autonomously and securely.", "date_modified": "2026-08-03T00:00:00.000Z", "author": { "name": "Push Chain", "url": "https://x.com/PushChain" }, "tags": [ "Key Features", "Deep Dives" ] }, { "id": "https://pushchain.github.io/push-chain-website/pr-preview/pr-1235/blog/understanding-the-crypto-ai-agent-stack/", "content_html": "

\"Cover

\n\n

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.

\n

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

\n

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

\n

What makes this article different?​

\n\n

Crypto AI Agent Stack Explained Layer-wise​

\n

\"Crypto

\n

Layer 1: User and application​

\n

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

\n

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

\n

Layer 2: Agent runtime​

\n

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

\n

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

\n

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

\n

Layer 3: AI model and planner​

\n

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

\n

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.

\n

Layer 4: Memory and knowledge​

\n

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

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

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

\n

Layer 5: Data and perception​

\n

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

\n

Layer 6: Tools and action adapters​

\n

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

\n

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

\n

Layer 7: Wallet, identity and policy engine​

\n

A wallet gives an agent the power to

\n\n

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

\n

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

\n

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:

\n\n

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

\n

Layer 8: Blockchain and smart-contract execution​

\n

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

\n\n

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

\n

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.

\n

Layer 9 - Agent Economies​

\n

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

\n\n

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!

\n

Watch this space.

", "url": "https://pushchain.github.io/push-chain-website/pr-preview/pr-1235/blog/understanding-the-crypto-ai-agent-stack/", "title": "Understanding the Crypto AI Agent Stack (Layer by Layer)", "summary": "Understand what crypto AI agents are composed of and how they work behind the scenes in the simplest way possible.", "date_modified": "2026-07-27T00:00:00.000Z", "author": { "name": "Push Chain", "url": "https://x.com/PushChain" }, "tags": [ "Key Features", "Deep Dives" ] }, { "id": "https://pushchain.github.io/push-chain-website/pr-preview/pr-1235/blog/rwa-scale-across-multiple-chains/", "content_html": "

\"Cover

\n

Consider you’re building a tokenized treasury fund.

\n

Let's call it YieldVault.

\n

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

\n

Then the requests start coming in.

\n\n

This sure sounds like the road to PMF, right?

\n

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?

\n

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?

\n

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.

\n

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

\n\n

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.

\n

Every deployment is a separate product.​

\n

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.\nThis is where Push Chain does it differently.

\n

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.

\n

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

\n

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.

\n

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.

\n

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

\n

No. Not at all.

\n

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.

\n

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.

\n

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

", "url": "https://pushchain.github.io/push-chain-website/pr-preview/pr-1235/blog/rwa-scale-across-multiple-chains/", "title": "What Happens When RWAs Scale Across Multiple Chains?", "summary": "Learn how RWA apps can become universally accessible to any user on any chain using Push Chain's Universal Execution Layer.", "date_modified": "2026-07-16T00:00:00.000Z", "author": { "name": "Push Chain", "url": "https://x.com/PushChain" }, "tags": [ "Key Features", "Product" ] }, { "id": "https://pushchain.github.io/push-chain-website/pr-preview/pr-1235/blog/push-chain-completes-hacken-security-audit/", "content_html": "

\"Cover

\n

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.

\n

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.

\n

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.

\n

Today we're sharing the results.

\n

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

\n

Key Outcomes​

\n\n

The Security Audit Scope​

\n

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

\n
    \n
  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. \n
  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. \n
  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. \n
  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.
    5. \n
\n

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

\n

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.

\n

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

\n

Audit Findings​

\n

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

\n

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.

\n

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.

\n

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:

\n\n

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.

\n

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

\n

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

\n

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

\n

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.

\n

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.

\n

What's Next​

\n

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

\n

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.

\n

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.

\n

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.

\n

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

\n

Read the full Hacken audit reports

\n", "url": "https://pushchain.github.io/push-chain-website/pr-preview/pr-1235/blog/push-chain-completes-hacken-security-audit/", "title": "Push Chain Completes Hacken Security Audit, $100,000 Bug Bounty Launching Soon", "summary": "Push Chain is a complex system, it lets users from *any* chain, settled in one place. No bridges, gas in any token.", "date_modified": "2026-06-25T00:00:00.000Z", "author": { "name": "Push Chain", "url": "https://x.com/PushChain" }, "tags": [ "Featured", "Product", "Partnerships" ] }, { "id": "https://pushchain.github.io/push-chain-website/pr-preview/pr-1235/blog/introducing-zappi/", "content_html": "

\"Cover

\n

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

\n

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.

\n

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

\n

Here’s what it unpacks…

\n

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

\n

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.

\n

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

\n

This matters because payments need a common dollar layer.

\n

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.

\n

Read more about PUSD here

\n

What exactly does Zappi do?

\n

Global digital payments are now being taken over by Stablecoins.

\n

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

\n

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.

\n

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

\n

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

\n

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

\n

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

\n

Paid from any supported stablecoin, through any chain.

\n

That is what Zappi is designed for.

\n

How can I use Zappi?

\n\n

Where can I use Zappi?

\n

Zappi makes stablecoin payments easier for:

\n\n

Join our merchant network today!

\n

Start using Zappi

\n

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

\n

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

\n

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.

", "url": "https://pushchain.github.io/push-chain-website/pr-preview/pr-1235/blog/introducing-zappi/", "title": "Introducing Zappi - First Universal Payments App on Push Chain", "summary": "Introducing Zappi an anychain to anychain stablecoin payments app for freelancers, merchants, and businesses. Powered by PUSD, the Universal Stablecoin. Built on Push Chain.", "date_modified": "2026-06-04T00:00:00.000Z", "author": { "name": "Push Chain", "url": "https://x.com/PushChain" }, "tags": [ "Featured", "Product", "Ecosystem" ] }, { "id": "https://pushchain.github.io/push-chain-website/pr-preview/pr-1235/blog/introducing-pusd/", "content_html": "

\"Cover

\n\n

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.

\n

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.

\n

Challenges users and businesses face​

\n

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

\n

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

\n\n

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.

\n

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.

\n

That is the problem PUSD is built to solve.

\n

Missed opportunity:​

\n

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.

\n

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

\n

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

\n

What is PUSD?​

\n

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

\n

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

\n

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

\n

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

\n

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

\n

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

\n

Universal means Universal:\nPUSD 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.

\n

PUSD+ for yield-bearing exposure\nPUSD+ 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.

\n

How to mint PUSD?​

\n
\n

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

\n

Safest Stablecoin Yield​

\n

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

\n

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.

\n

How to earn yield on PUSD?​

\n
\n

Early Usecases​

\n

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.

\n

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

\n

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

\n

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.

\n

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.

\n

TLDR;​

\n

\"What

", "url": "https://pushchain.github.io/push-chain-website/pr-preview/pr-1235/blog/introducing-pusd/", "title": "Introducing PUSD: A Universal Stablecoin Built for the Future of Onchain Payments.", "summary": "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.", "date_modified": "2026-05-28T00:00:00.000Z", "author": { "name": "Push Chain", "url": "https://x.com/PushChain" }, "tags": [ "Featured", "Product", "Ecosystem" ] }, { "id": "https://pushchain.github.io/push-chain-website/pr-preview/pr-1235/blog/push-rewards-program/", "content_html": "

\"Cover

\n

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.

\n

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.

\n

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

\n

A program beyond social farming​

\n

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.

\n

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.

\n

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.

\n

Enter Push Chain Pass (Rare/Shinies)​

\n

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.

\n

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.

\n

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

\n

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

\n\n

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.

\n

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

\n

⚠️ 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.

", "url": "https://pushchain.github.io/push-chain-website/pr-preview/pr-1235/blog/push-rewards-program/", "title": "Push Rewards Program goes Public: Universal Network Meets Real Usage", "summary": "Following the launch of Donut Testnet and $PC ticker reveal, Push Chain has continued to gain strong momentum. Over the past few months,", "date_modified": "2026-05-21T00:00:00.000Z", "author": { "name": "Push Chain", "url": "https://x.com/PushChain" }, "tags": [ "Featured", "Programs" ] }, { "id": "https://pushchain.github.io/push-chain-website/pr-preview/pr-1235/blog/introducing-multihop-on-push-chain/", "content_html": "

\"Cover

\n

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

\n

Cross-chain today is still manual and bumpy

\n

For users:​

\n

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.

\n

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

\n

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!?

\n

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

\n

\"First

\n

For developers:​

\n

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

\n

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

\n

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.

\n

What multihop changes?

\n

For users:​

\n

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

\n

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

\n

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

\n

\"Second

\n

For devs:​

\n

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

\n

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.

\n

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.

\n

Refer to the docs for more detailed insights.

\n

Routing is automatic:\nYou 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.

\n

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

\n
CEA TL;DR

Chain Executor Accounts 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.

Read more about CEAs.

\n

Funds can move with any hop\nAny 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.

\n

Multiple calls can be batched into a single hop\nThe 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.

\n

Try It

\n

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

\n

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

", "url": "https://pushchain.github.io/push-chain-website/pr-preview/pr-1235/blog/introducing-multihop-on-push-chain/", "title": "Introducing Multihop on Push Chain", "summary": "Multihop allows you to compose multiple cross-chain operations into a single signed transaction. Ordered and tracked end-to-end.", "date_modified": "2026-05-15T00:00:00.000Z", "author": { "name": "Push Chain", "url": "https://x.com/PushChain" }, "tags": [ "Technical", "Deep Dives" ] } ] }