-
Notifications
You must be signed in to change notification settings - Fork 335
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CIP-0125? | Arrestable native assets #832
base: master
Are you sure you want to change the base?
Conversation
I'm open to comment pre-implementation to get feedback on the high-level design. |
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 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
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.
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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
- consider marking it as a solution to CPS-0003 as @michele-nuzzi has for his parallel proposal in CIP-0113? | Programmable tokens #444 (comment)
- please adopt the standard format corrections & editorial guidelines below.
accidentally hit the "green tick" instead of "comment" button
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:
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.
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.
Yes sir. |
Co-authored-by: Robert Phair <rphair@cosd.com>
@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). |
@rphair Here is the new Compare and contrast section, for your enjoyment |
thanks @micahkendall ... yes, I think that's a good addition. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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 issubledger
so to use those terms implies their usefulness in technical reference (currently none). cc @Crypto2099
Please also change the containing directory to CIP-0125
. 🎉
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." |
Co-authored-by: Robert Phair <rphair@cosd.com> Co-authored-by: Ryan <44342099+Ryun1@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Co-authored-by: Robert Phair <rphair@cosd.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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:
CIP: 125 | ||
Title: Arrestable native assets | ||
Status: Proposed | ||
Category: Ledger |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Category: Ledger | |
Category: Tokens |
This proposal has overlap with the problem statement CPS-3? Smart Tokens
(rendered in branch)