private metadata viewership logic (while in fractionalized state)
2. SNIP1155 reference implementation : multi-token standard reference implementation for Secret Network:
create reference contract based on ERC1155 / CW1155
add Secret Network-specific features, eg: viewing keys, query permits, access control, private metadata, etc., including adjustments to these features to fit the multi-token standard.
I believe having these two pivotal standards/features on Secret Network will be very valuable. I also believe it is value accretive to the ecosystem to have the core functionalities built out first before additional features.
In terms of timeline, the scope of this is around 4 months, but with features becoming available earlier for applications willing to iron out some code and deal with less documentation. I estimate 1-1.5months for (1), 1.5-2months for (2), and an additional month or so for debugging/testing/tying loose ends. My ask for doing these two CCBL items is $100,000.
If the community is supportive, I plan to come back on-chain after this to fund Parts 2 and 3 of fractionalized sNFTs (my original scope), and potentially cross-chain integration for SNIP1155.
I’ve gone ahead and wrote in the original posting, but will be cross posting here just in case
I believe the original proposal included trade royalties and cross chain implementation, while the new proposal instead only covers the part 1 of the original post(core functionality) with SNIP 1155 implementation taking precedence over the orignal part 2 and 3 of prop 75. (Hoping that makes sense)
I still see a discrepancy with the ask going from 68.5k to 100k, however. The timeline shows that 4 months is still what the roadmap is looking like so I’m curious to know what the bump in pricing is for?
Would we be able to dive a little deeper into understanding the price ask for this? Thanks in advance!
Thank you for initiating these developments, these are definitely key features for the Secret Network.
I would be in favor of having the 2 features split into separate calls for funding as raised in the original thread.
It would enable expressing feature dev requests with reduced costs & timelines, and also would enable having others to take those features potentially in parallel. Ideally there would be collaborations, i.e. not just 1 developer on these features implementation. But that might be already part of the plan.
Ideally the expected payments are split, e.g. 30% at start, 30% in the middle, 40% once considered/validated as done.
Having minimum dev code quality commitment / what will be covered, e.g. test coverage, done criteria / api breakdown, reference integration sample(s), documentation(s)
Sorry for the specification overhead, the concern is mostly to make this dev funding request process safe for the community trust on the long run. The commitment and planning should be more formally expressed imo for a $100K funding request of an individual developer over ~4months.
Hi Jabba, the frac-sNFT’s architecture will be loosely based on fractional.art and unicly’s model. I outlined features in my original post, but just like SNIP1155 the detailed specifications themselves (which will be more involved, because of the added privacy features required on SN) will need to be written as part of the project. I aim to cover key features with unit/integration tests within the timeline, but eventually an essentially 100% test coverage. Docs and tests and will be more backloaded in terms of timeline, and I anticipate there will be ongoing work afterwards.
In terms of funding schedule, from my understanding, it’s a function of the way the CCBL and community pool funding is designed. I am not speaking for CCBL/community of course, but it’s probably fair to say that having to come onchain multiple times to fund a project would present substantial time/effort overhead for developers which, again from my understanding, is precisely what the CCBL aimed to address.
Regardless, I hear your concerns. My aim is to get the first iteration of the specifications written for frac-sNFT as one of the first priorities, which will specify how each of the features I outlined will function (ie: what must, should, must not etc. happen).
Obviously you are free to start from scratch if you want to, but you could probably cut your dev time for 1155 in less than half, by just adding/updating functions related to fungibles to the 721 implementation. That was the route I was going to go if I ever had the time to do 1155.
That way you’d be able to use all the existing privacy functionality. You could either use the view_private_metadata permission to also include viewing the balance of a fungible if applicable, or add a new view_fungible_balance permission. Even if you are adding a new permission, you would still be able to use all the privacy/whitelisting functionality already there just by adding the new permission type to the permission arrays.
So all that would really be needed is adding optional quantities to the existing 721 code. If None, it is non-fungible, otherwise it is fungible with a quantity.
Not only does it make it a much smaller amount of work, but it also makes 1155 backwards-compatible with existing 721s, much the same as 722 non-transferable tokens are backwards-compatible with 721. You could even look at the code pushes in the ref implementation for 722 as an example of how you would implement quantities (could be done almost identically to the non-transferable flag)
Hi DDT, This is Chill Validation. Nice to meet you!
We like what you are doing and wanted to verify:
The difference between your original ask of $68k->100k is based on an additional month of debug/test/loose ends?
Is the duration and intensity of effort fairly in line with other ecosystems? Or is it “especially harder/more time consuming” due to SCRT’s architecture?
Also due to the rate/size of the ask, we wanted to ask if you could point out any other recent examples of this rate structure. We thought it might be good to be able to say that the funding is in line with something else.
What do you think of the suggestions that baedrik has offered? And would it any material impact on you scope/future implementation plans?
Hi baedrik, thanks for the comments, which are helpful as always. I never intended to reinvent the wheel of course. Although I will probably start from a blank slate, I will also be borrowing/editing functions from CW1155, SNIP721 and SNIP20. I also had the chance to look into your SNIP721 ref impl in more detail the last few days and can see that it has quite a lot of the privacy features that are needed. Will certainly be good to make SNIP1155 backward compatible as well, which would definitely help with usability.
Maybe I’ll put it out here anyway, that I plan to do quite a lot of “Part 2” (collections and royalty) of the frac-sNFT implementation as part of this scope anyway. Especially if the SNIP1155 turns out to be quicker than expected, I will start on the other parts I initially scoped for frac-sNFT, especially the royalty part. So this funding will cover some/many of Part 2 in addition to what I proposed when submitted on-chain.
The debugging/test/loose ends/documentation etc. have always been there, and will likely continue as ongoing/maintenance effort. It would make no sense to go from 68->100 for tying loose ends! The initial move to 82.2 was the additions of functions to allow fractional owners to interact with the underlying NFT via voting/DAO mechansim eg: reveal, setwhitelistapproval (and make sure some other functions cannot be accessed eg: those that allow someone else to transfer the NFT out of the vault). In addition, functionality to allow the creator (person who initially fractionalizes the NFT) to configure the parameters/thresholds on how these interactions are decided between the frac-owners. This also need to be implemented into “Part 2”, with the ability to do these on collections of NFTs (which can be from different SNIP721 contracts). Then the move to ->100 was when I combined with SNIP1155. As as I mentioned in above, I actually plan to do a good portion of Part 2 anyway, especially the royalty part which I think is important. So I am really adding SNIP1155 to the mix, and doing essentially all the key/urgent/important features of frac-sNFT as well. Hence the increase. As I mentioned in the original thread too, in my initial scope there would have been a bit of a wait between Part 2 and Part 3 because I would need to wait for Secret Network to upgrade (enabling CosmWasm1.0) before starting Part 3 (cross-chain). With the new scope there won’t be any wait like this, means the total amount of work is quite a lot more.
I don’t want to point to other proposals too much, but the hourly rate here is definitely lower than the $150/hr for devs to mentor others in the upcoming dev committee proposal And separately, just to point out that I don’t get financial upside from the success / adoption of these contracts, since it is not eg: a game or exchange etc. where I create a utility token and get to benefit from price appreciation.
Maybe to add a bit on your point 2, short answer is yes. The privacy features add a lot of complexity, and effort doesn’t scale linearly with complexity I am not building from scratch since I will be able to borrow from earlier work as mentioned…but there’s always going to be work to adjust/modify/tweak and properly integrate them to suit the implementation. It’s never a simple case of copy-pasting code from various places, because that normally doesn’t work, and is at best just sloppy.
An update: the fractionalized Secret NFT standard implementation is now functional.
Feature highlights
⦁ Allowing the first privacy-preserving fractionalized NFTs to be created
⦁ All the benefits of fractionalization as seen on other blockchains, with the added advantages of having a privacy layer (eg: users can own and trade fractions of Secret NFTs privately)
⦁ DAO functionality to grant private metadata viewership to certain addresses, or vote on configuration changes
⦁ An improved auction process to unfractionalize and buy out the underlying NFT
Next steps
⦁ More extensive unit and integration tests, to ensure potential bugs are uncovered and fixed.
⦁ More documentation, including on known attack vectors and how to mitigate them.
⦁ Also, at some point potentially to add functionality outside the scope of the current grant: particularly secondary royalties
⦁ Possible front-end implementation so users can actually start fractionalizing NFTs on Secret Network?
Thanks in advance!