CIP-0125? | Arrestable native assets

[micahkendall]

This proposal has overlap with the problem statement CPS-3? Smart Tokens

(rendered in branch)

[micahkendall]

I'm open to comment pre-implementation to get feedback on the high-level design.

[micahkendall]

For the record, there are significant but maybe subtle differentiators from CIP-0113 (including, differentiators from the most recent 'V2' which @matteocoppola clarified to me)

• this proposal has a single spending script hash, rather than many (however the implementation may use an additional withdrawal script for optimisation purposes)
• the owner is a field in the datum
• the implementation is key to the proposal, this is due to network effects as ideally many different seizable assets may be used together, this is best accomplished if they may be in the same utxo
• we don't try to do anything related to 'accounts' or ERC-20
• we specify the CIP more succinctly, because it doesn't try to generalise

[michele-nuzzi]

This feels like a specific subset of CIP-0113

I'm not saying it shouldn't be implemented, after all if we take Ethereum as an example they too have multiple standards for multiple specific token kinds (ERC20, ERC721, and so on...)

Before proceeding with making it a standard when should also consider the benefits of having a specialized one for seizure-specific assets.

I'll cover a few points mentioned about CIP-0113

• this proposal has a single spending script hash, rather than many (however the implementation may use an additional withdrawal script for optimisation purposes)
• the owner is a field in the datum

the "V2" of CIP113 is not final yet, in the sense that we are implementing it to see how it works.

if multiple scripts are a problem we can always move the parameters in a datum and we have a single script.

Multiple scripts were introduced to facilitate the offchain, as indexing based on the datum is still pretty limited.

• the implementation is key to the proposal, this is due to network effects as ideally many different seizable assets may be used together, this is best accomplished if they may be in the same utxo
• we don't try to do anything related to 'accounts' or ERC-20
• we specify the CIP more succinctly, because it doesn't try to generalise

As you mentioned there are few benefits to having an ad-hoc standard, but we should also consider if it is worth the differentiation of assets

[rphair]

@micahkendall we have to shrink the title for consistency with other CIPs, especially to remove words that will be implied to the reader and/or present as Motivation. We can see how this works in the PR title & if you have an alternative recommendation let's try to keep the CIP + PR titles consistent. (Note there is no hyphen in the phrase native asset.)

Note re: the compilation stub here: even though only currently redirecting to another repository, the CIP format might contain code samples and schemas but we have decided by consensus in the past not to include source trees. It would be sufficient in this case to include a link to the butaneprotocol/subledger repository (with some introduction if appropriate), and so unless disputed your /subledger directory should be removed.

@michele-nuzzi's #832 (comment) suggesting this CIP is a subset of candidate CIP-0113's functionality is compelling, and might be a benefit to avoid fragmentation of these implementations as the community is trying to launch them in Cardano. I would love to see some cooperation between you two & to see these proposals combined unless there are irreconcilable specifications that you want to pursue independently.

@micahkendall if you do choose to submit this as an independent proposal please

1. consider marking it as a solution to CPS-0003 as @michele-nuzzi has for his parallel proposal in #444 (comment)
2. please adopt the standard format corrections & editorial guidelines below.

accidentally hit the "green tick" instead of "comment" button

[micahkendall]

@michele-nuzzi's #832 (comment) suggesting this CIP is a subset of candidate CIP-0113's functionality is compelling, and might be a benefit to avoid fragmentation of these implementations as the community is trying to launch them in Cardano. I would love to see some cooperation between you two & to see these proposals combined unless there are irreconcilable specifications that you want to pursue independently.

I think there are significant differences in the CIPs, my goals around simplicity and compatibility with existing EUTXO patterns are not present in CIP-0113. Furthermore on the topic of fragmentation, I think the CIP-0113 proposal is wholly incompatible with the goals of this CIP, so I think fragmentation is inevitable, whether both are accepted or not. I would also argue that my CIP is more favourable because it addresses the core regulatory issues for RWA, however does not enable any additional functionality outside of that scope, which would be appealing to the RWA ecosystem which may not want to break too far from the native asset standard.

One non-negotiable in my proposal is script hash per protocol: in my design, every asset class and user would share the same script hash, forming a closed but wholly interoperable system. An example of how this is functionally different, is that you can automate the transformation as described here:

• 1. take an existing smart contract system such as an AMM DEX
• 2. wrap the validators such:
  • the top-level validation is always a 2-arg validator
  • when there is a mint or certificate, normal logic except for the script context mapping
  • wrap the redeemer so that the difference between Spending, Spending&Withdrawing, Withdrawing can be branched
  • for each spend from the sub-ledger, invoke the validator in the wrapper
  • the context arg has it's properties mapped such that the input elements in the subledger and the output elements are mapped to be regular
• 3. send utxos such that the credential field in the datum is set to the new validator hash, instead of the address field of the output, locking them in the 'mapped validator'

This construction is meant to indicate more the power of maintaining EUTXO ideas, rather than as an actual purpose or goal of the CIP. It is merely emergent advantage of the CIP, not to be included in the CIP description.

@micahkendall if you do choose to submit this as an independent proposal please

1. consider marking it as a solution to CPS-0003 as @michele-nuzzi has for his parallel proposal in CIP-0113? | Programmable token-like assets #444 (comment)

I have included a link due to the overlap, however my proposal actually doesn't aim to address the same issues as CPS-0003. The express goal of that CPS is to control the native token lifecycle, which my proposal explicitly avoids, within the subledger you have full regular native asset functionality, such as sending to others without restriction and no ability to tax or validate any transfer or receipt of assets.

My proposal comes from the angle of approaching a very particular aspect of regulation, rather than any goal for more expressiveness in token programmability. The scope is very narrow, and the proposal is very simple, hence the Path To Active is much more achievable. Especially so when we consider the wide ecosystem changes that would be necessary.

2. please adopt the standard format corrections & editorial guidelines below.

Yes sir.

[rphair]

@micahkendall thank you for clearing up my understanding on these points. It sounds like it would suit the Cardano ecosystem well for these two CIP's to develop independently and I can understand also why we would want to keep it separate from CPS-0003.

I'd already added it to the agenda to introduce (not necessarily review) at the next CIP Editors' Meeting (https://hackmd.io/@cip-editors/90) in 1½ weeks and you are welcome to come along to help with that introduction.

@michele-nuzzi if you would like to take the opportunity to attend for a good comparison & contrast of your two proposals at that meeting, please let me know and I'll also put #444 on the agenda for a review (since it's been a while and we could use an update if you are ready).

[micahkendall]

@rphair Here is the new Compare and contrast section, for your enjoyment

[rphair]

thanks @micahkendall ... yes, I think that's a good addition.

[rphair]

@micahkendall I argued at the CIP meeting tonight that this should be assigned a CIP number so that this can better progress in parallel with #444 and to help potential implementors choose which model suits them best. Your recent updates & comments for both CIPs have been very helpful with that. cc @michele-nuzzi

@Ryun1's earlier suggestions for the CIP title (#832 (comment)) were based on suggestions from the meeting that:

• the term Seizure suggests an enthusiasm for doing so (rather than your stated modest goal of regulatory compliance)
• Plutus subledger is not "a thing" and neither really is subledger so to use those terms implies their usefulness in technical reference (currently none). cc @Crypto2099

Please also change the containing directory to CIP-0125. 🎉

[rphair]

p.s. to #832 (review) - @micahkendall after waiting for any disputes, I've recorded it in the CIP candidates list via #844 with the most recent title correction. If any further corrections please post in this thread and/or change in the branch source CIP title... otherwise please change the CIP title to match the PR title.

[micahkendall]

p.s. to #832 (review) - @micahkendall after waiting for any disputes, I've recorded it in the CIP candidates list via #844 with the most recent title correction. If any further corrections please post in this thread and/or change in the branch source CIP title... otherwise please change the CIP title to match the PR title.

Hey cheers. The requested changes are mostly wording so I don't really care whether they are protested or not. Whether the CIP is enthusiastic or not doesn't meaningfully affect usage.

I would argue the term "subledger" is useful as a coined term because of how it can be useful for abstraction. From the CIP's glossary: "A subset of the main ledger that tracks specific types of transactions or assets, often with additional rules or functionality."

[rphair]

I would argue the term "subledger" is useful as a coined term because of how it can be useful for abstraction

sure @micahkendall let's keep this term in mind whenever the question of the title comes up... I'll suggest reintroducing it myself if discussion indicates it would help with the abstraction.

[rphair]

@micahkendall I noticed this PR wasn't categorised & also that the CIP was given a Ledger category. That would only be appropriate if changes to the Ledger were going to be required — which doesn't seem so in this case — and since the software device you are calling a "subledger" interacts with native assets, I believe (pending possible further discussion) that this is really a Tokens category proposal:

[rphair]

Suggested change

	Category: Ledger
	Category: Tokens

[rphair]

@micahkendall is this work by any chance also being absorbed into

• CIP-0113? | Programmable tokens #444

the way that

• CIP-0143? | Interoperable Programmable Tokens #944

has been? It's been a long time since this proposal was updated (so marking Waiting for Author as an alternative to closing it as Likely Abandoned) but perhaps, while candidate CIP-0113 is headed through validating its reference implementation towards confirmation & merging, some cooperation with that team (@colll78 @michele-nuzzi @matteocoppola) would be beneficial?

In any case please let us know either where this is going or if you have discontinued work on this potential standard.

[micahkendall]

Cheers for the follow up, don’t think the proposal is covered by any of the above but I don’t have time to push it through

[rphair]

thanks @micahkendall for the update & for your ideas so far. I'll give it a brief cooling-off period and then remove this candidate CIP link from CPS-0003 unless there is any objection. cc @Ryun1 @Crypto2099 @perturbing

[colll78]

I think CIP-113 after updating to CIP-143 does indeed cover all the proposed value of this CIP:

this CIP maintains the same script hash across all UTxOs, hence saving budget, enabling programmability, allowing ease of interoperability, because we use prefixing to identify assets which are locked to the subledger, we may not only have one script hash across the same asset class, but across all asset classes (I believe making this the favourable CIP for DEX integration) again, because we use prefixing, you may put non-seizable assets into the subledger, and then withdraw them again, so no wrapping is necessary for example to swap $BTN (true native, unseizable) and $USDC (subledger native, seizable), because a subledger DEX can simply operate with both in one UTxO

CIP-143 addressed this. Now, all programmable tokens live at the same script hash. CIP-143 also is designed around the concept of a mini-ledger (referred to as subledger in this CIP) and allows non-seizable / non-programmable assets to enter and exit the programmable tokens mini-ledger. No wrapping is necessary.

native assets are still used

CIP-143 also uses native assets, not virtual assets.

this CIP isn't a standard of implementations, it aims to provide a single implementation, to minimise fragmentation

CIP-143 also is not a standard for implementations, it is a single implementation of a mini-ledger for programmable tokens within which all programmable tokens must exist. Programmable tokens can never exit this mini-ledger, nor can they be minted outside of it.

no account abstractions

CIP-143 (and thus CIP-113) doesn't use account abstraction.

narrow scope, enabling a faster path to active.

CIP-143 is active on mainnet, with a minting platform and a management UI platform for viewing balances, freezing, seizing, and making transfers.

[rphair]

thanks @colll78 - I've therefore removed the Abandoned tag whose main purpose is to get either an old or new author to continue the work... not necessary here since it seems already achieved. 🎉