Broadcasting notes in token contracts

Thanks as always for your replies, Mike!

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.

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

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.

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 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”.

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.

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.

Sounds good, will tackle this during the week!

48 Likes