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.

In Web3, the narrative always ships before the product. The product ships after the community leaves.

No matter the bear or bull market over the last decade, one sentiment in crypto has always remained true: crypto is really hard to use.

This is the kind of feedback we still get today from the earliest degens and builders. Imagine the tyranny that hopeful newcomers and retail users had to face!

The sentiment wasn't always terrible.. There was an almost euphoric time when the entire industry thought that crypto was finally fixed.

(Note the extra emphasis on "almost")

The Promise of Chain Abstraction​

Sometime back in 2022, a new term was born — "Chain Abstraction"

The promise was simple: users would interact with apps in a way where they never even had to know they were using Web3 tech. The UX would be invisible. The chain would be invisible. Users would simply use crypto apps just like they use regular apps.

This framing was used everywhere: pitch decks, blog posts, conference keynotes, and even token launch announcements.

The idea felt so intuitive, so relatable, felt as if the dream of "onboarding a billion users" was finally turning into reality!

Hundreds of millions in funding. Super competitive landscape. Everything was looking ideal.

But today, over 90% of these projects are dead. (Quite literally)

What the fuck exactly happened to chain abstraction?

Who pulled the plug? Was the dream of uniting all chains just a hoax? Did VCs get rickrolled?

"In Web3, the narrative always ships before the product. The product ships after the community leaves."

Chain abstraction was no different.

The idea was real. The problem was real. The money was very, very real. What wasn't real (at least not yet) was the part where any of it actually worked for the person on the other end of the screen.

Why Abstraction Is So Hard to Build​

Because the underlying networks are financially incentivized to fight it.

In the early 2020s, the multi-chain world was sold as a feature. More chains meant more choice, more specialisation, more innovation.

What wasn't said loudly was that every new chain also meant a new token, a new ecosystem fund, and a new set of VCs with a financial interest in making sure they 10x their pot — regardless of whether anyone used the product.

Hundreds of L1s and L2s. Each one with its own liquidity, its own gas token, its own community convinced that theirs was the true one.

The industry is not fragmented by accident: it's fragmented because fragmentation is profitable.

The Intent Architecture Problem​

Most modern chain abstraction runs on something called intent-based architecture. The user says what they want ("swap this token on Ethereum for that token on Solana") and a third party called a Solver figures out how to make it happen.

What could be better than completely disappearing complexity from the user's screen, right? But the truth is, the complexity does not disappear — it simply moves a few steps away from the user.

To execute a cross-chain intent instantly, a solver must front their own capital on the destination chain and take on immense inventory risk.

Now tell me, who has the capital to maintain deep liquidity across 50 different, incompatible Layer 2s? Definitely not decentralized retail users. Only massive, institutional market makers (Wintermute, Jane Street, etc.)

Does this mean we just abstract away a decentralised bridge and replace it with a centralized cartel?

When market volatility spikes, these centralized solvers widen their spreads to protect themselves, or they simply stop filling intents altogether. The user's so-called "seamless" abstracted transaction either fails silently or gets hit with massive slippage!

The UX Illusion​

From a psychological standpoint, hiding the network name doesn't solve the core anxiety of Web3.

To achieve chain abstraction, the industry added multiple layers of middleware (Application → Permission/Intent → Solver → Settlement). This architectural bloat increases latency.

If an abstracted transaction takes 45 seconds to clear because a Solver is routing it through a complex cross-chain message protocol like LayerZero, the user still experiences the cognitive friction of waiting, wondering if their funds are lost in the ether.

Did we just paint over the rust instead of replacing the pipe?

The Identity Problem: Omnichain Networks​

Omnichain networks promise a seamless multi-chain world, but their architecture fundamentally breaks Web3's most critical component: persistent user identity.

Because they rely on proxy signers (like Threshold Signature Schemes) to execute cross-chain actions, the destination EVM never sees who actually initiated the transaction. It only sees "who called it last" — which is the bridge's proxy address.

To understand why this is a major security vulnerability and a hindrance to adoption, imagine building a lending aggregator. If a user on Solana wants to route a deposit into Aave on Ethereum, they don't have a persistent Ethereum address. Even using Aave's onBehalfOf parameter just shifts the problem, forcing the protocol to use the relayer/gateway contract as the beneficiary.

Now every single cross-chain user's Aave position risks getting pooled under the same proxy address!!

• There is no isolated health factor.
• There is no individual borrowing limit.
• One user's bad cross-chain trade could trigger liquidations for everyone sharing that proxy.

Which, by the way, is a big honeypot for attackers to ignore.

For borrowing, it gets worse. A user with no Ethereum history cannot pre-approve credit delegation for the proxy. Because ZetaChain doesn't natively solve this, developers are forced to build incredibly complex, per-user proxy architectures just to patch the bleeding.

The Messaging Layer Problem: LayerZero​

Protocols like LayerZero position their product as a universal messaging layer, allowing developers to build "Omnichain Applications" (OApps) that can seamlessly pass data and tokens across any network.

But behind the scenes, LayerZero's architecture heavily relies on off-chain Decentralized Verifier Networks (DVNs) and Executors. While marketed as modular and trust-minimized, the reality is that the underlying security is only as strong as the off-chain entities verifying the messages.

If a specific DVN configuration is compromised or colludes, the "immutable endpoint" on-chain is useless.

The Contagion Risk: LayerZero connects everything to everything. If a catastrophic vulnerability is found in a low-tier connected chain, or in the messaging standard itself, the blast radius is instantly transmitted across the entire ecosystem.

The official docs of LayerZero say "LayerZero is an omnichain interoperability protocol."

When your interop is message-based, every chain needs its own:

• Contract deployment
• DVN configuration
• Audit cycle

LayerZero's own docs pitch lzSend() and lzReceive() functions as "one framework, every chain." But "one framework" still means deploying and maintaining that framework N times across N chains.

For a protocol promising omnichain composability, the developer experience scales linearly with every chain you add. Which, to me, does not sound like chain abstraction — but more like managed fragmentation.

The Hope That Remains​

Even though things aren't looking great for chain abstraction, the hope is still not lost.

The kind of hope that's not just coming from the users but also from devs — and most importantly from projects who're fighting all the odds to build tech that abstracts every user experience and unites every chain. No strings attached.

All we need is one final Push.

Most apps lose on users before they’ve ever interacted with the product.

Not because the product feels complex to use. Because wallet creation is considered as a separate onboarding step.

Push Wallet Kit removes this separation. By provisioning a real wallet the moment a user signs up.

Here’s how to enable it in your app in just 4 steps:

Authentication becomes identity provisioning​

Usually onboarding requires two independent systems:

1️⃣ Authentication based (Google, email, socials)
2️⃣ Wallet creation and connection

It creates friction because users must create/import wallets before interacting with your app.

Push Chain combines these into a single identity layer. When a user logs in, Push provisions a wallet automatically. This wallet becomes the user’s persistent onchain identity.

Your app can now interact with the user immediately, without requiring manual wallet setup.

Step 1: Install Push Wallet Kit​

npm install @pushprotocol/ui-kit

This will give your app access to authentication, wallet provisioning, and wallet access through one interface.

Step 2: Configure social login methods​

Define which login methods your app should support:

This configuration enables authentication via Google and email.

When users authenticate using these methods, Universal Wallet automatically provisions a wallet for them.

Step 3: Initialize the Universal Wallet Provider​

Wrap your app with the Universal Wallet Provider:

This activates the Universal Wallet layer. It handles:

• Authentication
• Wallet provisioning
• Secure key management
• Session persistence
• Wallet availability across your app

Your app now has an identity and wallet layer ready to onboard users.

Step 4: Enable additional social login providers​

Push Wallet Kit also supports additional identity providers beyond Google and email.

You can enable providers listed below:

Each authentication method provisions the same Universal Wallet identity.

This means users can log in using familiar platforms, while your app still interacts with a consistent wallet layer.

What Universal Wallet enables​

Once authenticated, the user immediately has a usable wallet. This wallet:

• Persists across sessions
• Can sign transactions
• Can interact with smart contracts
• Is accessible programmatically inside your app

No extensions/manual wallet setup required.

What you unlock as a builder​

Users can log in and start using your app immediately. They can sign transactions, interact with contracts, and participate onchain, without creating or connecting a wallet manually.

Universal Wallet ensures wallet identity exists from the first interaction.

Takeaway:​

Push Wallet Kit unifies authentication and wallet provisioning into a single layer.

Authentication creates identity → Identity provisions the wallet → Wallet enables execution

Sounds game-changing, right? Explore here

Early Access for the FINAL season of Push Points Program before mainnet is live!

The hunt for the golden rare pass begins.

What is Points Program S3 about?​

S3 is an incentivized testnet program created to reward honest users for exploring and experiencing the magic of Universal Apps on Push Chain.

Use universal apps, earn points, collect rare passes, spin magic wheel, collect more rare passes, and top the leaderboard!

Points earned will unlock your eligibility for the Push Chain reward drop during mainnet launch.

What are the rewards?​

Rare Shiny Pass holders become eligible for many exciting rewards on mainnet day 1

1. A unique mechanism with perpetual rewards for Shiny Pass holders
2. Boosted APY staking rewards
3. MORE BIGGER BANGERRR rewards will be revealed in the coming days!

Note: S3 Leaderboard rankers unlock additional boosted rewards

What are Rare Passes? What do they unlock?​

Rare passes are unique collectables that have the potential to unlock greater rewards during TGE.

Only a tiny % of rare passes will evolve into golden shiny passes, confirming your reward.

The more rare passes you collect. The higher your odds of winning a golden shiny pass.

How can I get an entry into the early access?​

Early Access is open to a limited number of users only.

You need an invite code in order to get in.

The best place to find invite codes is this:

Remember! 1 invite = 1 user entry. Once you’re in, you can invite up to 3 more frens

How can I make the most out of this program?​

S3 is not just about play-to-earn. Look at the bigger scope here.

The apps you’ll be using are not normal crypto apps.

They are Universal in nature, meaning users across Solana and EVM, using wallets like MetaMask or Phantom, can interact with these apps without bridging.

Quick tips:

• Stay active on Discord and X for invite code giveaways.
• Collect as many rare passes as you can!
• Refer and onboard your frens and earn special multipliers
• The more you level up, the better your chances of winning a rare pass.

How does Push Chain work?​

Push Chain is an L1. But not “yet another L1”. It is a shared state network designed to unite different chains together.

You can use apps that exist not just on Push but every popular chain including Solana, Ethereum, Base, BNB and more. Stronger volume, better yields, incredible fun.

No new wallet. No need to bridge funds. Sign in with Google or any of your existing wallets.

Builders can deploy apps on push and instantly support users from Solana, Base, BNB, any EVM chain!

Participation Guidelines​

We’ve implemented sybil resistance checks to discourage botting and farming that doesn’t contribute meaningful value to users or the network.

Please use wallets with sufficient history and genuine activity.

Fair participation will be rewarded, while misuse may lead to restrictions.

If you have any questions, feel free to reach out to us on Discord

Join the program here - portal.push.org

If you’re building any cross-chain defi apps or want to upgrade your current app to cross-chain. This article’s for you.

We like to explain things with examples...

So let's say you’re building a lending aggregator that can read and route user deposits to the best yield across Aave on Ethereum, Compound Finance on Base, and MarginFi on Solana, or any other protocol on any chain.

Even though the idea sounds great and it would definitely attract an incredible amount of volume. But one honest fact that can't be ignored is how hectic it would be for devs to handle the cross-chain plumbing

A very unsexy problem​

AAVE and most mature DeFi protocols let you specify who a deposit is for. There's a parameter called onBehalfOf, so the caller and the beneficiary don't have to be the same address.

Sounds like it solves the cross-chain problem, right?

Not quite. Because onBehalfOf just shifts the question, it doesn't answer it. When a user from Solana, or any other chain, wants to deposit into AAVE on Ethereum: what address do you actually put there?

The user has no persistent Ethereum address. So you end up passing the bridge or relayer contract as the beneficiary. Which means every user's AAVE position lives under the same address, same health factor, same borrowing limit, same liquidation risk across all of them!!

And for borrowing, it gets worse. AAVE's onBehalfOf for borrows requires something called credit delegation. The beneficiary address has to have pre-approved the caller on Ethereum, before any borrowing can happen. A user with no Ethereum history can't do that.

So the real problem isn't msg.sender. It's that cross-chain users have no persistent, protocol-recognised address on the destination chain to begin with.

No consistent address = no isolated position = no real aggregator.

This is the identity problem in cross-chain DeFi. And it's what most interop protocols have actually failed to efficiently solve.

The destination chain has no way to distinguish users because EVM only sees who called it last and not the original initiator. Solutions like per-user proxy contracts on the destination chain or smart account patterns (which is essentially what Push Chain's UEA and CEA model does) exist, but they require the dApp to architect around this. And most cross-chain interop layers don't handle it natively.

Digs aside. Let’s actually acknowledge it and figure out a viable UNIVERSAL solution.

3 non-negotiable rules​

For a lending aggregator to work correctly across chains, 3 things must hold:

1. Each user must have an isolated, persistent identity on every target chain.
2. That identity must be deterministically derivable.
3. And most imp: The user must be able to act from anywhere. Their home chain, a different L1, L2, doesn’t matter!

Most current approaches solve (3) at the cost of (1). You do get semi-efficient cross-chain execution, but at the cost of identity collapse and extreme development overhead.

The architecture that actually works​

The pattern that solves this mess cleanly is called CEA - Chain Execution Account: A smart contract deployed on each target chain, deterministically derived from the user’s identity on the coordination layer (i.e Push Chain)

Each CEA is derived from the parent UEA plus the target chain ID.

Same user, different chains - but always the same deterministic address.

If you’re new to the concept of UEA would recommend checking this quick guide on UEAs first. What are UEAs?

The flow for a deposit looks like this:

Now AAVE sees a consistent, user-specific address every single time. The health factor is isolated. Borrow limits are per-user. Liquidations behave correctly.

What This Unlocks for Aggregator Design​

With per-user CEAs in place, the aggregator contract on Push Chain can do things that were structurally impossible before.

Cross-chain collateral loops become straightforward: Deposit ETH on AAVE via CEA_ETH, borrow USDC against it, route the USDC back to the UEA, redeploy it on Base via CEA_BASE. Each hop preserves identity. No position bleed between users.

Unified health factor monitoring is now coherent: Because each CEA maps 1:1 with a UEA, a smart contract on Push Chain can track CEA_ETH → AAVE position and CEA_ARB → Compound position for the same user and act on either.

A natural extension to this feature would also be: Automated liquidation protection: trigger a repayment to CEA_ETH when health drops below threshold

Withdrawals route CEA → UEA via a funds transfer route, so capital can be swept back to the coordination layer and redeployed elsewhere without needing additional account infrastructure.

The Part worth sitting with​

Bridges solve asset movement. Relayers solve message passing. But neither solves the question of who is acting on the destination chain. CEAs answer that question cleanly, and once that's answered, the rest of the aggregator design becomes significantly less complicated.

If you're building cross-chain DeFi infrastructure, this is the piece to get right first.

Want to find out more cool things about Push Chain?

Check out our knowledge base

And experience the power of UNIVERSAL APPS here.

Most people think wallet security is about private keys.
Yet, most exploits happen when assets move between chains.

This Maker Monday explains how Push Chain handles asset movement across chains without bridges, and why that changes the security model completely. Let’s dive in!

Usual problem with bridges

Here’s how a bridge works & where it exploits the assets:

1️⃣ you lock assets on chain A
2️⃣ a small set of signers controls a pool
3️⃣ a wrapped version appears on chain B

If that signer set is compromised, the wrapped assets become useless. That’s not a UX issue, that’s a design issue.

Push doesn’t aim to fix the bridge’s security. We avoid needing them in the first place.

If asset movement depends on a small signer set, security will always be fragile.

Wallet security is really “who can approve a transfer.”​

On Push, assets are controlled using MPC (Multi-Party Computation), built with Silence Labs. Read more about the integration here.

Here’s the simplest way to think about it:

• There is no single private key
• The “key” is split across multiple validators
• No validator can move funds alone
• A minimum number of signers must agree every time

Nothing gets signed unless the network agrees.
This isn’t about hiding keys better. It’s about removing unilateral control.

Even if one validator is hacked, nothing moves.

What “Universal Assets” actually mean​

Universal Assets let you use assets from other chains directly on Push.

Examples:
ETH → pETH
SOL → pSOL
USDC → pUSDC

These are not wrapped tokens.

• 10 ETH locked → 10 pETH minted
• 10 pETH burned → 10 ETH released

Same amount. Same value. Always 1:1.

No pools.
No peg maintenance.
No oracle tricks.

There’s no scenario where users hold an unbacked asset.

How assets are moved into Push:​

Let’s say you’re a Solana user with SOL!

Here’s what actually happens:

1. You sign once on Solana

2. Your SOL is locked via a Universal Gateway

3. Funds move into an MPC-controlled vault

4. Validators verify:

   → Transaction happened
   → Amount is correct
   → Funds are secured

5. Push mints the same amount of pSOL to your account

That’s it.
No second transaction.
No bridge UI.

No extra claiming step.
Assets are secured before they’re usable.

Here is a flow diagram showing how a native asset moves from an external chain to the Push Chain and back, without bridges, wrapped tokens, or trusted relayers.

How assets leave Push Chain:​

Leaving Push is the reverse, and this is where security really shows.

1. You burn pSOL on Push
2. A burn proof is emitted
3. Validators independently verify it
4. A threshold of validators co-sign a release
5. Your original SOL is sent back to Solana

Key details:

• Validators never “send” funds directly
• They only produce partial signatures
• The MPC vault releases exactly what was burned

You can’t release more than you burned.
The math won’t allow it.

There’s no bridge pool to drain ever.

Threshold signing doesn’t run inside the validator itself.

• Validators handle consensus and verification
• A separate MPC signer (sidecar) handles cryptography
• Even if validator logic fails, keys remain protected

This separation limits the blast radius.
Breaking consensus logic doesn’t give you access to funds.

How does this change failure modes?​

Here’s the real difference compared to bridges:
If a bridge breaks → wrapped assets break
If Push halts → assets stay locked safely

Burn proofs still exist. Funds don’t disappear. They just wait.

Takeaway:
Most systems assume bridges are unavoidable.
Push assumes asset movement itself must be constrained.

That’s the shift:

• from trusting signers
• to enforce rules at the protocol level

Wallet security isn’t about better warnings.
It’s about making bad outcomes impossible.

Ballsy looks singular on paper.​

It’s one game with one rule set, producing a canonical outcome, and by web3 instinct, that immediately feels risky.

But that instinct confuses shared rules with shared control. You can have a shared state without giving up decentralized execution.

Ballsy is simple. But what it requires isn’t. Ballsy is a cross-chain game where every player, no matter which chain they’re on, interacts with the same game state and gets the same outcome.

One game with one set of rules, and with one shared truth.

Here’s how most teams would approach building something like Ballsy today:

• Deploy the game separately on each chain
• Each deployment tracks its own state
• Outcomes are synced after the fact

There’s no shared state and no obvious center, which makes it feel decentralized, but in reality, it isn’t state-authoritative.

And this design doesn’t fail loudly; it fails quietly. Rules start updating at different times, edge cases get handled inconsistently, and over time, state transitions stop lining up.

Each instance appears “correct,” but collectively, they drift apart. This is where the real issue begins.

You don’t actually have decentralization, what you have is duplicated authority over state across multiple consensus domains.

Push Chain solves this by removing duplication, not control.

Ballsy runs on:

• A single authoritative game state
• One source of truth for outcomes
• One consensus-enforced rule set

So execution remains decentralized.

Ballsy runs with a single authoritative game state, a single source of truth for outcomes, and one consensus-enforced rule set.

The distinction most systems miss is simple, but critical: State authority is not the same as execution authority.

Push Chain unifies what counts as a valid action, how state progresses, and what the final outcome is without unifying where actions originate, who submits transactions, or how users retain sovereignty.

And when state authority is unified, a lot of unnecessary complexity simply disappears.

There’s no need for syncing logic, no reconciliation layer, and no debates over which deployment is “correct.”

Not because the complexity moved somewhere else but because it was never necessary to begin with.

Ballsy depends on this model. Without a single authoritative state, cross-chain determinism breaks, and outcomes eventually diverge.

If your app has multiple places that decide state truth, you don’t have resilience. You have ambiguity.

Push Chain doesn’t centralize apps.

It unifies state authority under a single consensus domain, so execution can remain decentralized.

One source of truth, with many execution environments.

Don’t just read, experience it! Interact with different chains and observe how the outcome remains consistent.
👉 https://ballsy.push.org/

“Shared State” sounds risky, and that instinct is correct.

If execution happens across chains, what stops?

→ partial updates
→ reorg bleed-through
→ inconsistent global state

Not all chains finalize blocks the same way​

Different chains provide different levels of finality:

Deterministic style finality​

• Once committed, blocks are effectively irreversible
• Confirmation is certain
• Reorg risk is negligible

Probabilistic finality​

• Blocks can be reorganized within a window
• Early confirmations are not absolute
• Finality strengthens over time

This difference is where most cross-chain complexity begins.

How Push Chain separates execution from state​

Push Chain enforces a strict rule:

Execution cannot directly mutate Shared State.​

Execution can:

• read shared state
• run logic
• compute outcomes

But it cannot commit state changes directly. Only canonical block commits can update Shared State.

The mental model​

Think of execution as a sandboxed simulation:

• Transactions propose changes
• Execution computes the result
• But nothing is applied yet

Only when a block becomes canonical:

• Results are committed
• Shared State is updated

If a block is dropped or reorganized:

its effects never enter the canonical Shared State​

Where risk is actually handled​

Shared State does not mean shared risk.

Push Chain handles risk before state is committed, not during execution.

Transactions can be handled differently depending on:

• value sensitivity
• finality characteristics of the source chain

At a high level, this creates two modes:

1. Fast path (UX-first, bounded risk)

Used for:

• lower-value interactions
• cases where instant UX matters

How it works:

• execution proceeds without waiting for deep finality
• reorg risk is bounded at the protocol level
• safeguards limit worst-case exposure

Result:

• near-instant user experience
• controlled, limited risk
• no corruption of Shared State

2. Finalized path (risk-minimized)

Used for:

• higher-value transactions
• environments with probabilistic finality

How it works:

• waits for sufficient confirmation depth
• execution results are committed only after strong finality

Result:

• slower than fast path
• negligible reorg exposure
• fully stable canonical state

What happens when things go wrong?​

Reorgs

• Non-canonical blocks are discarded
• Their execution results are ignored

Shared State reflects only the surviving canonical chain. No partial updates. No global drift.

Execution failures

If execution reverts:

• No canonical commit
• No state transition
• No cross-chain inconsistency

Execution failure ≠ state corruption.

Why this distinction matters

Shared State does not mean:

• shared execution risk
• shared failure modes
• shared reorg exposure

Instead:

• execution is isolated
• risk is handled before commit
• state updates happen only through canonical consensus

That’s the difference between:

“Everything touches everything,” and “everything resolves through one authority.”

Takeaway​

Even in a multi-chain environment:

• execution can fail
• chains can reorg
• transactions can be reordered

But Shared State remains predictable, consistent, and corruption-resistant

Because execution never had the authority to mutate it in the first place.

Try it before trusting it. The boundary is visible at the client layer.

👉 push.org/docs/chain/build/initialize-push-chain-client/

What is a Universal Stablecoin?​

A universal stablecoin is a dollar you can use on one chain while the actual asset stays on another.

You don’t bridge it.

You don’t wrap it.

You don’t move liquidity around.

Instead, the original stablecoin is locked on its source chain, and Push Chain mints a 1:1 representation (pUSD) that you can use immediately.

From a user’s perspective, it behaves like any other stablecoin. From the system’s perspective, nothing actually “moves”.

That distinction matters because it’s what lets Push avoid bridges without giving up security.

Push Chain doesn’t move dollars across chains.

It mirrors ownership.

The diagram here shows how a user from any EVM / non-EVM chain, like Solana here, can mint pUSD from USDC in just a couple of clicks:

Lock on the source → mint on Push → burn on Push → release on source.

No wrapping

No liquidity hops

No extra “claim your token” step

Minting 1 pUSD​

Example: A user has USDC on Ethereum and wants to use it on an app built on Push.

Here, the user just signs one txn on Ethereum.

Under the hood:

• The Universal Gateway receives the USDC
• Funds are transferred into an MPC TSS vault
• A lock event is emitted on the source chain

The asset never left Ethereum.

Why does MPC vault matter here?​

It isn’t a multisig that anyone controls

• The signing key is split across validators
• No single party can move funds
• Only threshold consensus can execute the txn

This is what makes the mint secure.

How Push Chain verifies minting​

Universal Validators watch the source chain.

They independently verify:

• The lock actually happened
• Funds are in the MPC vault
• The user signature is valid
• Amounts match exactly

Once enough no. of validators agree, Push Chain is told:

“This lock is real.”

That’s the only condition for minting.

Push mints exactly the locked amount of pUSD.

It’s credited to the user’s UEA:

• Deterministically derived from their source address
• Same identity, just different execution layer

From the user’s POV:

• One signature
• pUSD usable immediately
• No follow up txn

pUSD supply isn’t market-managed. It’s state-managed.

Withdrawing pUSD back to your chain's native stablecoin​

Nothing is released unless something is burned.

When a user wants to withdraw a required amount:

• Exact number of pUSD is burned on Push Chain
• A burn proof is emitted
• Validators verify the burn

Only after threshold consensus:

• Validators generate partial signatures
• These combine to authorize the MPC vault
• The vault releases exactly the burned amount

Burn 100 pUSD → release 100 USDC on the source chain.

What does the user get?​

The asset lands:

• On the original chain
• At the original address
• As the original token

Why pUSD matters to builders​

This design quietly removes a lot of complexity:

• No bridge liquidity assumptions
• No fragmented balances
• No identity remapping

You can build apps assuming:

one user, one balance, one execution surface, even if assets live on external chains.

To know more about pUSD - read our quick thesis.

We’re about to launch pUSD very soon. Join our Discord or Telegram to be the first to know when it’s live!

Stablecoins removed volatility, fixing crypto’s biggest usability blocker.

That’s why today, one dollar in the real world means one dollar onchain. Further enabling trading, lending, payments, and most DeFi primitives.

But execution and settlement are two different things. Execution is fine. Settlement is still broken. They are not designed for a world where value lives across dozens of chains at the same time.

This blog dives into:

• where stablecoins quietly break
• why this isn’t a UX problem
• and how Push approaches stablecoins differently

Issue: Dollars that exist, but don’t cooperate​

USDC on Solana is worth $1

and USDC on Base is also worth $1

Same issuer. Same backing. Same trust assumptions

Yet the system we all built treats them like strangers.

They have separate liquidity pools, settle independently, and don’t share liquidity naturally. Even though economically, they represent the exact same dollar!

So you end up with money that’s globally trusted, but siloed on a single chain.

This is definitely not a bridging problem, nor a wallet problem.

It’s a chain-bound settlement problem.

Fragmentation isn’t theoretical (it’s visible everywhere)​

Let’s take @aave as an example on one chain

You see • ETH–USDC

• ETH–USDT

• ETH–USDe

Three different pools & versions of same dollar with zero shared depth.

Theoretically, this looks reasonable. In practice, it creates friction we’ve learned to accept as “normal.”

Liquidity that should reinforce itself ends up competing with itself. Rates flatten out. Depth gets thinner. And execution quietly worsens, even when there’s plenty of capital.

Now extend this across:

→ hundreds of protocols

→ dozens of chains

→ multiple wrapped/bridged versions

Ecosystem isn’t suffering from a lack of capital. It’s short on “capital that can be aggregated”.

Why this matters more than you think​

This fragmentation leaks into everything.

• Liquidity stays shallow

Even with high demand, split pools can’t compound efficiently. Yields look fine until you compare them to the depth potential of unified pools.

• Execution degrades

Stable-to-stable swaps still incur slippage, which feels wrong, but is considered normal.

• Capital sits idle

Bridges move balances, they don't unify state. Liquidity locked in siloed pools or sitting mid-bridge isn't doing anything.

Stablecoins make crypto usable for the masses.

Fragmentation makes it inefficient to use.

The bottleneck is settlement, not trust​

USDC issued by @circle is trusted across chains.

USDT from @tether is too.

The ecosystem already agrees on issuer trust, economic value, and redemption assumptions.

What it doesn’t share is state.

Bridges move balances from one chain to another, but nothing is actually unified. They copy and leave liquidity in siloed pools.

This is where Push takes a unified stance.

Universal Settlement on Push Chain​

On Push, stablecoins don’t stay isolated just because they originated on different chains.

Instead of treating:

• USDC on Ethereum
• USDC on Solana
• USDC on Base as fundamentally separate assets

They are allowed to converge at settlement, as long as the underlying trust assumptions match.

The idea is simple, even if implementation isn’t: equivalent dollars shouldn’t fragment just because execution environments differ.

A simple mental model (which actually holds)​

You can think about universal stablecoins on Push in three steps

1. Issuer Trust

   If two stablecoins share the same issuer or equivalent trust model, they’re economically the same.

2. Unified Settlement

   That equivalent value converges into a shared settlement layer instead of staying split across chains.

3. Universal Execution

   Apps execute against shared liquidity, regardless of where users enter from.

No wrapping. No duplicated pools. No competing versions of the same dollar.

pUSD: The Universal Stablecoin​

This settlement model shows up as pUSD

pUSD is not:

• a new peg or
• a wrapper token

pUSD is a native settlement asset that represents converged stable value on Push Chain.

Think of pUSD as a clearing layer, not a currency.

Stablecoins with accepted trust assumptions settle into pUSD. Where they come from doesn’t matter at execution. Liquidity is shared, not mirrored.

For users, this looks like one balance which just works. For builders, it’s one settlement asset to reason about instead of many.

How pUSD makes DeFi more efficient​

Once the settlement is unified, second-order effects compound fast:

• AMMs stop competing for liquidity and start sharing it
• Lending markets scale without chain specific ceilings
• Yield products don’t fragment by deployment
• Payments become globally native by default

pUSD not only cleans things up.

It makes certain kinds of apps possible, the kind that break down when liquidity and settlement are split across chains.

TL;DR​

Crypto already has global money.

What’s been missing is a global settlement.

Universal stablecoins don’t add complexity. They remove artificial distinctions between assets which were already economically equivalent.

That’s the direction Push Chain is moving ahead.

Takeaway:

Stablecoins solved volatility.

Universal stablecoins solve fragmentation.

Know about the underlying tech that's bringing this concept into reality - https://push.org/docs