[PA RFC-0008] PERISH issue mode



:thumbsup: Time sensitive tokens sound like a useful idea and I like the idea of “transferable but only so many times”. Do you have a use case already in mind? Would be nice to develop it and then have someone use it to see how it works in practice.

Grocery store can use PERISH issue mode with flag 288.

Is the flag mentioned here the value from the new “rules” dictionary that should have “number_of_blocks” present? I’m not sure if flag is the right way to describe an integer count.

If no flags are provided in the rules field, cards expire after 0 blocks which makes them all invalid by default.

Is it possible to keep such a deck from being spawned? I’m not sure why we would want to create cards that are expired before we even hand them out.

Depends on introducing new deck-defining information in the deck spawn protobuf, the “rules” field.

Does protofbuf let us specify any fields we want in the rules dictionary or do they have to be determined beforehand? It might be useful for decks that use a CUSTOM issue mode to store data in rules as well. (Although, to be honest, I have no concrete example of anyone using CUSTOM mode :stuck_out_tongue: ).

Maximum number of “hops” (transfers) the card can do, counted from the issuer. For example, it can be transfered max 3 times and then it becomes invalid.

Does giving the card back to the person that sent it to you count as a hop? If you’re the last person to receive the final hop, what happens if you try to send it? Would everyone treat it as an invalid card transfer and it would remain in your possession forever?

Also, would it make sense to talk about a TRANSFERABLE issue mode? Might be an interesting deck property to give cards.

deck_spawn = > {
“version” : 1,

If we added this new MODE and “rules” protobuf would we also want to start using a new version number? 2? 1.1? :slight_smile:


Does this replace ‘subscription’?


No, I did not plan it like that. They can still co-exist.
With PERISH I want to play with this new “rule” field in the deck-spawn protobuf. I will leave this as a draft until “rule” idea is refined.

Beside this simple rules this new field can be used to carry extra flags for the any issue mode, like issue modes for issue modes or bytecode for smart contracts.


This is how PA works, it allows you to do silly things at your end and reserves a right to ignore you. For example you can issue a deck with NONE&MULTI issue mode.

That requires explicit definition in the RFC indeed.

The proposed changes keep backward compatibility.