Mixoor

A privacy-preserving mechanism that enables users to send tokens/sol without creating an on-chain link between sender and recipient. The protocol uses zero-knowledge proofs (zk-SNARKs) to cryptographically guarantee privacy and integrates compliance screening to prevent illicit use.

How It Works

Deposit Phase: User deposits tokens into a pool. A cryptographic commitment (hash of secret + nullifier + amount) is generated client-side and emitted as an event in our program.

1. Proof Generation: When withdrawing, the user generates a zk-SNARK proof that demonstrates "I know a secret corresponding to some commitment in this tree" - without revealing which one.
2. Withdrawal Phase: Our relayer executes the withdrawal transaction, sending funds to the recipient. The zero-knowledge proof ensures no on-chain connection between the original deposit and the withdrawal.

Technical Details

Deposit Flow

1. User address is screened using the Range API to assess risk and compliance.
2. Client generates random secret and nullifier (32 bytes each)
3. Client computes the commitment: commitment = Poseidon(secret, nullifier, amount, pool)
4. Client builds a Merkle tree from on-chain CommitmentInserted events, inserts the new commitment, and computes the updated root.
5. Client submits the deposit transaction containing the commitment and the new Merkle root.
6. Program transfers assets to the vault PDA and emits a CommitmentInserted event.
7. Program stores the new Merkle root in a ring buffer (50 latest roots with timestamps)

Withdrawal Flow (via Relayer)

1. Backend receives the withdrawal request and validates that the commitment exists and the nullifier has not been spent.
2. Backend reconstructs the Merkle tree from on-chain CommitmentInserted events and derives the corresponding Merkle root.
3. Backend generates a zero-knowledge proof with the following public inputs: root, nullifierHash, recipient, relayer, fee, refund, poolId
4. The proof attests to knowledge of a valid commitment, proving possession of the associated secret and nullifier.
5. Backend invokes the update_root instruction, enabling safe concurrent withdrawals.
6. Relayer submits the proof transaction to the on-chain program.
7. Program verifies:
   • Proof validity
   • Root inclusion in history
   • Nullifier has not been used
8. The program executes transfers funds to the recipient minus the 0.15% protocol fee.

Sponsor Tech Used

Range API

• Integrated for address risk screening and compliance
• Prevents the protocol from being used for illicit financial activity while preserving privacy for legitimate users

Helius

• RPC endpoint for Solana network access
• Digital Asset Standard (DAS) API for fetching token metadata and user token balances

Project setup

The first thing you'll want to do is install NPM dependencies which will allow you to access all the scripts and tools provided by this template.

pnpm install

Managing programs

You'll notice a program folder in the root of this repository. This is where your generated Solana program is located.

Whilst only one program gets generated, note that you can have as many programs as you like in this repository. Whenever you add a new program folder to this repository, remember to add it to the members array of your root Cargo.toml file. That way, your programs will be recognized by the following scripts that allow you to build, test, format and lint your programs respectively.

pnpm programs:build
pnpm programs:test
pnpm programs:format
pnpm programs:lint

Generating IDLs

You may use the following command to generate the IDLs for your programs.

pnpm generate:idls

Depending on your program's framework, this will either use Shank or Anchor to generate the IDLs. Note that, to ensure IDLs are generated using the correct framework version, the specific version used by the program will be downloaded and used locally.

Generating clients

Once your programs' IDLs have been generated, you can generate clients for them using the following command.

pnpm generate:clients

Alternatively, you can use the generate script to generate both the IDLs and the clients at once.

pnpm generate

Managing clients

The following clients are available for your programs. You may use the following links to learn more about each client.

• JS client
• Rust client

Starting and stopping the local validator

The following script is available to start your local validator.

pnpm validator:start

By default, if a local validator is already running, the script will be skipped. You may use the validator:restart script instead to force the validator to restart.

pnpm validator:restart

Finally, you may stop the local validator using the following command.

pnpm validator:stop

Using external programs in your validator

If your program requires any external programs to be running, you'll want to in your local validator.

You can do this by adding their program addresses to the program-dependencies array in the Cargo.toml of your program.

program-dependencies = [
  "metaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1s",
  "noopb9bkMVfRPU8AsbpTUg8AQkHtKwMYZiFUjNRtMmV",
]

Next time you build your program and run your validator, these external programs will automatically be fetched from mainnet and used in your local validator.

pnpm programs:build
pnpm validator:restart

Disclaimer

This software is provided "as is" without warranty of any kind, express or implied. The authors and contributors assume no liability for any damages, losses, or legal consequences arising from the use or misuse of this software. Users are solely responsible for ensuring their use complies with all applicable laws and regulations. By using this software, you acknowledge that you understand and accept these terms.