Merkle trees and NFTs to increase privacy

[criadoperez]

In regards to the requirements of the industry posted here and here I want to start a discussion of using Merkle trees to solve the privacy issues.

Main objectives are to keep the amount of shares of a release a secret and the amount of USDC you received for it also a secret.

This is not a full solution yet, but a starting point to see if its the right solution to the problem.

Concept Overview

1. Royalty Tokens as NFTs: Each NFT represents a unique holder's entitlement to royalties.
2. NFT Collections for Each Release: An NFT collection will be created for each release, distributing the shares of that release among the holders of the collection. The use of NFTs ensures that the exact percentage owned by each holder remains private.
3. Transfer and Splitting of NFTs:
   • Full transfer: If a holder wants to give their entire share to someone else, they can simply transfer the NFT.
   • Partial transfer: If a holder wants to transfer part of their share, the original NFT is burned, and two new NFTs are minted and distributed to the respective owners.
4. Off-Chain Calculation: Calculate the royalty amounts off-chain and commit to these amounts using a Merkle Tree.
5. On-Chain Verification and Distribution: Use a smart contract to verify proofs and distribute USDC payments based on the NFT holdings.

Steps for Implementation

1. Royalty Tokens as NFTs

   • Minting NFTs: The Payment Provider mints a unique NFT for each holder, representing their share of the royalties. These NFTs are non-fungible and contain metadata that includes the holder's identifier but not the share amount.
   • NFT Collections for Each Release: For every new release, a separate NFT collection is created. The shares for that release are distributed among the holders of the NFTs in that collection.

2. Off-Chain Calculation and Commitment

   • Calculate Royalties: Payment provider calculates the royalty amount for each NFT holder off-chain based on the total royalties to be distributed and the share each NFT represents.

   • Create a Merkle Tree:

     • Each leaf node in the Merkle Tree represents a payment for an NFT holder. The data in each leaf can include the holder's address, the NFT ID, and the payout amount.
     • Hash each leaf node.
     • Construct the Merkle Tree from the hashed leaf nodes.
     • Compute the Merkle root.

   • Optionally, for enhanced privacy, the payout amounts can be encrypted before creating the Merkle Tree.

3. On-Chain Verification and Distribution

• Publish Merkle Root: Publish the Merkle root on-chain using a smart contract. This serves as a commitment to the payouts.
• Generate Proofs: For each NFT holder, generate a Merkle proof that can be used to verify their inclusion in the tree. This proof will be used when claiming the payment.
• Smart Contract for Verification and Distribution:
• Deploy a smart contract that holds the USDC for distribution.
• The contract should verify the Merkle proof provided by the NFT holder and distribute the corresponding USDC payment if the proof is valid.

4. Transfer and Splitting of NFTs

• Full Transfer: If a holder wants to give their entire share to someone else, they can transfer the NFT directly to the recipient. The recipient now owns the full share of the original holder.
• Partial Transfer:
  • The original NFT is burned.
  • Two new NFTs are minted within the same collection, representing the split shares.
  • The new NFTs are distributed to the respective new holders.
  • The Merkle Tree is regenerated to reflect the updated ownership percentages and a new Merkle root is published on-chain.

Steps for Deployment and Operation

1. Deployment:

   • Deploy the MerkleRoyaltyDistributor contract with the Merkle root, USDC token address, and Royalty Token (NFT) address.
   • Transfer the total USDC amount to the contract for distribution.

2. Claiming Process:

   • NFT holders call the claim function with their token ID, payout amount, and Merkle proof.
   • The contract verifies the proof and, if valid, transfers the USDC amount to the NFT holder's address.

3. Handling Transfers:

   • For full transfers, NFT holders use standard NFT transfer mechanisms.
   • For partial transfers, implement a mechanism to burn the original NFT, mint two new NFTs, and update the Merkle Tree.

Some Considerations

• Proofs: Still unclear how to distribute the proofs.
• Gas Costs: The Merkle Tree depth and proof size can increase gas costs associated with on-chain verification.
• Optional Encryption: For additional privacy, we can consider encrypting the payout amounts before creating the Merkle Tree, though this is optional.

[kowalski]

@criadoperez there are many things which I like about this model. However I'd like to point out some deficiencies that may make think a bit more about this structure.

1. In this model, each payout creates a commitment of a merkle root of a payment. At this point everything is nice and private. However at this step I'm missing a mechanism that would enforce that the payment provider has correctly respected the amount of shares when calculating payout amounts for each shareholder. If I have 3 equal shareholders I expect them to get same usdc amounts. If amounts are private and the calculation is purely off-chain than we all must rely on honesty of payment providers. Such assumption may or may not be okay. I'd prefer to be able to claim that our protocol enforces that the payments are distributed fairly.
2. I can see a deficiency in privacy when user is claiming their payout. I understand that this will mean calling a function like claim(bytes32 paymentBatchMerkleRoot, bytes merkleProof). By calling a function like this we are revealing the leaf of the merkle tree. Eventually it's fair to assume that all the shareholders will claim all the leafs. Because if they dont' some money will remain "unreceived". So over time entire merkle tree get revealed (in calldata of claim function calls) so all the amount become known.
3. The merkleProof is necessary to claim. It will have to be provided by the payment provider. By withholding this argument, the payments providers gain the ability to censor some users from claiming. In this sense the "payout" is not final. After the payout the payment provider can still "undo it" in a sense.

[criadoperez]

Thanks @kowalski for your input. Let me try to address your points.

1. Verification of Fair Distribution:

You correctly noted the need for a mechanism to ensure that the payment provider fairly calculates and distributes the payout amounts according to the shareholders' entitlements. To address this:

• Merkle Tree Proof and Share Verification: The Merkle tree should include information that remains constant regardless of NFT ownership transfers. Specifically, each leaf node in the Merkle tree will contain:
  - NFT ID: The unique identifier for the NFT.
  - Payout Amount: The amount of USDC that the NFT holder is entitled to receive.
  - Percentage Share: The percentage share of the total payout that the NFT represents.
  - Total Amount: The total amount of USDC to be distributed.

By including the percentage share and total amount, holders can verify that their payout corresponds to their share of the total amount. This allows holders to ensure they received the correct amount without revealing individual payout amounts directly. This method serves as the best solution as it maintains privacy while ensuring fairness and minimizing the need for trust in the payment provider.

• Second Option - Zero-Knowledge Proofs (ZKPs): Integrating Zero-Knowledge Proofs can provide cryptographic assurance that the payouts were calculated correctly according to each holder's share without revealing the actual amounts. This maintains privacy while ensuring fairness, but it introduces additional complexity.

2. Privacy Concerns During Claiming:

You raised a valid point regarding the potential privacy leakage when shareholders claim their payouts. Each claim could indeed reveal the corresponding leaf of the Merkle tree. To mitigate this we coudld use:

• Batch Claims: Instead of individual claims, the contract could support batch claims where multiple payouts are claimed in a single transaction. This would reduce the frequency of privacy exposure.
• Shielded Transactions: A line to investigate...

3. Proof Distribution and Censorship Resistance:

The concern about the payment provider potentially withholding Merkle proofs is relevant. However, considering that the payment provider can ultimately choose to pay or not pay, the risk of censorship might be less critical. We can also look into:

• Decentralized Proof Distribution: To prevent the payment provider from withholding proofs while ensuring privacy, a decentralized system for distributing proofs can be implemented. This system could use IPFS or similar decentralized file storage solutions to store individual proofs securely. Each shareholder can then access their proof using a unique identifier or key provided off-chain. This ensures that only the rightful owner can access their proof without revealing all branches of the Merkle tree.

Optional Encryption for Enhanced Privacy:

We also mentioned the possibility of encrypting payout amounts. While this adds complexity, it could significantly enhance privacy. If we pursue this route, careful consideration must be given to key management and the potential overhead on both the off-chain and on-chain components.