# Broadcasting notes in token contracts

**URL:** <https://forum.aztec.network/t/broadcasting-notes-in-token-contracts/2658>\
**Category:** Aztec\
**Created:** [December 18, 2023, 6:30pm UTC](https://forum.aztec.network/t/broadcasting-notes-in-token-contracts/2658 "2023-12-18T18:30:11Z")\
**Posts on this page:** 1\
**Showing post:** 3

<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:** [December 19, 2023, 1:06pm UTC](https://forum.aztec.network/t/broadcasting-notes-in-token-contracts/2658/3 "2023-12-19T13:06:50Z")

</div>

Thanks as always for your replies, Mike!

> [@Mike](#):
>
> Do we need to make opinionated decisions here, or can we just let app/wallet devs decide? Are you seeking to create an opinionated token standard?

I’m trying to identify what a vanilla token implementation would look like, to test if the decisions we’ve made on keys make sense. So yeah, an opinionated token standard would be the result of this exercise.

> [@Mike](#):
>
> I think there might be a need, depending on how the app might wish to build in auditability functionality. Proving who you sent funds to feels like a useful primitive, in some cases.

> [@Mike](#):
>
> I can envisage a token contract implementation which wishes to enforce correct encryption?

Agree, I noted this as I was finishing the post, hence the section on “compliance”.

> [@Mike](#):
>
> We can call their account contract though - could that be a useful way to get this preference?

Good point. If we’re not constraining, we can safely call an unconstrained function to get the result, and can just ignore it if it fails.

> [@Mike](#):
>
> I haven’t quite followed this paragraph, sorry.

Sorry, it ended up quite confusing. My point is that the outgoing key is meant to encrypt “outgoing” data, so we use the outgoing _secret_ key for encryption. However, there are situations where a 3rd party sends outgoing data on behalf of the user, such as in a `transferFrom`. And since we cannot give the 3rd party the outgoing secret key (because secrets need to stay secret, as you say), the 3rd party would have to encrypt this data with the user _incoming_ public key, or we’d have to design for an outgoing _public_ key.

Nullifiers are a different story: we know from the [escrow use case](https://forum.aztec.network/t/how-to-handle-private-escrows-between-two-parties/2440/2) that, in order to allow a 3rd party to spend a user’s notes, those notes need to be nullified with a random secret rather than requiring the owner’s nullifier secret key. So that’s “solved”.

> [@Mike](#):
>
> - The app might have a strong preference to generate an outgoing trail and to backup change notes. Imo, either: the app should have the ability to detect that an account contract has denied an encryption request and then the app might choose to revert; or the user’s account contract shouldn’t be able to refuse such a call from an app.
> - Doesn’t this depend on the requirements of the token contract?
> - Doesn’t this depend on the requirements of the token contract?

Agree, in all these scenarios the app (token in this case) may have a preference one way or another. Maybe the problem here is that we’re talking about a very general token contract, so requirements are too flexible. Let’s assume we’re working with a utility token, that has no auditability or compliance requirements, which I think would be the most “vanilla” scenario.

> [@Mike](#):
>
> 1. Perhaps we need to more-exactly define “outgoing” data in this context. I’d been understanding it to mean “data that I (a user) have created, which is primarily intended for someone else’s future consumption”. With that definition, I suppose I view the scenario of a 3rd party spending Alice’s notes as “incoming data”, from Alice’s perspective.

Excellent, I agree, and that makes things easier. The downside of this is that “your tokens you’ve sent” and “your tokens someone else has sent on your behalf” are encrypted using different keys, but that’s not too bad.

> [@Mike](#):
>
> Separately, it would be nice if we could distill all our imagined token scenarios into a very minimal comparison, to help us to see how to design a single token contract standard which can enable all scenarios without too much ugly conditional logic:

Sounds good, will tackle this during the week!

---

_[View the full topic](https://forum.aztec.network/t/broadcasting-notes-in-token-contracts/2658)._