Shielded Kudos Pt. 4: DL examples

Applications
1

In this post I’ll provide two examples of DL logics. They are not meant to describe the most common use cases, these are just two examples that are meant to highlight the programmability features of the kudos application.

Example one: named token

Function Condition
Issue/Burn Can only be done by a certain entity
Transfer/Swap Allowed only if 2% of the transferred value is sent to the issuer, i.e., if the sender and receiver are not issuer, then there must be another resource with quantity 0.02q that is sent by the same owner and received by the receiver

Example two: Loyalty Points

Function Condition
Issue Can only be issued by a certain entity. Each token has an associated expiration date
Burn No extra constraints
Burn for reward The owner can issue a burn intent claiming reward from the issuer for burning their loyalty points. Only for non-expired tokens.
Transfer/Swap No extra constraints

A note on burn-for-reward mechanics

While working on this example, I came up with an idea of burn/issue-for-reward mechanics. I described my thoughts in more details here. This is not a crucial question for this example, so I don’t want to think too much on how to implement it the best way. A simple option to implement it on the DL side is to always verify that there is some extra logic (intent) associated with the burn. For “simple” burns, the intent is always satisfied.

2

Could you pls clarify the constraints, witnesses and instances of the DL? And what’s in labels and values?

If the KL and DL description is complete, it would be helpful to see concrete transaction examples. For instance, for a named token issue transaction/action, how many resources are needed (including padding and dummy resources) in practice, and how they are constrained, and correlated.

1 Like
3

Example one: named token

Kudo structure

  • label: includes the issuer’s pk

Consumed

Ephemeral:

  • verify a signature issued by the owner signing the list of cms + nfs of the action: Signature.Verify(issuer_pk, cms + nfs, Sig) = True

Created

Persistent:

  • there is a created resource r of the same denomination with r.owner = r.issuer, r.quantity = 0.02 * self.quantity

Ephemeral:

  • verify a signature issued by the owner signing the list of cms + nfs of the action: Signature.Verify(issuer_pk, cms + nfs, Sig) = True

  • Instance: commitments, nullifiers (nothing extra)

  • Witness: resource objects (includes issuer’s pk), signatures