Skip to content

Feat/private transfer#204

Draft
Huygon764 wants to merge 18 commits intodevelopfrom
feat/private-transfer
Draft

Feat/private transfer#204
Huygon764 wants to merge 18 commits intodevelopfrom
feat/private-transfer

Conversation

@Huygon764
Copy link
Copy Markdown
Contributor

@Huygon764 Huygon764 commented Mar 10, 2026

Types of change

  • Feature
  • Bug
  • Enhancement

Private Transfer (Mixer) — Exploration

⚠️ This is an exploration/proof-of-concept, not a production-ready feature. It demonstrates the idea of private fund movement on-chain. Whether this becomes part of the product is still undecided.

What it does

Allows a user to deposit funds into a shared pool and later withdraw the same amount to a different address. There is no on-chain link between the depositor and the withdrawer — an observer cannot tell who sent funds to whom. We use it to deposit fund to multisig account. Not for payroll feature

How it works (simplified)

  1. Deposit: User picks a token and a fixed amount (e.g. 0.01 ETH), confirms the transaction. Funds go into a shared Mixer pool on-chain.
  2. Wait: Other users also deposit. The more users in the pool, the harder it is to guess who is who.
  3. Withdraw: User generates a cryptographic proof (ZK proof) in the browser that says "I have a valid deposit" without revealing which one. A relayer submits the withdrawal on-chain so the user's wallet never appears in the transaction.
  4. Result: Funds arrive at the chosen recipient address from the relayer, not from the user's wallet.

Known limitations / Drawbacks

If this feature moves toward production, the following gaps need to be addressed:

  • Fixed denominations (tradeoff): Users can only deposit/withdraw preset amounts (e.g. 0.01 ETH, 10 USDC). This is intentional — if users could choose any amount, each amount would create its own pool with potentially only one user, making it trivially traceable. Fixed amounts force users into shared pools for better privacy, but at the cost of flexibility.
  • Amount is still visible: The deposit and withdrawal amounts are public on-chain. Only the sender-recipient link is hidden.
  • No compliance mechanism: No viewing keys for auditors, no address screening (e.g. OFAC). Without these, it has the same legal risks as Tornado Cash.
  • Relayer is a single point of failure: If the backend goes down, withdrawals are blocked. No backup relayer or fallback exists.
  • Timing correlation: Deposits and withdrawals close in time can be correlated. No random delay mechanism is implemented.

…ents (#200)

- Updated QuestPage layout for better responsiveness with max-width and padding adjustments.
- Changed BatchTransactions and TransactionSummary components to use flexbox for improved item alignment and responsiveness.
- Enhanced QuestCard to allow for flexible width.
- Added titles for new routes in the Title component.
* refactor: adjust z-index values across various components for improved UI layering

* feat: add timing constants for HTTP timeouts, cache TTL, and retry delays

- Introduced new timing constants in `timing.ts` for backend and nextjs packages.
- Updated index files to export the new timing constants for better accessibility.

refactor: replace hardcoded values with timing constants for retries and timeouts

- Updated various services and modules to utilize new timing constants for retries and timeouts, improving maintainability and consistency across the codebase.
- Adjusted `waitForReceiptWithRetry`, `PriceService`, `ZenTransferService`, `TransactionService`, and `ZkVerifyService` to use centralized timing configurations.

refactor: replace hardcoded values with timing constants across components and hooks

- Updated various components and hooks to utilize new timing constants for polling intervals, refetch intervals, and timeouts, enhancing maintainability and consistency throughout the codebase.
- Adjusted `NotificationItem`, `ClaimSection`, `EditAccountModal`, and several hooks to reference centralized timing configurations.

refactor: standardize formatting and improve component styles

- Refactored various components to enhance code readability by standardizing formatting, including consistent indentation and spacing.
- Updated styles across components to utilize new shadow and height constants for improved UI consistency.
- Adjusted text sizes in multiple components to ensure uniformity in typography.
… sections (#206)

- Updated ChooseNetwork component to include wallet connection checks and commitment validation, enhancing user experience with appropriate notifications.
- Adjusted StatusContainer to allow copying of commitment addresses to clipboard for better usability.
- Enhanced Sidebar component to incorporate wallet connection status in navigation logic.
* Refactor test

* feat: enhance transaction E2E tests to support multi-asset transfers

- Added support for ETH, ZEN, and USDC in transaction flow tests.
- Introduced utility functions for ERC20 token transfers and balance checks.
- Refactored account funding logic to accommodate multiple asset scenarios.
- Updated test descriptions for clarity and consistency.

* Add batch to e2e flow

* Refactor test local

* Change log for human read

* clean up unused code

* Test for staging

* Change address ZEN token of horizen testnet

* Refactor for DRY
* Improve UX of Transfer page

* Improve UX of Batch page

* Improve UX of EditAccountModal

* Enhance transaction loading feedback in Dashboard and modals

- Updated TransactionRow component to display detailed loading steps during transaction approval.
- Integrated step loading functionality in useTransactionVote hook for improved user experience during transaction processes.

* Changed button label from Transfer now to Submit Transfer to enhance user understanding during the transfer process.
* Payroll: Create batch for group

* Change global css
- Enhanced readability by reformatting import statements and function parameters in `mixer.controller.ts`, `mixer.indexer.ts`, and `mixer.service.ts`.
- Added new components for the Mixer UI: `DepositTab`, `WithdrawTab`, `MixerContainer`, and `PoolStats`.
- Implemented hooks for managing deposits and withdrawals in `useMixerDeposit` and `useMixerWithdraw`.
- Updated DTOs in the shared package to improve type validation.
- Introduced new API methods in `mixerApi` for handling deposits and withdrawals.
- Added state management for cached commitments in `WithdrawTab` to optimize withdrawal processes.
- Updated `getWithdrawableSlots` in `useMixerWithdraw` to return commitments alongside slots, reducing redundant API calls.
- Refactored `useMixerKeys` to utilize refs for base secret management, improving performance during concurrent calls.
- Adjusted `useMixerWithdraw` to accept commitments as parameters, streamlining the withdrawal flow.
@Huygon764 Huygon764 force-pushed the feat/private-transfer branch from 4b64cc4 to 0f80cd2 Compare March 17, 2026 09:26
@Huygon764 Huygon764 force-pushed the develop branch 4 times, most recently from a479f9a to cc77d2a Compare March 20, 2026 06:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant