Integrating Particle Network for chain abstraction

Integrating Particle Network (chain abstraction)

We often face the task of building a universal dApp that works across multiple blockchains. Users want to interact with a protocol on Base while having funds on Ethereum. The standard approach — manual bridging — requires 3–5 transactions, up to 30 minutes waiting, and high gas costs. Particle Network solves this with Universal Accounts: one account, one balance, one signature for any chain. This is the next step after Account Abstraction — abstraction not only of the wallet but of the entire multi-chain environment.

Our experience shows: basic integration takes 2–3 weeks, and full integration with Universal Accounts takes up to 6 weeks. Below we break down the key components and the connection process.

What problems does chain abstraction solve?

Multi-transaction complexity. Users perform 3–5 operations instead of one: approve on Ethereum, bridge, approve on target chain, then the main transaction. Particle Network compresses this into a single operation, automatically selecting the optimal liquidity source. According to Particle Network documentation, Universal Accounts reduce transactions by 3–5 times, and gas savings can reach 60% — for active users, this means thousands of dollars per month.

Gas complexity. Each blockchain requires its own native token for fees. Universal Gas allows paying gas with any ERC-20 token (USDC, USDT, ETH) — conversion happens automatically.

Latency and liquidity. Users must wait for bridge transaction confirmations (up to 30 minutes) and monitor bridge liquidity. Particle Network uses a cross-chain layer that aggregates multiple bridges (Axelar, LayerZero, Wormhole) for instant operations. Recently we integrated Particle Network for a DeFi protocol on 5 chains: transaction time dropped 3x, and user churn due to complexity decreased by 40%.

How we implement integration: stack and configuration

Connect Kit — the entry point

import { ConnectButton, useAccount, usePublicClient } from "@particle-network/connectkit";
import { mainnet, base, polygon } from "@particle-network/connectkit/chains";
import { AuthType } from "@particle-network/auth-core";

// Provider setup
export default function App() {
  return (
    <ConnectKitProvider
      config={{
        projectId: "YOUR_PROJECT_ID",
        clientKey: "YOUR_CLIENT_KEY",
        appId: "YOUR_APP_ID",
        chains: [mainnet, base, polygon],
        walletConnectors: [
          evmWalletConnectors({
            metadata: { name: "Your App" },
            multiInjectedProviderDiscovery: true,
          }),
          authWalletConnectors({
            authTypes: [AuthType.email, AuthType.google, AuthType.twitter],
            fiatCoin: "USD",
            promptSettingConfig: {
              promptMasterPasswordSettingWhenLogin: 1,
            },
          }),
        ],
        plugins: {
          wallet: {
            visible: true,
          },
        },
      }}
    >
      <YourApp />
    </ConnectKitProvider>
  );
}

Universal Account for cross-chain operations

import { useUniversalAccount } from "@particle-network/universal-account-sdk";

function CrossChainButton() {
  const { smartAccount } = useUniversalAccount();
  
  async function executeOnBase() {
    const transaction = {
      to: BASE_CONTRACT_ADDRESS,
      value: parseEther("0.1"),
      data: encodeFunctionData({ abi, functionName: "deposit" }),
      chainId: 8453, // Base
    };
    
    // The system automatically:
    // 1. Checks user balances across all chains
    // 2. Selects optimal liquidity source
    // 3. Performs cross-chain operation if needed
    // 4. Executes transaction on Base
    
    const txHash = await smartAccount.sendTransaction(transaction, {
      feeQuotes: await smartAccount.getFeeQuotes(transaction),
    });
    
    console.log(`Transaction: ${txHash}`);
  }
  
  return <button onClick={executeOnBase}>Execute on Base</button>;
}

Universal Gas in practice

const feeQuotes = await smartAccount.getFeeQuotes({
  to: TARGET_CONTRACT,
  value: 0n,
  data: calldata,
});

const usdcQuote = feeQuotes.find(q => q.tokenInfo.symbol === "USDC");

const txHash = await smartAccount.sendTransaction(tx, {
  feeQuote: usdcQuote,
  tokenPaymaster: usdcQuote.tokenPaymaster,
});

Why choose Universal Accounts?

With Particle Network, transaction count is reduced by 3–5x compared to traditional bridges, and gas costs are cut by up to 60% thanks to payment in cheap stablecoins. This solution is 2x faster to integrate than alternatives. Users get a unified experience without knowing about internal bridges or tokens. For developers — one SDK and one integration for all chains.

What's included in the integration work?

Estimated timelines

Basic flow (social login + embedded wallet + gasless) — from 2 to 3 weeks. Adding Universal Accounts with cross-chain logic — another 1–2 weeks. Full customization with non-standard features — up to 6 weeks. Cost is calculated individually; we guarantee a fixed price after audit. Contact us for an accurate project estimate.

Step-by-step integration guide

1. Register your project in Particle Dashboard.
2. Install packages: npm install @particle-network/connectkit @particle-network/universal-account-sdk.
3. Configure the provider with your keys.
4. Implement social or email login.
5. Add getFeeQuotes call for gas payment with any token.
6. Use smartAccount.sendTransaction for cross-chain operations.
7. Test on testnet before mainnet deployment.

Common integration mistakes

{
  "paymaster": {
    "tokens": ["USDC", "USDT", "ETH"],
    "feeQuotesLimit": 3
  }
}

Our team has years of Web3 experience and has successfully delivered 10+ projects with chain abstraction for DeFi, NFT, and gaming. Get a free consultation — write to us for a project evaluation. We'll help you choose the optimal stack and timelines.

Additional resources: Particle Network documentation on GitHub.

Cross-Chain Bridge Development: Architecture, Risks, and Implementation

We develop cross-chain bridges and cross-chain solutions end-to-end. We know how to avoid disasters. A few years ago, the Binance BNB Chain bridge lost $570M — the attacker forged a Merkle proof in BSC's native bridge. That same year, Wormhole lost $320M: guardian signature verification was bypassed through a bug in Solana's secp256k1 program. Ronin Bridge — $625M. These are not coincidences. Bridges are the most attacked infrastructure in Web3 because they aggregate liquidity and have complex cross-chain verification logic.

Why Do Bridges Break? Three Architectural Classes of Vulnerabilities

Finality and Reorg Issues. Ethereum has probabilistic finality before The Merge and economic finality after (2 epochs, ~12 minutes). Bitcoin — ~6 blocks (~60 minutes). Solana — ~400ms. If a bridge mints wrapped tokens on the destination chain immediately after 1-2 blocks on the source — a reorg of 3+ blocks allows the attacker to obtain tokens on the destination while the source transaction is reverted. Correct protection: wait for finality confirmation specific to each chain. For Ethereum — 64+ blocks (2 epochs). Not one block.

Signature Verification. Most bridges use a multisig committee or threshold signature: N out of M validators must sign the event from the source chain. Wormhole used 13 out of 19 guardians. The attack was not on the keys themselves — the attacker found a vulnerability in the signature verification code on Solana, where an outdated sysvar account was accepted as valid without verification. On-chain signature verification is harder than it seems.

Lock-and-Mint vs Burn-and-Mint. In the lock-and-mint model, original tokens are locked in a contract on the source chain, and wrapped tokens are minted on the destination. The source contract is a honeypot: all locked TVL is there. One bug in the unlock logic — and all funds are available to the attacker without needing to do anything on the destination chain. Native burn-and-mint (like Circle CCTP for USDC) is safer: no locked pool.

How to Choose a Messaging Layer for Your Project?

LayerZero — a protocol for arbitrary message passing between chains. Not a bridge itself, but infrastructure for building bridges and omnichain applications.

Architecture: Endpoint contract on each chain, Executor (delivers messages to the destination chain), DVN (Decentralized Verifier Network — verifies the transaction fact on the source chain).

Source chain:
  OApp.send() → Endpoint.send() → [emits packet event]

Destination chain:
  DVN verifies packet hash → Executor calls Endpoint.deliver() → OApp.lzReceive()

In v2, the developer chooses DVNs: official (LayerZero Labs, Google Cloud, Polyhedra), or custom. One can configure required DVN + optional DVN: a message is accepted only if all required DVNs confirm. This allows building bridges with different trade-offs between security and speed.

OApp (Omnichain Application) — the base contract for integration. Inherit OApp, implement _lzSend and _lzReceive. For token bridges — OFT (Omnichain Fungible Token) standard out of the box does burn-on-source / mint-on-destination.

Wormhole uses a network of 19 guardians (large companies like Jump Crypto, Everstake, etc.), each signing observed events. Threshold — 13 out of 19. VAA (Verified Action Approval) — a signed message that is accepted on the destination chain.

Main difference from LayerZero: Wormhole has native support for non-EVM chains: Solana, Aptos, Sui, Algorand, Near. For projects needing a bridge between Ethereum and Solana — Wormhole is often the only production-ready option.

After the exploit, Wormhole added Native Token Transfers (NTT) — an architecture without a locked pool, similar to CCTP. NTT + Hub-and-Spoke model: redundant liquidity is not accumulated on one chain.

Relay Architecture and Light Client Verification

Relay-based bridges (IBC in Cosmos ecosystem, Succinct's Telepathy) verify the source chain's state via a light client on the destination chain. For EVM→EVM: a contract on Ethereum stores and verifies BLS signatures of the source chain's blocks.

ZK-bridges are the next level. Succinct, Polyhedra zkBridge, Electron Labs generate a ZK-proof of the correctness of the source chain's consensus. On the destination chain, the proof is verified, not the validator signatures. Removes trust in the committee. But ZK-proof verification is gas-expensive — from 200k to 500k gas on Ethereum L1 depending on the proof system. A ZK-bridge is safer than a relay-based bridge but requires 2-3 times more gas for verification.

What Does Cross-Chain Bridge Development Include?

We implement the project turnkey and deliver a complete set of results. Our clients receive:

Implementation: What to Consider Before the First Line of Code

Mandatory components for any production bridge:

Pauser. Emergency pause function, called by multisig or automatically upon anomaly detection (suspicious volume, atypical call sequence). Most hacked bridges did not have or did not use a pauser in time.

Rate limiting. Limit output volume per time interval. If an attacker drains the bridge — rate limit gives time to react. Implementation: transferVolume[currentEpoch] += amount; require(transferVolume[currentEpoch] <= epochLimit).

Finality checks. Specific to each chain. Not "wait 1 block", but use finality API or wait for required number of confirmations.

Relayer monitoring. An autonomous service that monitors the state of both bridge sides. If a message is sent but not delivered within N minutes — alert. If locked balance diverges from totalSupply of wrapped token — critical alert.

Timeline and Cost

A simple ERC-20 bridge on top of an existing messaging layer (LayerZero OFT or Wormhole NTT) — 4-8 weeks including testing and audit. A custom bridge with own verification, multi-chain support, rate limiting, monitoring — 12-24 weeks. A ZK-bridge with custom proof circuits — from 6 months.

Bridge audit takes longer than a standard DeFi protocol audit: cross-chain scenarios, finality edge cases, reorg attacks must be tested. Minimum 3-4 weeks for a production-grade solution.

Cost is calculated individually after workload assessment. We have been working since 2018 and have completed 15+ projects in blockchain infrastructure. Contact us — we will evaluate your project and propose the optimal bridge architecture.