Unified Accounts System: A Single Account for Cross-Chain Operations

Development of Unified Accounts System

Have you faced the situation where you need to keep a dozen wallets for working in different blockchains and manually transfer liquidity? Our team of engineers solves this problem with a unified accounts system — a single account that works across all networks. This is not just a convenient abstraction, but an architectural solution combining deterministic contract deployment, cross-chain synchronization, and intent-oriented execution. Let's examine how this works at the smart contract and infrastructure level. Unified accounts evolve from a multi-chain approach (many wallets) to chain-abstraction (one wallet, transparent multi-chain). The task is non-trivial: implementing it correctly means solving several independent technical problems simultaneously. Our team's experience in cross-chain development — over 10 successful projects.

How does a unified account solve the liquidity fragmentation problem?

When working with several L1/L2 chains (Ethereum, Polygon, Arbitrum, Optimism, Base), the user is forced to keep funds on each network separately. A unified account uses CREATE2 for deterministic addressing and synchronizes state through a secure bridge. This allows having a single logical balance that is automatically available on all chains without manual transfers. Compare: in a traditional scheme, to stake 100 USDC in a protocol on Arbitrum, you first need to transfer USDC from Ethereum — that's at least two transactions and 15 minutes of waiting. In a unified account, the user indicates the intent, and the system itself routes liquidity through the optimal bridge in a couple of clicks. We guarantee that gas and time savings reach 40–60% on typical operations.

What is a unified account at the technical level?

Naive implementation: a smart contract on each supported chain with the same address (via CREATE2), state synchronization via a bridge. This works but creates complexity: state is fragmented, synchronization has latency and cost.

Advanced implementation separates four layers: Identity, Intent, Execution, Settlement. Each layer solves its own task, and together they provide a seamless cross-chain experience.

Deterministic Addresses via CREATE2

The first step is the same address on all EVM chains:

// Factory contract with the same address on all chains
contract AccountFactory {
    function deployAccount(
        bytes32 salt,
        bytes calldata initCode
    ) external returns (address account) {
        // CREATE2: address depends only on factory address + salt + initCode
        // If factory is deployed via keyless deployment (same address on all EVM),
        // then Account will also have the same address
        assembly {
            account := create2(0, add(initCode, 32), mload(initCode), salt)
        }
        
        if (account == address(0)) revert DeploymentFailed();
    }
    
    function predictAddress(
        bytes32 salt,
        bytes32 initCodeHash
    ) external view returns (address) {
        return address(uint160(uint256(keccak256(abi.encodePacked(
            bytes1(0xff),
            address(this),
            salt,
            initCodeHash
        )))));
    }
}

Keyless deployment (via ERC-2470 Singleton Factory or Nick's method) ensures the same factory address on all EVM chains. Consequently — the same salt + initCode = the same account address on all chains. ERC-2470: Singleton Factory is the standard method for deploying contracts with the same address.

Cross-chain state synchronization

The second step — synchronizing account data between chains. For example: the user updates the list of owners on Ethereum, this should be reflected on Polygon.

Pattern: Primary chain + synchronization via bridge:

contract UnifiedAccountPrimary {
    // Primary state stored on the "home" chain
    mapping(address => bool) public owners;
    uint256 public nonce;
    
    // Synchronize changes to other chains
    function addOwnerAndSync(
        address newOwner,
        uint64[] calldata targetChains,
        address[] calldata targetAccounts
    ) external onlyOwner {
        owners[newOwner] = true;
        
        // Send update via bridge (CCIP, Axelar, LayerZero)
        for (uint i = 0; i < targetChains.length; i++) {
            bytes memory payload = abi.encode(
                "ADD_OWNER",
                newOwner,
                ++nonce
            );
            
            bridge.sendMessage(targetChains[i], targetAccounts[i], payload);
        }
        
        emit OwnerAdded(newOwner);
    }
}

contract UnifiedAccountReplica {
    // Replica receives updates from Primary
    uint256 public lastSyncedNonce;
    
    function receiveSync(
        bytes calldata payload,
        bytes32 originMessageId
    ) external onlyBridge {
        (string memory action, address target, uint256 nonce) = 
            abi.decode(payload, (string, address, uint256));
        
        // Replay protection: nonce must be the next
        require(nonce == lastSyncedNonce + 1, "Invalid nonce");
        lastSyncedNonce = nonce;
        
        if (keccak256(bytes(action)) == keccak256(bytes("ADD_OWNER"))) {
            _addOwner(target);
        }
    }
}

Intent-based execution

Unified account accepts user intents, not specific transactions. The user says "I want to stake 100 USDC in protocol X" — the system itself decides where to get USDC and on which chain to execute:

interface UserIntent {
  action: "stake" | "swap" | "transfer" | "borrow";
  targetProtocol: string;
  targetChain?: number;  // optional — if not specified, system chooses
  inputToken: string;
  inputAmount: string;
  outputToken?: string;
  minOutputAmount?: string;
  deadline?: number;
}

class IntentRouter {
  async resolveIntent(intent: UserIntent, userProfile: UserProfile): Promise<ExecutionPlan> {
    // 1. Find the best chain for execution
    const targetChain = intent.targetChain || 
      await this.findOptimalChain(intent, userProfile);
    
    // 2. Determine where to get funds
    const fundingSource = await this.findBestFundingSource(
      intent.inputToken,
      intent.inputAmount,
      userProfile.balances,
      targetChain
    );
    
    // 3. Build execution plan
    const steps: ExecutionStep[] = [];
    
    if (fundingSource.chainId !== targetChain) {
      // Need a bridge
      steps.push({
        type: "bridge",
        fromChain: fundingSource.chainId,
        toChain: targetChain,
        token: intent.inputToken,
        amount: intent.inputAmount,
        bridgeProtocol: await this.selectBridge(fundingSource.chainId, targetChain),
      });
    }
    
    // Main action
    steps.push({
      type: intent.action,
      chainId: targetChain,
      protocol: intent.targetProtocol,
      ...
    });
    
    return {
      steps,
      estimatedGas: await this.estimateTotalGas(steps),
      estimatedTime: this.estimateTime(steps),
    };
  }
}

Gasless cross-chain operations

For a complete UX of a unified account — the user should not think about gas. The system abstracts this:

// User pays in USDC, system converts to native tokens
async function executeGasless(
  intent: UserIntent,
  feeToken: "USDC" | "USDT" | string
): Promise<string> {
  const plan = await intentRouter.resolveIntent(intent, userProfile);
  
  // Calculate total cost in feeToken
  const totalCostInFeeToken = await priceOracle.convertGasCost(
    plan.estimatedGas,
    plan.steps.map(s => s.chainId),
    feeToken
  );
  
  // Get UserOperation with sponsored gas
  const userOp = await buildSponsordUserOp(plan, feeToken, totalCostInFeeToken);
  
  // Sign once on the source chain
  const signedOp = await userAccount.signUserOperation(userOp);
  
  // Executor relay executes all steps
  return relayer.submitIntent(signedOp);
}

Account abstraction as a foundation

Unified accounts are natively built on ERC-4337: Smart account instead of EOA on each chain, UserOperations as a unit of intent, Bundler as executor, Paymaster as gas abstraction layer. ZeroDev Kernel, Safe with modules, or a custom implementation — the choice depends on the required flexibility.

The atomicity problem

Critical question: what happens if step 1 (bridge) succeeds, but step 2 (stake on the target chain) fails with an error? Options: Optimistic execution (continue, record pending state, retry on failure), Atomic through escrow (funds in escrow contract until final step confirmation), Two-phase commit (prepare → commit/rollback). In practice, most systems use optimistic with retry mechanism and manual fallback (funds remain on the target chain if the action is not executed).

Comparison of cross-chain communication approaches

What is included in the unified account development

1. Analysis of target networks and synchronization requirements.
2. Designing identity and intent layer architecture.
3. Deploying factory contracts via keyless deployment.
4. Integrating a bridge protocol and setting up synchronization.
5. Implementing intent router with gas abstraction support.
6. Integrating frontend SDK.
7. Deploying to testnet and conducting an audit.
8. Deploying to mainnet and launch.

Timelines

• Basic unified identity (CREATE2 same addresses, basic sync): 4-6 weeks
• Intent routing + cross-chain execution: 6-8 weeks
• Gas abstraction + feeToken: 3-4 weeks
• Production hardening + security audit: 6-8 weeks
• Total: 4-6 months

The budget for unified account development is calculated individually. Contact us, provide the specification of used chains and synchronization requirements — we will prepare an individual proposal with accurate timelines. Request a consultation to evaluate your project and get professional turnkey development.

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.