Build a Custom Marketplace

I read the sentence
I have read every post in this thread
You know, I get the impression that unknown individuals who have ties to the Laguna team just decided to saw off the stash money that was collected over time by Laguna.
The affiliation between the Contractor and the Client (they are not hiding it).
Lack of a portfolio for the Contractor
3. Doubts about having experience in the field
4. I don’t quite understand what prevents you from engaging developers from the same Asia?


OS wont unlist all the nfts, so people still manipulate on OS the floorprice, im not in favor

Hi Keizer. CU Assets pertain to CU NFT Assets. Soft items are not included in the PRD in that they don’t have metadata. From LG’s perspective, we cannot give Merkle Root special access to soft item data either.

This is an entirely different thing that should be covered in the RMP Analytics instead.

You may refer to the PRD again to check what the full picture looks like in Phase 3.

  1. Is this demo interface serious? Just a picture, not a prototype, I hope the author can provide additions;

He provided a very early video of the prototype in this comment.

He said this re: custodial form:

We chose to go with a custodial model two main reasons. The first is time, we wanted the initial version of this marketplace to come online quickly so the community could start seeing progress and resolving some of their issues with OS. The second was security, this also relates back to time, a single contract in a well known and tested custodial model is much faster to secure and to audit. With all that said. We do know that the community likes to keep full custody of the assets. With that in mind we are planning to see if we can find a way to keep the assets in your wallet. This will require the meta data observer to be fast enough to detect a meta change and de-list the item, or prevent the completion of a transaction, before a transaction can go through. The meta can change in a single tick of the chain then the transaction in the second tick, so this is an abuse vector that needs to be closed. We may be looking to the community for guidance on what is an acceptable time frame. In the mean time, while we have custody, we can ensure you are getting what you payed for.

He said this re: OS

Something to consider here is that OS won’t be shut off when the new CU marketplace comes online. We hope that most players will migrate their activity to the new marketplace, and we have set the fees to incentivize it, but trading will most likely still happen on OS for all assets.

From the LG side: As this is web3, nobody can stop anybody from making their transactions in their preferred marketplace. As a project, marketplaces may even list us without us knowing and nobody can really stop them from doing that.

LG will continue encouraging the community to use the native marketplace though, but ultimately, nobody can stop anybody from using their preferred marketplace. And that’s okay. We expect this number to be really small though due to the fees.

The approved council functions can be found in the CUIP-04. These are the only functions that the council is expected to exercise for now and is approved by the DAO.

Thank you @sonolumin for this proposal and for being extremely thorough in answering all the questions that have been discussed here. I hope to see more of the community here because I am interested in seeing what they have to say. I would love to see what you guys have in the works going forward. I appreciate the honesty in every aspect in the answers you have given in all the above questions and queries, so I am wishing you all the best!

Hello Everyone,

This is not a direct reply to any person, but more of a reply to the concern of this being a custodial solution.

The first thing I would like to go over is that OS is a “semi custodial” or “joint custodial” marketplace. When you place an item for-sale or for-auction, OS calls a contract method that gives OS the permission to transfer said asset from your wallet. This permission lasts indefinitely until you go back to OS and remove the permission. So you have the NFT in your wallet, but you and OS have permission to transfer it to a 3rd party. We affectionately call this joint-custody.

You can read more about how OS manages this on the OS support pages.

I am not going to claim that there is a best way to do a marketplace, just give you some reasons why we went with the proposed method.

  1. By taking custody of the asset when it is listed for sale or auction we can guarantee the asset is not also simultaneously listed on another marketplace.
  2. By taking custody of the asset we can guarantee the owner of the asset can’t try to pull any shenanigans like: listing a Unicorn with five breeding points locking into the game, using a breeding point, then pulling it back out before the sale. This is something that would also be mitigated by a fast observer, but to start with we don’t have to rely on the accuracy of the observer service.
  3. It is faster to implement a custodial market than a true escrow only market.
  4. Due to the simpler design there is a smaller “surface” to secure.

We have considered how to build a truly escrow based marketplace. In the escrow model you would list you asset and we would only collect a signature from your wallet confirming you have the asset you are listing. We would then set an observer to watch your asset for any transfers or meta changes. If the observer saw any such changes it would delist the item. When someone clicked the buy button we would first collect the payment into an escrow contract, then we would notify you of the purchase. At that time you would need to come back to the market and approve a transfer of the asset into the escrow contract and then the transfer would be completed.

In the above model we would truly have no custody of your asset but there are a few issues that for which we don’t know the answer.

  1. This is the biggest: without collecting any KYC, how would we notify you to come back and complete the transaction. It would be a poor user experience for the buyer if they have to wait an unknown amount of time for the counter party to be notified then complete the transaction.
  2. We are only shifting custody to the buyer. We need to transfer their funds into the escrow contract to start the transaction at which point we are back to having custody of assets. We could only collect permission to transfer funds, but this is back to the “joint custody” situation. We don’t think it would be feasible for every transaction to have both parties simultaneously online to where both could transfer into the escrow contract within minuets of each other thus minimizing custodial time.

I know this has been a bit of a long winded post and I hope it come across as a kinda brain dump of how and why we made the proposal as-is and not as a defense or claim that any one method is better than the other. We are all crypto holders ourselves and understand not wanting to have to trust anyone with our assets.

A few final words on how we are securing the market.

  1. Issuing the listing party a NFT receipt. The contract will require the input of said receipt in order to de-list and withdraw any items. We won’t even have the ability to pull your item out of the contract without the receipt.
  2. The trade observer will have to co-sign transfers. This system looks for anomalies in trading and stops the trading for human review. An example would be “if greater than x% of trade volume is going to a single address: stop trading”. We don’t want to publish the set of rules or the training data used to make them so a malicious 3rd party can’t dissect the system.
  3. Having the system security reviewed by a 3rd party, and making the contract code open to anyone that wants to do their own review.

Thanks again for your time. The writing time on this was one cup of coffee long :slightly_smiling_face:


Hi all and hi MR Team. Thanks very much for the proposal and your detailed thoughts and replies which does give a lot of confidence.
I do not think that the rates are far off market – but that said I still have a very simple question from an economic POV regarding the fees and RBW part of the compensation:
Usually, when a party takes on risk (and corresponding return opportunity → “upside sharing”), the fixed portion of the compensation gets discounted to make this trade-off possible and economically viable (e.g. compensation in a startup for early employees which dial back on fixed comp in favour of stock options). But with your proposal I cannot really see that trade-off, i.e. both the fixed payment and the monthly floor do not suggest a risk-taking on MR’s end. Hence, against this backdrop, just wanted to better understand the rationale behind that and if it would be an option to turn everything into fixed comp and what this would look like from your POV.
Thanks so much!

1 Like

Since this could have such a large impact on the future of CU, wondering if Merkle Root devs would be open to setting up an AMA with the community. A verbal discussion vs just a written discussion here on the forum could be helpful.


This may be something that I have to defer some of the LG team to answer about the philosophy of how they want to make sure the ecosystem partners have plenty of funds to keep operating and iterating.

In short: We don’t want for there to be a possibility we get into a position where we can’t pay for the hosting and critical security maintenance that must be done every month. This statement is meant to be honest and hopefully not alarming. We do currently have plenty of capitalization and income to provide such a service, but you never really know what the future brings. Under the minimum fee model– no mater the circumstance the marketplace stays running and maintained.

We looked at several fixed fee options. For example we considered a cost per user per month to be around $0.021 (users distinctly identified by IP for browsing and wallet address for listing/buying). This would put 1,000,000 users/mo at $21,000 and 2,000,000 users/mo at $42,000. It was decided that tracking users would be a hassle and a hard sell so it was abandoned.

We still needed a pricing metric that grows with the size of the user-base, so we ultimately landed on transaction volume. The only other option we have not really considered that I think could work in a fixed-fee model would be for LG to bear the costs of the hosting and we get payed a fixed amount each month for our engineer’s time.

I would love to hear some more thoughts. Please let us know if you have any ideas.

Hello, IslandGirl. Do you mean an AMA between Merkle Root and the community?

Yes. An AMA between Merkle Root and the community.

Let’s make it happen. I’ll coordinate re: this. Any announcement will be made by the CM team on Discord and the socials. Thanks, IslandGirl.

1 Like

If LG is already managing hosting for other aspects of the game and related resources that is something that should be considered, especially if they already have staff to manage the hosting.

Part of my concern is how MR’s self interests align with the community when it comes to that particular bucket of funds.

You (@sonolumin) posted the key hosting costs. I noticed you listed licensing costs as well as the Enterprise cloud costs. I could be mistaken but it seems the Elastic licensing is covered by the cloud provider. Is the license for a local (non cloud) development setup? I also wonder what features of Elastic Search your team is going to utilizes that make the Enterprise feature set (and associated cost) needed? I hope it wasn’t picked because it has ‘Enterprise’ in the name.

I’ve been out of the hosting busines since 2013, I wish I had a better idea of the hardware and bandwidth requirements for Elastic.

My biggest hope and wish is that MR sees that transaction percentage fee as a license to print money and is hungry and ready to create the best, most engaging, frictionless NFT market out there that takes CU to 1M DAU and beyond.


My biggest fear with full custodial marketplaces are something like this:

this could also be done by checking the DNA of the unicorn / the lock state. Just listen to the unicorn contract for “lock into game” events, and if locked into game, delist from marketplace.

This can be solved by listening to breed events and updating the metadata of a unicorn in your own database whenever a breed happens. Also, with what I said above, the second the unicorn is locked into the game, it would become delisted.

My issue is with full custodial marketplaces. Joint-custody is not an issue for me, see the twitter post I linked above. Imagine something goes wrong and every single unicorn for sale gets locked into the contract forever.

I agree with this, and think an escrow model is not the solution either

I think this will cause unneeded congestion and complications. Also, it becomes 1 extra NFT that needs to be tracked, and tax wise, it would make things a nightmare. I am giving you an NFT for another NFT. Then when it sells, Im giving you back that NFT for eth. that is 2 taxable events in the United States, instead of just 1.

Any smart contract will need to be open source, as it belongs to the CU community…nvm this is covered in your point below

Audits are incredibly expensive. Who pays for them? and what company do you plan on using?


Also, I find it kinda ironic that this tweet from Opensea came out today:

We are open to taking the marketplace in a joint custodial direction similar to OS. We would need to extend the initial deadline a few weeks to accommodate the change. I’m going to make a poll here to get some numbers on the communities preference.

Would you prefer the Crypto Unicorns Marketplace to be:

  • Fully Custodial (contract takes possession of your assets when listing)
  • Joint Custodial (contract only collects permission to transfer your asset when listing; same as Open Sea; extend the deliverable by two weeks)
  • No Preference

0 voters

Personally, for the increased peace of mind, I have no issues with extending the deadline.

1 Like

I think it is great that you guys are asking and a good sign of your ability to work with the community.

Wallet permissions have their own set of pitfalls, how many of use truly scrutinizes every MM tx we approve? Hacks have taken advantage of this…

I don’t feel like I know enough about this to make an informed decision. Personally I used OS because that is where the NFTs where, not because of some crypto ownership ideal. And in all honesty I just skimmed through that part of the CU whitepaper, I didn’t really understand how other projects handle NFTs differently.

Based on the explanation in the proposal post I find myself leaning towards full custodial. JC seems to share many of the risks without the benefits.

After @Maxbrand99 reply I find myself leaning towards JC. So much to learn…