phoenix
phoenixPhoenix - Your AI Assistant
Inactive session will be ended in 24 hours
End Session

Blockchain Developer – Smart Contracts, ZK & Cross-Chain

  • Posted:
  • Proposals: 7
  • Remote
  • #4509454
  • Open for Proposals
Adnan M.Edin D.Talha M.Kbizsoft SolutionsRahul T. + 2 others have already sent a proposal.
  • 1

Description

Experience Level: Expert
Project Description:

We need a freelance Blockchain Developer for a defined project to build smart contracts, integrate ZK proofs, and implement cross-chain settlement for a multi-chain protocol. This is a fixed-scope freelance engagement, not a permanent role.

Deliverables:

- Deploy smart contracts on Ethereum, Solana, Base, Arbitrum, and Polygon
- Integrate ZK proof systems (Ligero/Arc)
- Implement cross-chain settlement using CCTP and Hyperlane
- Integrate FHE (Fhenix/Zama) for encrypted state
- Build a backend API with Express and TypeScript for a 7-stage payment pipeline
- Provide tested, secure, and documented production-ready code

Required Experience:

- 4+ years in software development
- 2+ years in blockchain development with production deployments
- Solidity and TypeScript/Node.js
- Experience with EVM chains and cross-chain messaging (Hyperlane, Wormhole, or CCTP)
- Working knowledge of ZKPs and cryptography
- Experience working remotely and communicating asynchronously

Preferred (not required):

- Experience with Solana
- Familiarity with FHE (Fhenix/Zama)
- Prior work with CCTP in production

New Proposal

Login to your account and send a proposal now to get this project.

Log in

Clarification Board Ask a Question

  • David H.

    One area I'd want to validate early is how settlement finality is coordinated across chains, since the contracts, ZK verification, and cross-chain messaging should all derive state from a single source of truth to avoid replay or partial settlement scenarios. Have you already defined that settlement orchestration, or would you like it designed as part of the implementation?

    Yuri M.25 minutes ago

    You've identified the critical challenge. We've defined a sequential 7-stage pipeline with idempotent keys to prevent replay, using CCTP attestations as the verifiable bridge anchor for cross-chain finality and on-chain audit modules with Merkle proofs to reconcile deposits equals distributions. However, we view final settlement orchestration as a key design problem we want our engineering lead to help shape, particularly around handling in-flight states between CCTP burn and mint confirmation, and coordinating ZK proof verification with cross-chain settlement.

  • Asad C.

    - Regarding CCTP and Hyperlane integration, could you explain the expected cross-chain settlement workflow? Which assets or tokens will move across chains, what events should trigger settlements, and are there specific requirements for handling failed transactions, retries, message verification, or settlement finality?

    - Could you describe the complete 7-stage payment pipeline in detail? Specifically, what operations occur at each stage, which components interact with the blockchain, and should the backend handle transaction orchestration, queue management, event listeners, retries, notifications, and transaction monitoring?

    Yuri M.23 minutes ago

    Answer to Q1 (CCTP & Hyperlane Integration):
    USDC is the primary settlement asset. The workflow is: source chain burns USDC and generates CCTP attestation → Hyperlane relays the message to destination chain → destination chain mints USDC and enters shielded pool. For failed transactions, we retry with idempotent keys up to 3 times, then log for manual reconciliation. CCTP attestations provide finality verification; we also use Merkle proofs for audit reconciliation.

    Answer to Q2 (7-Stage Pipeline):
    Stage 1: USDC deposit on source chain (smart contract). Stage 2: ZK proof generation (client-side Ligero/Arc SDK). Stage 3: Swap to USDC if needed (Uniswap API). Stage 4: CCTP bridge burn-and-mint (smart contracts). Stage 5: Shielded pool deposit (Unlink SDK). Stage 6: Private transfer to recipient identity. Stage 7: Destination withdrawal (smart contract).

    The backend orchestrates all stages with queue management, event listeners for on-chain confirmations, retry logic for failures, and real-time status notifications to users. Transaction monitoring tracks each stage's progress with idempotent keys to prevent duplicate processing.