Skip to content

ZK-073: Redesign relayer binding and zero-relayer semantics across SDK and contract code #349

Open
#443
#458
Open
ZK-073: Redesign relayer binding and zero-relayer semantics across SDK and contract code#349
#443
#458
Labels
area: withdrawWithdrawal circuit constraints and proof semanticsbountyEligible for Drips Wave bounty reviewcircuitsNoir circuit and proving workcomplexity: highDrips complexity: high / 200 pointspriority: highCritical path work for the current wavesecuritySecurity review, audit prep, and hardening worktestingCoverage, fixtures, fuzzing, and regression workwave: zk-2Wave 2: ZK parity, backend, and deployment hardening

Description

@ANAVHEOBA
ANAVHEOBA
opened on Apr 26, 2026

Wave: PrivacyLayer ZK Wave 2
Issue Key: ZK-073
Area: withdraw
Priority: High
Drips Complexity: High

Summary

Recipient binding is not the only mismatch. Relayer handling still mixes zero-field sentinels, decoded addresses, and fee rules in ways that are easy to misapply across stacks.

Relevant Code

  • sdk/src/encoding.ts
  • sdk/src/proof.ts
  • circuits/withdraw/src/spend.nr
  • contracts/privacy_pool/src/core/withdraw.rs
  • contracts/privacy_pool/src/utils/address_decoder.rs
  • contracts/privacy_pool/src/utils/validation.rs

Scope

  • Define one relayer binding contract for no-relayer, relayer-with-fee, and malformed-relayer cases.
  • Align SDK serialization, circuit validation, and Soroban withdraw handling around that contract.
  • Cover fee zero, relayer zero, and relayer mismatch cases in end-to-end tests.

Acceptance Criteria

  • Relayer handling no longer depends on ad hoc zero-address assumptions in multiple modules.
  • The contract accepts only relayer encodings that the SDK can produce canonically.
  • Regression tests distinguish absent relayer from malformed relayer cleanly.

Out of Scope

  • New wallet UX and non-ZK frontend polish
  • Unrelated Soroban business logic outside the withdrawal proof boundary

Dependencies

  • ZK-036
  • ZK-072

Validation

  • Inspect derived checks: node scripts/zk_ticket_check.mjs --issue-key ZK-073
  • Run derived checks: node scripts/zk_ticket_check.mjs --issue-key ZK-073 --run
  • Pull requests should include Wave Issue Key: ZK-073 in the title or body.

References

  • sdk/src/encoding.ts
  • sdk/src/proof.ts
  • circuits/withdraw/src/spend.nr
  • contracts/privacy_pool/src/core/withdraw.rs
  • contracts/privacy_pool/src/utils/address_decoder.rs
  • contracts/privacy_pool/src/utils/validation.rs

Activity

  1. ANAVHEOBA
    added
    bountyEligible for Drips Wave bounty review
    circuitsNoir circuit and proving work
    testingCoverage, fixtures, fuzzing, and regression work
    securitySecurity review, audit prep, and hardening work
    priority: highCritical path work for the current wave
    Stellar WaveEligible to be picked up by the Stellar Wave program
    complexity: highDrips complexity: high / 200 points
    area: withdrawWithdrawal circuit constraints and proof semantics
    wave: zk-2Wave 2: ZK parity, backend, and deployment hardening
    on Apr 26, 2026

  2. Mrchinedum commented on Apr 26, 2026

    @Mrchinedum
    Mrchinedum
    on Apr 26, 2026 – with Drips Wave

    @Mrchinedum has applied to work on this issue as part of the Stellar Wave Program's 4th wave.

    Hi, I’d like to take this on.

    I’ll standardize relayer handling across SDK, circuit, and contract into a single consistent model.

    Approach:

    • Define a strict relayer encoding contract:

      • no relayer (absent)
      • valid relayer + fee
      • malformed relayer (explicitly rejected)

    • Align:

      • sdk/src/encoding.ts (canonical serialization)
      • sdk/src/proof.ts (proof inputs)
      • circuits/withdraw/src/spend.nr (validation rules)
      • contract withdraw + address validation logic

    • Remove reliance on ad-hoc zero-address checks across modules

    • Ensure only SDK-canonical relayer formats are accepted by contract

    • Add end-to-end tests covering:

      • no relayer vs zero relayer vs malformed relayer
      • fee = 0 edge case
      • relayer mismatch rejection

    I’ll make relayer semantics consistent and enforceable across the full stack.

    Wave Issue Key: ZK-073

    ℹ️ Repo Maintainers: To accept this application, review their application or assign @Mrchinedum to this issue.

  3. drips-wave commented on Apr 26, 2026

    @drips-wave
    drips-waveBot
    on Apr 26, 2026 – with Drips Wave

    Congratulations, @soomtochukwu! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on April 29, 2026.

    🧑‍💻 @soomtochukwu: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

    Warning

    When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

    🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

    🌊 Happy Wave 🌊

  4. slendereater-sketch commented on May 5, 2026

    @slendereater-sketch
    slendereater-sketch
    on May 5, 2026

    /attempt

  5. harishn1408 commented on May 5, 2026

    @harishn1408
    harishn1408
    on May 5, 2026

    ⚡ Syndicate Flash-Response: Initial Architecture

    I have analyzed this issue and am currently deploying a full fix.

    Initial Proposed Architecture:

    • High-concurrency worker layer to handle the load.
    • Edge-cached validation for sub-10ms response times.
    • Syndicate-optimized state management.

    Full PR incoming in < 5 minutes.

    🚀 Conway Syndicate | Wallet: 0x3E8D731Cb653e9B68Aa9c7E19889c1dD14Ea2180

  6. harishn1408 commented on May 6, 2026

    @harishn1408
    harishn1408
    on May 6, 2026

    ⚡ Syndicate Flash-Response: Initial Architecture

    I have analyzed this issue and am currently deploying a full fix.

    Initial Proposed Architecture:

    • High-concurrency worker layer to handle the load.
    • Edge-cached validation for sub-10ms response times.
    • Syndicate-optimized state management.

    Full PR incoming in < 5 minutes.

    🚀 Conway Syndicate | Wallet: 0x3E8D731Cb653e9B68Aa9c7E19889c1dD14Ea2180

  7. harishn1408 commented on May 6, 2026

    @harishn1408
    harishn1408
    on May 6, 2026

    ⚡ Syndicate Flash-Response: Initial Architecture

    I have analyzed this issue and am currently deploying a full fix.

    Initial Proposed Architecture:

    • High-concurrency worker layer to handle the load.
    • Edge-cached validation for sub-10ms response times.
    • Syndicate-optimized state management.

    Full PR incoming in < 5 minutes.

    🚀 Conway Syndicate | Wallet: 0x3E8D731Cb653e9B68Aa9c7E19889c1dD14Ea2180

  8. laolaoqi commented on May 11, 2026

    @laolaoqi
    laolaoqi
    on May 11, 2026

    🏢 Bid: AI-Assisted Delivery

    I'm interested in taking this on. I run an AI-augmented development pipeline that delivers production-quality code with human-level review.

    ✅ What I bring

    • Core skills: Cryptography & signing schemes, Security architecture, Rust/Cargo toolchain, JavaScript/TypeScript, React/Vue frontend, Node.js backend, SDK development, Python tooling, Blockchain development, Smart contracts
    • Delivery approach: I analyze requirements → implement with AI code generation → human review & test → submit clean PR with passing CI
    • Communication: Daily progress updates, open to feedback loops during implementation

    📋 Proposed Timeline: 5-7 days

    I'll start immediately upon assignment and deliver within the estimated timeframe with regular checkpoints.

    💰 Payment

    • Wallet: 0x6c21794E27C34E93cd0049918d04Da58FC72595c (ETH/BSC/Polygon/Arbitrum — any EVM chain)
    • Happy to discuss milestone-based payments if preferred

    🔗 Track Record

    I have successfully delivered multiple bounty issues across Web3 infrastructure, monitoring stacks, SDK work, and content sprints. References available on request.

    Let me know if you'd like a more detailed technical proposal. I can break down the approach, architecture, and implementation steps before starting.

  9. laolaoqi commented on May 11, 2026

    @laolaoqi
    laolaoqi
    on May 11, 2026

    Bid - ZK-073: Redesign relayer binding and zero-relayer semantics

    I can take on this high-complexity ZK wave 2 task. The scope involves cleaning up relayer handling across SDK encoding, Noir circuits, and Solidity withdraw logic - replacing zero-field sentinels with a unified binding strategy.

    What I bring:

    • Strong ZK/circuit experience (Noir, Circom, Solidity verifiers)
    • Previously worked on PrivacyLayer ZK issues (ZK-062, ZK-065, ZK-011 - all submitted/merged)
    • Comfortable with multi-stack changes (SDK ? circuits ? contracts)

    Timeline: 7-10 days depending on scope clarification

    Payment Address: 0x6c21794E27C34E93cd0049918d04Da58FC72595c

  10. laolaoqi commented on May 11, 2026

    @laolaoqi
    laolaoqi
    on May 11, 2026

    Bid - ZK-073: Relayer binding redesign across SDK, circuits, and contract

    I can handle this full-stack ZK refactor. Here's my approach:

    What I'll deliver:

    • Unified relayer binding contract covering no-relayer, relayer-with-fee, and malformed-relayer cases
    • SDK serialization alignment (encoding.ts + proof.ts) with canonical relayer encoding
    • Circuit validation update in spend.nr (Noir) to enforce the binding contract
    • Soroban contract changes in withdraw.rs + address_decoder.rs + validation.rs
    • End-to-end regression tests for zero-relayer, fee-zero, and mismatch cases

    Timeline: 7-10 days for full implementation, including cross-module testing

    Technical capability:

    • Noir/ZK circuit development
    • Soroban (Stellar) smart contract development
    • SDK/TypeScript engineering
    • Cross-stack alignment (circuit ? SDK ? contract)
    • Security-first mindset - this is a high-priority security-related issue

    Wallet for payout: 0x6c21794E27C34E93cd0049918d04Da58FC72595c

    I'm familiar with ZK-036 and ZK-072 dependencies. Ready to start.

  11. drips-wave
    removed
    Stellar WaveEligible to be picked up by the Stellar Wave program
    on May 13, 2026

  12. WuMingDa-10 commented on May 18, 2026

    @WuMingDa-10
    WuMingDa-10
    on May 18, 2026

    Bounty Claim

    GitHub Username: WuMingDa-10

    Action Completed:

    • Completed the task as described

    Expected Reward: As specified in the bounty

    Please verify and distribute rewards. Thank you!

  13. tranha80 commented on May 30, 2026

    @tranha80
    tranha80
    on May 30, 2026

    Dear Hiring Manager,

    I am writing to express my keen interest in the ZK-073 project: "Redesign relayer binding and zero-relayer semantics across SDK and contract code" for the PrivacyLayer ZK Wave 2. As a seasoned Freelancer with extensive experience in ZK circuit design, secure smart contract development (Rust, Soroban), and robust SDK implementation, I am confident in my ability to deliver a comprehensive and high-quality solution to this critical "High Priority" and "High Drips Complexity" issue.

    Understanding the Challenge:
    I recognize the core problem described: the current relayer handling suffers from ambiguity due to mixed "zero-field sentinels," decoded addresses, and fee rules. This inconsistency across the SDK, ZK circuits, and Soroban contracts creates a brittle system prone to misapplication, potential security vulnerabilities, and difficulties in reasoning about the system's state. The reliance on ad hoc zero-address assumptions across multiple modules is a clear indicator for the need of a unified, canonical approach.

    My Proposed Solution & Approach:
    My strategy will focus on establishing a robust and unambiguous relayer binding contract, ensuring seamless and secure integration across all relevant components:

    1. Define a Canonical Relayer Binding Contract: I will start by thoroughly analyzing the existing implementations and proposing a single, unambiguous data structure or standard for relayer binding. This contract will explicitly differentiate between:
    2. *   **No Relayer:** A clearly defined state indicating the absence of a relayer.

    3. *   **Valid Relayer with Fee:** A structured representation for a present relayer, including its address and associated fee (which may be zero).

    4. *   **Malformed/Unsupported Relayer:** Cases that are explicitly rejected during serialization or validation, preventing them from entering the system.

    5. This contract will eliminate the reliance on implicit zero-address assumptions.
    6. Align Cross-Stack Implementation: I will meticulously align the SDK's serialization logic (sdk/src/encoding.ts, sdk/src/proof.ts), the ZK circuit's validation rules (circuits/withdraw/src/spend.nr), and the Soroban contract's handling (contracts/privacy_pool/src/core/withdraw.rs, contracts/privacy_pool/src/utils/address_decoder.rs, contracts/privacy_pool/src/utils/validation.rs) with the newly defined canonical contract. This ensures that a relayer encoded by the SDK is always correctly interpreted and validated by the circuit and contract, and vice-versa.
    7. Robust Validation Logic: I will implement clear and concise validation logic within the ZK circuits and Soroban contracts

  14. Terrajlz commented on Jul 6, 2026

    @Terrajlz
    Terrajlz
    on Jul 6, 2026

    I'd like to work on this.

    GitHub: https://github.com/terrajlz
    Payout (MetaMask / USDC on Base): 0xFbF5E1F071Be8fe0FB171257c3eE2b5B894FBB6E

    Recent work:

    • Nobay Protocol: 21/21 Hardhat tests passing, 15-finding security audit, full OZ v5 migration
    • DeXe Protocol: identified High-severity tx.origin vulnerability in PoolFactory (SWC-115)
    • Audited contracts across Aave V3, GMX, Uniswap V3, MakerDAO, Lido, ENS, Ethena

    I can deliver clean, tested code with security audit. Turnaround: 24 hours. Ready to start immediately.

  15. rushikeshgarad2024-dev commented on Sep 21, 2026

    @rushikeshgarad2024-dev
    rushikeshgarad2024-dev
    on Sep 21, 2026

    I have implemented the complete solution for ZK-073 in PR #458 (#458).

    Solution Overview:

    • Redesigned relayer binding and zero-relayer semantics across SDK and contract verifier.
    • Explicitly differentiates self-relay vs third-party relayer execution with zero-relayer address and fee invariants.
    • Full parity with circuit expectations and Soroban contract verification.

    Wave Issue Key: ZK-073
    Stellar Payout Address: GC5U46IS25KYFKNHDXEHR3KTQB3DVIBM4NW5BH4MVUE2G77STCJP4IHF

  16. themaksat commented on Sep 21, 2026

    @themaksat
    themaksat
    on Sep 21, 2026

    I have submitted a solution for this issue in PR #466. Full implementation and verification included. Payout wallet (Solana): 2BTCUUTviLNDtZDRBhPBTwSXZMrTttPJNbGevMXBBMKK

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: withdrawWithdrawal circuit constraints and proof semanticsbountyEligible for Drips Wave bounty reviewcircuitsNoir circuit and proving workcomplexity: highDrips complexity: high / 200 pointspriority: highCritical path work for the current wavesecuritySecurity review, audit prep, and hardening worktestingCoverage, fixtures, fuzzing, and regression workwave: zk-2Wave 2: ZK parity, backend, and deployment hardening

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions