Privacy-Preserving Builder Codes for Revenue Sharing

TL;DR

• The Problem: Apps and wallets route billions in volume to AMMs and DeFi protocols, but proving attribution often means public tagging onchain transactions, which exposes user behavior and competitive intelligence.
• The Solution: A threshold OPRF construction (read more > Introducing TACEO:OPRF) where wallets blind-tag transactions (for blind attribution), networks commit them to Merkle trees (for verifiability), and redemption happens via nullifiers that prove (exactly once) “I referred this volume” without revealing which specific transactions.
• The Result: Verifiable payment for transaction flow with zero linkability. Wallets get provable compensation, users stay private, AMMs and others can’t reverse-engineer competitor strategies.

The Attribution Paradox

Wallets like Phantom, MetaMask, Ledger route billions in user transactions to AMMs every month. They’d like verifiable compensation for that volume. (read about ERC-8021: Ethereum should take this lesson from Hyperliquid (here’s how) - on X). But proving attribution means tagging transactions onchain, and those tags would reveal exactly what competitors would pay millions to see: which users trade where, how much, and when.

Builder codes align incentives, but attribution destroys privacy. Tag your transactions publicly, and you’ve handed your user behavior data and competitive intelligence to anyone watching the chain.

Current solutions force a difficult trade-off:

• Trust-based deals: Off-chain legal agreements with no public verification, no transparency.
• Builder codes (public tagging): Wallets attach identifiers to transactions. Everyone can link that wallet’s entire user base to specific onchain actions.

The question: can one prove “I referred these transactions” without revealing which transactions, which users, or how much any competitor is earning?

The answer is a combination of nullifiers and merkle trees backed by a threshold OPRF network. The wallet proves it generated transaction flow, the user stays unlinkable, and the competitive intelligence stays hidden.

Payment for Transaction Flow: Crypto Version

Payment for transaction flow follows the TradFi model (Robinhood routing to Citadel), but onchain:

Wallets and app builders bring users, AMM and other protocols want volume, revenue sharing aligns incentives. But onchain transparency makes it impossible to track attribution privately. Until you add a cryptographic layer that solves attribution without exposure.

Existing Solutions and Their Trade-offs

ERC-8021 (Ethereum’s “Transaction Attribution” tagging proposal): Wallets attach referral tags so validators can share fees. Tags are public. Volume is public. User behavior is public. Works for transparent fee-sharing but fails on privacy.

DFlow: A DEX aggregator that scores transaction flow quality so DEXs can charge different fees depending on how toxic the flow is. Useful for pricing, but not solving the attribution problem.

What’s missing: cryptographic proof of attribution while maintaining privacy for users, wallets, and pricing structures.

The Protocol

Protocol Flow in Three Steps

Between a wallet and an AMM

1. Tag → Wallet computes a blind referral tag for each transaction (from a wallet’s secret key and a random nonce). Attaches tag to transaction sent to AMM.

2. Commit → AMM determines fees generated, inserts [tag, fee_value] pair into a public Merkle tree (Referral Tree). Anyone can verify insertions are honest.

3. Redeem → Wallet queries TACEO:OPRF service to compute a nullifier on each tag, proving to the smart contract: “I know tags in Referral Tree that sum to $X in fees” + “Here’s a fresh nullifier proving I haven’t redeemed these before” + “Pay me my percentage.”

No one learns which transactions are being claimed, which users were involved, or what competitors are earning.

The OPRF network holds the missing piece: a nullification key that no single party controls. When a wallet redeems, the network blindly transforms public referral tags into unlinkable nullifiers, proving ‘I referred this volume’ without revealing which specific transactions are being claimed. The wallet’s secret key protects who generated the referrals. The OPRF severs the link between tag and redemption.

The Referral Flow

1. User Transaction

The wallet receives a transaction formulated by a user.

2. Blind Transaction Tagging

The wallet owns a secret key $sk$. For every transaction it routes:

1. Sample a random nonce $x_i$
2. Compute referral tag: $r_i=H(sk,x_i)$
3. Attach $r_i$ to the transaction

The AMM or protocol sees the tag but learns nothing about the wallet’s identity or other transactions. The tag is deterministic but reveals nothing.

3. The Referral Tree

The AMM:

1. Executes the transaction and determines fees generated ($b_i$)
2. Inserts $[r_i,b_i]$ into a public Referral Tree (Merkle tree)
3. Publishes the updated Merkle root onchain

This commits all tagged transactions and their fee values. Anyone can audit. If the AMM lies about fees or omits a referral, fraud is provable via Merkle proof.

The transaction flow is committed publicly, but tags are blinded. No one can link $r_i$ back to a specific wallet without knowing the wallet’s $sk$ and nonce $x_i$.

The Redemption Flow

4. The OPRF Recognition Layer

The wallet wants to redeem fees but can’t submit all referrals directly. Anyone watching would see the same tags in both the Referral Tree and the redemption transaction.

Instead, the wallet computes nullifiers without revealing any $r_i$:

$n_i=OPRF(r_i,sk_{oprf})$

Where:

• $r_i$ is the wallet’s referral tag
• $sk_{oprf}$ is a secret key collectively held by OPRF nodes via threshold MPC
• $n_i$ is the resulting nullifier: unique, deterministic, and unlinkable to $r_i$

The OPRF network applies its secret key without learning the input (oblivious) and without any single node holding the full key (threshold). The wallet gets a nullifier $n_i$ and a cryptographic proof $\pi_n$ that the computation was correct.

5. The Redemption Proof

The wallet constructs a zero-knowledge proof demonstrating:

1. “I possess valid nullifiers generated by the OPRF network on my referral tags”
2. “These tags exists in the Referral Tree with fee value $b$”
3. “I know the secret keys and nonces such that $r=H(sk,x)$”
4. “My payout percentage is $p$” (from the Fee Tree, if differentiated pricing exists - optional)

6. The Payout

The smart contract verifies:

• Is the proof valid?
• Have these nullifiers been used before?
• If both pass: send a (private) payment to the wallet, mark nullifiers as spent.

The result: The wallet gets compensated for provable volume. The AMM can audit that payouts match committed fees. But no one can link redemption to specific transactions or users.

For more about private/confidential payments, take a look at Merces, our confidential payments demo here.

The Optional Fee Tree: Differentiated Pricing

In competitive markets, AMMs might offer different rates to different wallets based on volume or exclusivity.

The Fee Tree is a second Merkle tree where each leaf contains:

• $PK_i$: Public key corresponding to a wallet’s secret key
• $p_i$: Revenue-share percentage for that wallet

When redeeming, the wallet includes a Merkle proof showing its public key is in the Fee Tree with percentage $p$. The contract calculates:

$P=B \cdot p$

One protocol might receive 0.05%. Another 0.03%. Percentages stay private until redemption. Competitive pricing intelligence stays hidden.

Where This Matters Now

Currently, wallets either take hidden markups, route based on opaque off-chain deals, or don’t monetize transaction flow at all. Privacy-preserving builder codes enables verifiable attribution where the user sees transparent pricing, the AMM gets verifiable attribution, and the wallet gets fair compensation.

Ready to Integrate?

The TACEO:OPRF service is live. The cryptography is deployed. Privacy-preserving builder codes are one of the many uses of the TACEO:OPRF service for privacy in payments and identity.

If you’re building a wallet, AMM, or any protocol handling transaction flow, this construction provides verifiable attribution without surveillance.

Reach out: [email protected]

Follow TACEO on X for updates.

Further Reading

• Introducing TACEO:OPRF
• TACEO:OPRF Docs