[Idea] Posted Phonons

@Senor and I are excited to announce a potential new feature that we have dubbed “Posted Phonons”. We hope to get community feedback and involvement with the end goal being that posted phonons become part of the Phonon Protocol.

In short, a phonon is a private key that is guaranteed to be known by a single phonon card and no other entity. We will refer to this as the “phonon guarantee”. Currently, when transfering a phonon, both the sender and recipient must have their cards actively paired. This pairing process ensures both cards are following the protocol’s rules, thus maintaining the phonon guarantee.

This pairing process works extremely well in some situations but not so well in many others. For example, imagine your friend messages you saying that they have purchased tickets to a gig you wanted to see. You wish to reimburse them immediately using the Phonon protocol, but doing so would require you both to coordinate opening your Phonon wallet apps, unlocking your cards, and waiting for the transaction to complete. As a result, your friend instead tells you they are too busy to sync and to just Venmo them.

Another scenario where active pairing is an inconvenience is high traffic online retailers. For each customer paying with the Phonon protocol, the retailer would need to maintain an active pairing connection and potentially need a phonon card for each connection. Even if the retailer wanted to go down this route, the development work involved would be substantial and require knowledge outside your typical web developer’s skill set.

Posted Phonons

The changes we propose under posted phonons will drastically improve the usability of the Phonon protocol in the above scenarios, and many others, while maintaining the phonon guarantee.

We introduce the concept of a “posted phonon”, which is a phonon that exists outside of any phonon card. A posted phonon consists primarily of a phonon private key encrypted with the intended recipient’s card’s public key, a signature proving the posted phonon comes from a valid phonon card, and a nonce. If a posted phonon comes from a valid card and the private key can only be decrypted once by a single phonon card then the phonon guarantee is maintained.

To create a posted phonon the sender’s card requires the recipient’s card’s public key and nonce (more below on how these could be requested if a card is offline). Once created, the original phonon is removed from the sender’s card, and the sender receives a posted phonon which can then be sent to the recipient over any medium (HTTP, email, smoke signals). A recipient can consume any received posted phonons at any time but posted phonons should be consumed in order of ascending nonce (consecutive order is not required). A phonon card will reject any posted phonons containing a nonce less than its current internal nonce.

With posted phonons in place, the “reimbursing a friend for tickets” scenario looks a little different. Instead of having to coordinate being online to pair, you ask your friend for their card’s public key and a nonce. Once you receive these details you are able to generate a posted phonon and send it to them using whatever medium suits. Your friend can then consume the posted phonon onto their phonon card whenever it is convenient for them.

Although this flow reduces the need for you and your friend to coordinate being online at the same time, it does introduce friction in other areas. Your friend, the receiver, has to send you their public key and a suitable nonce. To provide a suitable nonce they must keep track of nonces they have previously given out. Additionally, the receiver must ensure that they consume posted phonons in the correct order. Imagine if your friend had previously provided their mother with a nonce lower than yours but had not yet received a posted phonon from her. In this scenario, if they were to receive your posted phonon before their mother’s, your friend can not consume your phonon until they either receive and consume their mothers, or confirm that their mother isn’t going to send a posted phonon with that lower nonce. If their mother’s posted phonon is received after yours is consumed the funds will be lost to both your friend and their mother forever.

Phonon Inbox

To overcome these significant usability issues we have designed a service that we have dubbed a “phonon inbox”. A phonon inbox, sitting outside the of Phonon Protocol, is a service that manages the issuance, storage and consumption of posted phonons. To explain a phonon inbox we will again use the well-explored “reimbursing a friend for tickets” scenario.

Your friend, the recipient, at a previous point in time has signed up for a phonon inbox. When they signed up they provided the inbox with their desired username and their phonon card’s public key and current nonce. When you go to reimburse your friend, you enter their username into your phonon app which makes a request to your friend’s phonon inbox asking for their card’s public key and a nonce. Once these details are received your app immediately creates a posted phonon and sends it to your friend’s phonon inbox. Next time your friend opens their phonon app their card automatically consumes any ready posted phonons. To overcome the uncertainty around if it is safe to consume a received posted phonon when a posted phonon has not been received for a lower nonce, each nonce should be issued with an expiry timestamp. This timestamp gives the sender an explicit cutoff time in which they must send the posted phonon or it may be no longer consumable due the recipient possibly already consuming a posted phonon with a higher nonce.

Phonon inboxes can be self hosted or accessed through a service provider and therefore a discovery system is needed. One idea we have come up with is a “phonon inbox address”, such as hinchy$phonon.dao or personal$hinchy.com, which leverage the DNS system. Another complementary solution is for users to add their phonon inbox url to their ENS records.


Next Steps

  1. Get community consensus that this is a feature worth committing DAO resources towards
  2. Have the Core Devs confirm the feature is viable
  3. Complete the mock card implementation
  4. Have the Core Devs sign off on the mock card implementation
  5. Have the Core Devs implement the feature
  6. Phonon DAO develops an inbox system for public use


  • @deviator for looking over and giving feedback on our initial idea
  • @rake for coming up with the name “Posted Phonons”

This is great! Love the innovation.

1 Like

nice - seems like a really cool idea

1 Like

Solving offline usability is a pretty important goal so am very supportive of further investigation so would love to see Clamato’s suggestion of a call at an Aus/US friendly time where Dan/Nate/other members of the community can stress-test it.

I do worry slightly about the user experience of an expiry timestamp at scale but am struggling to think of a better solution and think there is value to having this out there to stimulate other ideas.

1 Like

Hey @Dcc, glad you think the idea is worth exploring.

The nonce expiry timestamp is definitely the weakest part of the proposed solution. Originally the idea was for the sender’s card to generate a unique nonce when generating the posted phonon. This has two advantages. The sender doesn’t need to request a nonce from the recipient, and second, the recipient can consume the posted phonons in any order. @deviator pointed out that this solution is not viable because of card memory limitations and recipient’s card being required to store these unique nonces.

Although not ideal,I don’t believe the proposed solutions nonce flow is a deal breaker. The sender’s app should request the nonce and send the phonon in quick succession so even at mass scale the receiver’s inbox should be receiving posted phonons roughly in order of nonce issuance.

Let me know if you have any thoughts on this. I’ll have a chat with @clamato about organizing a time for a community call.

1 Like

Great proposal hinchy and señor. This situation would most likely have come up, so props on your forward thinking for the solution.

In a way, is this a bit like picking up tickets at will call?

1 Like

@Rush I love an example like “will call” because everyone understands how that works today.

I own season tickets. I can’t attend tonight’s game. I tell the kiosk at the ballpark only you, Rush, are allowed to pick them up. And in this example, it’s up to the kiosk to check your ID, and make sure those tickets aren’t picked up by someone else!

Posted Phonons achieve exactly the same outcome: Rush gets my tickets. But with a few nuances:

  1. The kiosk functions less like a terminal/ticket window at a ballpark and more like email. Once you have the time to log onto the internet, you can grab your tickets. They are sitting there in your inbox. I sent them to you! (Note: In this example, the tickets are a gift. You probably wouldn’t even need the added service (which can be available to you) of having the tickets be verified as real.

  2. Unlike the kiosk, where an identity revealing verification step is required (check license ID), posted phonons are encrypted to recipient address. No identity is revealed. You either have the intended card, or not.

  3. Because it’s encrypted, even if it were stolen (I look exactly like my brother - better believe I can get his tickets at will call!) impossible to use. Can’t access the contents of the Posted Phonon.

@hinchy i miss anything?


Nope, I think that is everything.

One thing that I didn’t make clear in my original post but you brought up in point #3 is the fact that posted phonons do not need to be kept private. Because a posted phonon can only be consumed by the intended recipient there is no issue with making them public. There may be some interesting use cases for this such as providing proof a payment was made.

1 Like