Current CAP0023 proposal introduces two mechanisms:
- Allows to represent an arbitrary amount of an asset on the ledger
- delay creation/authorization of a trustline
Basically, it allows to
- create an "unspent entry" in the ledger ("initiate a payment") even if the destination doesn't exist or is not authorized yet
- claim one of those "unspent entries" ("complete a payment") as long as the claimant is authorized to do so
Is there a way to extend this mechanism to support UTXOs (which enables "non fungible tokens" at the same time)? First, we need to define what UTXO means in this context. We can define it as a chain of transformations (transactions) of "unspent entries" independent from any other ledger entries (therefore guaranteed to succeed).
For this to work we'll need to add a new transaction type that wraps a new "xpayment" "operation" that
- consumes one (or more?) balance entry
- Takes the fee from the XLM reserve in the balance entry
- Produces one or more new balance entries with deterministic IDs (ie,
H(source entries | output index)) NB: this transaction type doesn't use sequence numbers as it always consumes balance entries.
Implication: there is no way to stop an account from using xpayment in this context. This may weaken "freezing" to a certain extent. That said, enforcement is done when people try to claim balance entries, so it may be acceptable.
We could weaken the stance, by saying that in order to transform a balance entry the account must be authorized (or not exist and the issuer asset is "auth not required"), but this can cause those xpayment to fail, which complicates things quite a bit:
- We could mutate the balance entries in a deterministic way on failure
- Or we can add a flag to the balance entry that indicates that either
- xpayment is not allowed on those entries (so failure would never occur)
- Or requires
xtransactionto be wrapped by a standard transaction somehow (with a sequence number)
Follow up questions.
Q: Would we change CAP0023 if we were going to add this?
A: Maybe. There might be a way to move conditions off chain, basically only have a condition on pre-hash xtransactions (where the inputs are zeroed out as to make it possible to compute the hash) and have conditions on xtransactions that are ledger independent (so only time locks etc). NB: this rules out relative time locks so it may not be right.
Q: Can we add this later? A: it looks like this can be added on top of CAP0023. Only thing to be sure if is that balance entries have proper extension points/unions to allow for the transition if needed.