Shielded Kudos: Issue, Burn, Transfer (with Conditional Receive), Swap

[vveiln]

Kudos is an application that defines kudos denomination interface and describes how different denominations work. Kudos denominations might have some meaning assigned to them (e.g., money, trust, etc), but we will ignore the meanings here.

Note about the existing kudos application

If you are reading this and wondering about the existing kudos application: I’m aware it exists. The goals of this post are:

• develop a clear abstraction for the kudos application that doesn’t make decisions about individual denomination policies
• produce a written description of the developed abstraction (with diagrams) that can be referenced by the implementation
• ensure that the proposed design is compatible with the privacy goals ^[1]

Logic layers

The kudos application framework can be split into two parts:

1. Kudos application logic (KL) defines what a valid denomination is and specifies how to issue and govern denominations.
2. Denomination logic (DL) is a denomination-specific authorisation logic.

A kudos transaction is valid if it satisfies the kudos application logic and the denomination logic ^[2].

Desired denomination behaviour

We want any kudos denomination to allow:

1. issuing and burning kudos
2. doubly permissioned kudos transfer
3. kudos-to-anything swap

At the same time, we want to abstract away the authorisation logic of a particular denomination.

The high level idea

• A kudos resource of any denomination has KL in the logic field
• The denomination label includes the issuer’s pubkey and the verifying key of the DL
• KL requires a resource with the specified in the label DL be present in the transaction to authorise the action

Involved resource kinds:

• kudos denomination resource resource (kudos application logic)
• denomination authorisation resource (denomination authorisation logic)
• receive authorisation resource (receive authorisation logic)
• intent carrying resource (intent logic)

Specific transaction functions

Issue and burn kudos

We start with issuing and burning kudos since they are pretty similar to each other and are the simplest action possible.

• On the diagram, the grey resources correspond to kudos resources of denomination #n and the green resources represent the denomination #n authorisation logic.
• KL requires a resource with a DL from the label to be present in the same action. The DL resource verifies the issuance conditions specific to that denomination.
• The same idea works for burning, except that now we consume a persistent resource instead of creating a persistent resource.
• The denomination resource can be ephemeral and have a zero value, we only need to trigger the logic verification.

Transferring kudos with conditional receive

To allow specifying receive policies, we need to require a receiver-specific logic (RL) to be verified. This implies we need a resource that carries that RL. RL cannot be a part of DL since it isn’t associated with the denomination, it is associated with the receiver. RL presence requirement must be a part of the kudos logic (i.e., required for all denominations), otherwise the malicious sender can always create a denomination that doesn’t require it and send it to the desired receiver.

• As in the issue/burn case, we need to trigger the corresponding DL
• To bind the receive authorisation logic to the action, KL requires that there is a resource in the same action that is associated with the specified receiver’s pubkey
• To make sure the authorisation logic is indeed created by the receiver, the receive authorisation resource must contain a signature over the authorisation logic. This signature must be verified by KL
• As for DL, RL only triggers the logic and therefore can be ephemeral and zero value

Kudos-to-anything swap

• The binding mechanism here is similar to the RL binding. The intent resource is identified by the owner of the consumed kudo and the logic (IL) must be signed by the owner and verified in the KL
• The difference compared to the previous case here is that we need to explicitly specify what the unbalanced transaction looks like (left rectangle), and how to balance it (right rectangle)
• We don’t need to explicitly specify how to swap kudos for kudos. If the IL requires a kudo, it produces a kudo-to-kudo swap. Otherwise it can be a kudo-to-anything swap, which allows for more generality

Transaction functions and constraints for KL

TF	Description
Issue	A peristent resource is created, balanced by an ephemeral resource. There must be another resource with a logic specified in the kudo label
Burn	A peristent resource is consumed, balanced by an ephemeral resource. There must be another resource with a logic specified in the kudo label
Transfer	A peristent resource is consumed, balanced by an identical persistent resource with a different owner. There must be a resource with a logic specified in the kudo label. There must be a resource with a logic signed by the owner of the created persistent resource.
Swap	A peristent resource is consumed. There must be a resource with a logic specified in the kudo label. There must be a resource with a logic signed by the owner of the created persistent resource.

	Ephemerality	TF	Constraints
Create	Ephemeral	(Only burn)	There must be (an identical) consumed persistent resource
	Persistent	Transfer	There must be (an otherwise identical) consumed persistent resource with a different owner. There must be another resource with a logic signed by self owner
		Issue	There must be (an identical) consumed ephemeral resource
Consume	Ephemeral	(Only issue)	There must be (an identical) created persistent resource. There must be a resource with a logic specified in the self label
	Persistent	Burn	There must be (an identical) created ephemeral resource. There must be a resource with a logic specified in the self label
		Transfer	There must be (an identical) created persistent resource.There must be a resource with a logic specified in the self label
		Swap	There must be a resource with a logic specified in the self label. There must be a resource with a logic signed by self owner

Resources

• Scale-free kudos: brainstorming thread
• https://research.anoma.net/t/basic-e2e-shielded-kudos-app/1237
• https://research.anoma.net/t/cryptography-and-apps-q2-priorities/1266
• anoma-apps/Kudos at main · anoma/anoma-apps · GitHub

---

1. which, combined with a shielded RM, allows to have fully shielded e2e kudos ↩︎

2. and all the other required logics ↩︎

[Michael]

Thank you for the write-up. Two remarks

• develop a clear abstraction for the kudos application that doesn’t make decisions about individual denomination policies

1. Are resources the right layer of abstraction? In this example and by factoring out authorization and issuance, we tripled the amount of resources that need to be processed by the RM. For other apps, there might be even more properties that we would need to factor out.
   IMO, this increases complexity and carries overhead processing costs for the RM (unused fields, more logic, external calls / reads into other resources) but also for the human brain (even if the denomination logic will be reused / standardized).
   I don’t want to optimize prematurely, but this seems quite costly, having the resource plasma but also the existing development complexity in mind. Maybe it is worth to research if composable resource logics could make sense.

• produce a written description of the developed abstraction (with diagrams) that can be referenced by the implementation

2. While the diagrams are helpful, it would be nice to see the action context the respective resources are in. This is important for transactions in which multiple parties participate (here transfer with receive and swap). In the swap case, for example, you have to enforce the presence of intent-carrying resources in the solver action for it to be able to ensure the constraints over the created resources. This is important to consider for the implementation.
   
   FYI, I am visualizing this with tables (which show the consumption and creation side as columns and different actions as blocks of rows) in our docs.

[kike]

Thanks for writing up the proposal!

@vveiln

We want any kudos denomination to allow:

1. issuing and burning kudos
2. doubly permissioned kudos transfer
3. kudos-to-anything swap

At the same time, we want to abstract away the authorisation logic of a particular denomination.

Yes, I think separating creation/consumption denomination logic from receiver authorization makes sense. Perhaps it is a good idea to go ‘full’ with the abstraction:

• Signatures is one way to enforce receive policies.
• Another way is via a PRF family. The notion of ‘user identities’ is not a keypair of signing/verification keys (sk,vk), but instead a keypair of secret index/hiding commitmment to the index (k,c) for the PRF family. The owner of the consumed resource sets \sigma = PRF(k,receive\_policy), and the kudos logic (KL) verifies a zk-proof of correct generation of \sigma using c. This has the advtantage of making \sigma look random.
• A third option is [insert here].

Abstractly, the kudos logic runs some verification logic using two inputs specified in the resource value: the owner’s address (the signature verification key or the commitment to the PRF index), and the ‘proof of ownership’ (the signature or the zk-proof). The proof of ownership may be generated by secret data not explicitely in the resource (the signing key or the secret PRF index).

@vveiln

The DL resource verifies the issuance conditions specific to that denomination.

Here, do the issuance conditions account for both, minting and e.g. change?

• Minting: create but consume nothing. For example, create “5 bananas” (1 resource of kind Banana den#5), and consume nothing. (Similar for burning: consume but create nothing.)
• Change: create subject to consumption. For example,consume “4 bananas” (1 resource of kindBanana den#4), consume “1 banana” (1 resource of kind Banana den#1), and create “5 bananas” (1 resource of kind Banana den#5).

The disadvante of bundling together these two cases in the same logic is that, in the shielded case, when the logic is proved in zero-knowledge, this might become expensive: the circuit will have constraints that are not needed for the case at hand, e.g. minting constraints when doing a change of denominations.

Regarding the “change” case above, how would differentiate from the “kudos-to-anything swap” operation?

But maybe I’m missing something.

@Michael

Are resources the right layer of abstraction?

I think they are, but I agree with your point. Perhaps we can maintain the different types of logic, but not on their own in separate resources. I’m thinking in differentiating between “minted” kudos denomination, and “regular” kudos denomination (different resources). This would also unbundle logic for minting and transfering/swapping that I mentioned above.

@vveiln

ensure that the proposed design is compatible with the privacy goals

It’s still not totally clear in my mind what exactly do we understand by function privacy. But suppose is: “given a transaction, I cannot differentiate whether resources in it are for the kudos app or for the messaging app” This means that the label field somehow must obscure we are dealing with kudos’s resources.

Also, I think it would be useful to have a notion of identity for kudos (which, if I’m understanding correctly, we don’t have it yet in the design.) For example, imagine we want that only a single fixed issuer can mint different denominations of “banana”.

[vveiln]

@Michael

In this example and by factoring out authorization and issuance, we tripled the amount of resources that need to be processed by the RM.

I believe this is fine.

@Michael

IMO, this increases complexity and carries overhead processing costs for the RM (unused fields, more logic, external calls / reads into other resources)

You are right about that, this is the trade-off we accept to have a clear abstraction. In the short term it might feel like a significant cost increase.

The version I propose allows to have the main application logic constant (which I believe is highly desirable) regardless of what authorisation policies the denomination owner picks. It does it at the cost of 1-2 extra resources per transaction function, which I think is a reasonable deal.

@Michael

but also for the human brain (even if the denomination logic will be reused / standardized).

1. If we write a denomination logic that implements all of the authorisation mechanisms used in the existing kudos application, we basically get the same level of complexity for the human brain. It is not more complicated to use such an application (with a predefined DL) from the user perspective than the existing application. The difference comes in when the users request alternative authorisation options.
2. Hopefully, with the development of a higher-level language on top of the resource machine, human brains will not have to think about resources as much.

@Michael

Maybe it is worth to research if composable resource logics could make sense.

What exactly do you mean by composable resource logics?

@Michael

it would be nice to see the action context the respective resources are in.

The bigger rectangles on the diagrams represent actions.

@Michael

In the swap case, for example, you have to enforce the presence of intent-carrying resources in the solver action

The presence of the intent-carrying resource is enforced in the KL: “There must be a resource with a logic signed by the owner of the created persistent resource.”

[vveiln]

@kike

Yes, I think separating creation/consumption denomination logic from receiver authorization makes sense. Perhaps it is a good idea to go ‘full’ with the abstraction

Do you mean abstracting away how receive resource and intent-carrying resources are bound to KL? I think these are the only places we use signatures as verification mechanism.

@kike

do the issuance conditions account for both, minting and e.g. change?

No, it isn’t intended to be this way. Issuance = minting. Change would be generalised transfer, but there is no change in this proposal.

@kike

The disadvante of bundling together these two cases in the same logic is that, in the shielded case, when the logic is proved in zero-knowledge, this might become expensive: the circuit will have constraints that are not needed for the case at hand, e.g. minting constraints when doing a change of denominations.

We have all denomination constraints in the same logic. We can separate them, but it just moves them to the KL + we need a new resource kind for each transaction function. So DL becomes cheap, but KL becomes more expensive + more resource kinds are involved.

@kike

Regarding the “change” case above, how would differentiate from the “kudos-to-anything swap” operation?

Swap requires a presence of an additional resource - intent carrier resource. This resource is authored by the owner of the consumed kudo and it is bound to the “old owner identity”. In the transfer case, we have an additional receive verification logic resource. It is bound to the “new owner identity”. Another thing is that intent carrier resource is non-zero value and keeps the transaction unbalanced. Receive authorisation logic is zero value and doesn’t affect balance, it only triggers the logic.

@kike

Perhaps we can maintain the different types of logic, but not on their own in separate resources. I’m thinking in differentiating between “minted” kudos denomination, and “regular” kudos denomination (different resources).

What is the difference between regular kudos and minted kudos?

@kike

This means that the label field somehow must obscure we are dealing with kudos’s resources.

The label is a part of a resource object, it isn’t a part of the transaction. Nobody sees the label, so the label doesn’t have to obscure it, I believe.

@kike

Also, I think it would be useful to have a notion of identity for kudos (which, if I’m understanding correctly, we don’t have it yet in the design.) For example, imagine we want that only a single fixed issuer can mint different denominations of “banana”.

I think identity question is an important thing for more than just kudos and I believe it is a part of another specs research realm. On my side I imagine identities to be keypairs, so if DL wants to white-/blacklist, it can explicitly specify the public keys and verify that the user owns the corresponding private key. It might be not the most general solution, but it is a simple approximation that allows me to focus on other aspects. I can include this assumption explicitly in the post.

[Michael]

@vveiln

What exactly do you mean by composable resource logics?

Instead of having one resource logic reference per resource, you could imagine having multiple ones per resource that can be composed with logical ANDs.

Instead of

Resource {
  ...
  logicRef = 0x123;
  ...
}

you could have

Resource {
  ...
  logicRefs = 0x123 && 0xabc && ... 
  ...
}

or for the different logic branches:

Resource {
  ...
  logicRefs = {
    initialzation := 0x123;
    finalization := 0x456;
    consumption := 0x789 && 0xabc;
    creation := 0xdef;
  }
  ...
}

Maybe it’s worth exploring, maybe it isn’t.

[Michael]

@vveiln

@Michael

it would be nice to see the action context the respective resources are in.

The bigger rectangles on the diagrams represent actions.

Is this one action?

[vveiln]

@Michael

Instead of having one resource logic reference per resource, you could imagine having multiple ones per resource that can be composed with logical ANDs.

How is it different from a single logic with multiple constraints?

[vveiln]

I think this is the only rectangle in the post that can be more than one action. Specifically it can be up to 4 actions, I think, but the specific amount of actions depends on the specifics of the swap. It can be a single action as well. I decided not to include this information in the initial draft since we already know the mechanics of intent-carrier resources.

[Michael]

@vveiln

@Michael

Instead of having one resource logic reference per resource, you could imagine having multiple ones per resource that can be composed with logical ANDs.

How is it different from a single logic with multiple constraints?

You would have some degree of abstraction.
If you do this also for value and label, you could have property mixins (e.g., Ownable, Initializable) this way without the complexity that comes with multiple resources.

[vveiln]

1. How would you enforce that all logics are proven? Right now the rule is simple: one logic proof per cm/nf. Having no access to the label structure for verification, how can you know that some proof is not omitted?

2. How would you be able to ensure that there is a kudos logic in the set of logics of a presumably kudo resource? The proposed design implies that all kudos have the same logic (which is also good for proof aggregation)

[Michael]

I haven’t thought about those details. Maybe it is indeed too early to think about optimizations and we should just explore on the conceptual side.

[kike]

@vveiln

@kike

Yes, I think separating creation/consumption denomination logic from receiver authorization makes sense. Perhaps it is a good idea to go ‘full’ with the abstraction

Do you mean abstracting away how receive resource and intent-carrying resources are bound to KL? I think these are the only places we use signatures as verification mechanism.

Yes, I wonder why specifically signatures in the abstract proposal. But it is fine to keep signatures as of now. The only reason I favour the PRF approach is that it is faster to prove (e.g. with a Pedersen hash).

@vveiln

What is the difference between regular kudos and minted kudos?

A regular Kudos would be a Kudos that has not been created out of thin air, as a minted Kudos is.

Would a standard change require some DL logic? I’m just thinking in keeping the invariance of the supply, which in the current Juvix app is done via the quantity field, I believe, and as I get it, in your proposal the invariance is done via the DL.

@vveiln

The label is a part of a resource object, it isn’t a part of the transaction. Nobody sees the label, so the label doesn’t have to obscure it, I believe.

Right! Sorry, got it wrong

@vveiln

so if DL wants to white-/blacklist, it can explicitly specify the public keys and verify that the user owns the corresponding private key.

Ok, but how do you enforce that after you create Kudos Yulia's bananas#5 nobody can create Kudos Yulia's bananas#500 – these are two different resources (one resource per denomination) and you control issuance of 5 denominations only, even with whitelists? or are you saying the whitelist is for Kudos Yulia's bananas – i.e an identity. Again, I may be missing something.

Anyways, I think the proposal is well thought and in the right direction!

[xuyang]

Thank you, it’s a nice post.

1. Are you referring to quantity in Resource when mentioning value and value 0 in your post? We used value for balance, but you renamed it to quantity, giving value a new definition.
2. Do we need to constrain the creation and consumption of ephemeral kudo resources for issuing and burning? Otherwise, it’s possible to maliciously use ephemeral kudo resources with non-zero quantity to balance the persistent resource in transferring. Also, if I create a kudo for myself, trigger my receiving DL, and consume an ephemeral kudo, does it mean I can bypass the issuance? Or did I miss any constraints? The issuing and burning constraints may align with corresponding ephemeral resource creation and consumption if it makes sense.
3. Besides the necessary witnesses and the nullifier key, how do you define the ownership here? Denomination authorisation logic defines the consuming rules and receive authorisation logic defines receiving rules? I may need a specific rule for implementation. Alternatively, will @Michael define it somewhere?
4. Is the conditional receiving optional or mandatory? And I’m curious why it requires a signature, to prevent tampering and denial? The address completeness (public key and nullifier commitment) and receiving policies should be verified for msg integrity when fetching from receivers.

I’ve got the layout and basic constraints. Could you add the witnesses and instances of the above logic if convenient? And what do labels and values include overall?

[vveiln]

@xuyang

Are you referring to quantity in Resource when mentioning value and value 0 in your post? We used value for balance, but you renamed it to quantity, giving value a new definition.

Oh, you are absolutely right, it is a mistake! I’ll update the post.

@xuyang

Do we need to constrain the creation and consumption of ephemeral kudo resources for issuing and burning?

Yes, absolutely. Basically we need to explicitly allow the transaction function cases and everything else should be prohibited.

Specifically, as you mentioned, we only allow creation of ephemeral kudos for burning and consumption of ephemeral kudos for issuing. In any other case it is prohibited

@xuyang

how do you define the ownership here?

I think here I assume that ownership is verified via signatures, but it doesn’t have to be. I think it is the simplest way, but it has downsides.

DL verifies not just consumption, it is triggered every time a kudo of the denomination is consumed or created. For the denomination to be owned it has to bind the authorisation rules the some identity. Then it, practically speaking, is owned by this identity.

Kudo ownership I imagine by binding it to a public key, probably in the value field. We do need to ensure the correct validation of it (to make sure nobody can arbitrarily change the owner by changing the value without any constraints triggered). Changing the value should only be allowed for transfer (including swap), and has to be authorised. We probably want the authorisation mechanism to be in DL though to allow for variable mechanisms.

I’ll try to specify it in more details as soon as I can.

@xuyang

Is the conditional receiving optional or mandatory?

It has to be mandatory, but the user can have their receive logic to always return true. The reason for that is that if we allow certain denominations to not require it (i.e., delegate it to DL) as opposed to KL require it, a malicious user can just mint a new denomination and spam the user. Putting it in DL means letting the sender to decide if the receiver can refuse.

@xuyang

And I’m curious why it requires a signature, to prevent tampering and denial?

We need a way to verify that the logic was specified by the receiver and not someone else who just put the receiver’s public key in the receive resource. Otherwise anyone can put the receiver’s identity to some receive resource and set the logic always return true.

@xuyang

I’ve got the layout and basic constraints. Could you add the witnesses and instances of the above logic if convenient? And what do labels and values include overall?

I will try to specify the details asap.

[vveiln]

@kike

Yes, I wonder why specifically signatures in the abstract proposal.

Because this is not the part we are abstracting here. It isn’t supposed to be fully abstract, we are specifically abstracting away the DL logic. I think it might make sense to abstract this mechanism further, but this is a different direction of abstraction.

@kike

The only reason I favour the PRF approach is that it is faster to prove (e.g. with a Pedersen hash).

Interesting, I assumed it would be slower because you mentioned that we need to verify the proofs recursively. Or did I misunderstand what you meant there by verifying a proof in the logic?

@kike

A regular Kudos would be a Kudos that has not been created out of thin air, as a minted Kudos is.

I’m not sure I see what the reason for making it explicit it is since they are automatically unbundled by the kind of resources involved in the transaction. Minted kudos only exist in the issue tf, and issue tf is the only tf that is allowed to include ephemeral consumed kudos. Regular kudos are a part of the transfer or swap tf, and they only include persistent kudos.

@kike

I’m just thinking in keeping the invariance of the supply, which in the current Juvix app is done via the quantity field, I believe, and as I get it, in your proposal the invariance is done via the DL.

I didn’t look into how it is done in the implementation, but I feel like if we have a stateful issuance verification (basically a verification mechanism that is triggered just once) and don’t allow any more issuance, we can rely on allowing only transfers

@kike

Ok, but how do you enforce that after you create Kudos Yulia's bananas#5 nobody can create Kudos Yulia's bananas#500 – these are two different resources (one resource per denomination) and you control issuance of 5 denominations only, even with whitelists? or are you saying the whitelist is for Kudos Yulia's bananas – i.e an identity

I think in this case bananas#5 and bananas#500 would be different denominations and I control them separately even though I own them both. In that sense it is the same as if i had bananas and apples

We can also think towards nested denominations, where yulia’s denomination is the kudo level denomination and then treat yulia’s DL as a KL (that contains whitelists in the logic) that then triggers bananas#5 DL and bananas#500 DL.

[xuyang]

Thank you for replying

@vveiln

The reason for that is that if we allow certain denominations to not require it (i.e., delegate it to DL) as opposed to KL require it, a malicious user can just mint a new denomination and spam the user. Putting it in DL means letting the sender to decide if the receiver can refuse.

I’m not sure I fully understand this.
If the DL verifies both consumption and creation logic, can we merge the receive logic into creation logic in DL? I thought the receive logic is part of creation logic. Basically it’s the same or related to my next question below.

@vveiln

Otherwise anyone can put the receiver’s identity to some receive resource and set the logic always return true.

With the signature, someone can still put the receiver’s identity to resources, just ignore the signature/or tamper the logic and send to the receiver. Resources are created by a sender, the sender can set any public keys and DL/receive logic if he doesn’t want to comply with the receiver in a normal transfer. I’m not sure if we really can prevent sending unexpected resources to a receiver. But the receiver can drop or filter out unexpected resources and logic. It seems I missed some key constraints?

[vveiln]

@xuyang

If the DL verifies both consumption and creation logic, can we merge the receive logic into creation logic in DL?

DL is specific to denomination, receive is specific to a user. Same users might have different receive policies for the same denomination. For example, I accept apple token from anyone and you only accept apple token from me and kike, and the DL logic might require that an apple can only be created if there is another apple-tree resource consumed in addition to the standard apple resource. Does it make sense?

@xuyang

With the signature, someone can still put the receiver’s identity to resources, just ignore the signature/or tamper the logic and send to the receiver. Resources are created by a sender, the sender can set any public keys and DL/receive logic if he doesn’t want to comply with the receiver in a normal transfer.

I write my receive logic and sign it with my private key. Then if someone wants to send me something, they have to set my public key as the new owner of the resource they send to me. The KL logic then expects a receive resource in the same action with the logic signed by me - it will use my public key from the resource sent to me to verify the signature. KL takes the receiver’s public key and uses it to verify the signature over logic, so the logic is bound to the receiver.

That does imply that the sender must know the receiver’s logic to create/consume the receive resource, which is a limitation. But even if they could trigger the logic without seeing it, they would learn something about it by seeing which transfers fail and which don’t.

I’m not sure we can go around revealing the logic to the sender without interacting with the receiver directly and asking them to create a receive resource for us. It isn’t important that they create the receive resource though, they can’t forge the signature since they don’t know the signing key and so they have to use the logic the receiver provides.

[xuyang]

Thank you, understood

If there are three layers of logic(KL, denomination-specific logic, and user-specific logic), it makes sense.
I wonder if having just two layers (application logic and user logic) is possible and better. The application logic layer handles denomination integrity, issuance, burning, governance, etc. The user logic layer manages consumption and creation policies, including receiving rules. Users can also choose how to consume their resources.

Now I got what I missed. The receiving logic signature is verified in KL, right?

[kike]

@xuyang

The receiving logic signature is verified in KL, right?

I think it is. The signature is verified.

@vveiln

Interesting, I assumed it would be slower because you mentioned that we need to verify the proofs recursively. Or did I misunderstand what you meant there by verifying a proof in the logic?

For the private case (when we hide we are dealing with kudos), the proof verification would need to be recursive. For the shielded case, as opposed to signatures, we can put the commitment and the zkp of correct PRF generation somewhere not in the resource, e.g. in the applicationData of the action as done currently in the app.

@vveiln

@kike

I’m just thinking in keeping the invariance of the supply, which in the current Juvix app is done via the quantity field, I believe, and as I get it, in your proposal the invariance is done via the DL.

I didn’t look into how it is done in the implementation, but I feel like if we have a stateful issuance verification (basically a verification mechanism that is triggered just once) and don’t allow any more issuance, we can rely on allowing only transfers

Not sure I understood, but surely some check must be done in a change of denomination to ensure the total existing supply is preserved. (The total existing supply would be the sum of existing created resources for each denomination.)

@vveiln

I think in this case bananas#5 and bananas#500 would be different denominations and I control them separately even though I own them both. In that sense it is the same as if i had bananas and apples

You control the resources you have created, but you cannot prevent creating new denominations that do not exist yet. In the same way a banana resource cannot prevent the creation of an apple resource. There are potentally infinite denominations for a single kudo type.

I still don’t get how you handle, say, bananas kudos in a unified way. Say they belong to me, I want to prevent to exchange any possible denomination bananas#n with apples#m, because apples have been banned by the community, or I don’t want a specific denomination bananas#1000000 to be created because it’s too big, or simply I want to be the only entity able to create denominations for bananas (because I’m the ECB bank).

Or maybe you can? is it the KL shared for all denominations? Probably I’m missing something somewhere.