# How to handle private escrows between two parties..?

**URL:** <https://forum.aztec.network/t/how-to-handle-private-escrows-between-two-parties/2440>\
**Category:** Aztec\
**Tags:** question\
**Created:** [October 20, 2023, 6:14pm UTC](https://forum.aztec.network/t/how-to-handle-private-escrows-between-two-parties/2440 "2023-10-20T18:14:32Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![spalladino](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.aztec.network/spalladino/32/32_2.png) [@spalladino](https://forum.aztec.network/u/spalladino)\
**Post date:** [October 24, 2023, 8:18pm UTC](https://forum.aztec.network/t/how-to-handle-private-escrows-between-two-parties/2440/2 "2023-10-24T20:18:16Z")

</div>

> [@spalladino](#):
>
> ### Reencrypt the same note under multiple pubkeys
> 
> An alternative that does not require overloading the `pxe` with additional keys is to simply re-encrypt the same note under the pubkey of each recipient. In other words, having a single commitment on the note hash tree, but emit it as an encrypted log multiple times. The tradeoff here is more calldata used in the tx.
> 
> An issue with this approach is nullifying the note. Since multiple users have “access” to the note, they all need to be able to nullify it. The shared secret, derived from the recipients pubkeys, could be used here. Or a random nullifier key could be just embedded as part of the encrypted note, which becomes visible to all those who can decrypt it.
> 
> This implies that we cannot use the same note implementation for multi-encryption that we use for individual transfers, since we cannot just rely on `get_secret(note.owner)` for nullifying. But it’s a fairly small change, and it also plays well with [storing nullifier secrets or identifiers as part of the note itself](http://forum.aztec.network/t/rotating-encryption-and-nullifier-keys/2394#nullifiers-3) if we allow for rotating nullifier keys.

To elaborate on this approach, we’ll need to modify the token contract and introduce a new note type. This new note, let’s call it `SharedValueNote` for lack of a better name (please, dear reader, think of a better name!), should be similar to the ValueNote except for:

- `compute_nullifier` should not use the `owner`’s nullifier but a random secret generated by the note creator and embedded into the note, so it’s accessible by all viewers.
- `broadcast` should not use the `owner` pubkey, but receive a _list_ of the addresses for which to emit the encrypted log. Note that, given that this diverges from the default `NoteInterface`, we may need to make the note’s `broadcast` a noop and handle it manually.

Note that we still want to keep the `owner` field since that’s the address that’s authorised for actually spending this note in the contract logic.

The token contract then needs logic for creating and consuming these notes. An easy solution is to have a dedicated method `create_shared_note` that consumes existing regular `ValueNote`s of equivalent value, and then a `consume_shared_note` which does the opposite, similar to `shield/unshield` operations. An open question is how the `balance_of` method would work, since it’d have to add balance across both flavors of notes.

Alternatively, it’d be interesting to see if we can merge both the `SharedValueNote` and the `ValueNote` into a single note type somehow, since the only practical difference is whether the nullifier is set as a random value by the sender or generated from the recipient’s secret. This would probably require having a special flavor of the `transfer` function that accepts a list of “viewers” for the note.

---

_[View the full topic](https://forum.aztec.network/t/how-to-handle-private-escrows-between-two-parties/2440)._