Marketplace
The Marketplace is our ecosystem's marketplace. Although Harmony now has a collection of existing and upcoming 3rd party Marketplaces, we have come to the realisation that our project will contain a wide range of NFT collections including ERC721 and ERC1155 tokens.
For this reason, we want to invest our resources early into designing and building our very own Marketplace to make sure we have the sufficient foundation and infrastructure in place to release new features and give our players the immediate ability to start trading.
Buying, Selling and Fees
Any collection that is listed within the tavern will be sold for $KNIGHT, our custom token that has been designed to drive our ecosystem. We want our $KNIGHT holders to have the freedom to spend their earnt tokens on whatever they please, whether it is additional assets to further their collection in Rensmira, advance their journey and chances through our upcoming roadmap of features or even just to flip their way to a larger portfolio.
All transactions (specifically buys/sells) within the marketplace will be subject to a 3% fee. These fees sent to:
1.5% is burned ( sent to dead0x address)
1.5% sent to the bank to be split among everyone staking their $KNIGHT
All fees within the marketplace are dynamic and can be changed at any time. Naturally, public announcements will be made and in most cases will include voting or require some form of agreement within the community before being set in the contract. It is important to note here that we will never change the fees without notice, and there is a hardcoded maximum value of all current fees. This maximum value is set at 5%.
Note: we are keeping other 3rd party marketplaces within Harmony at the forefront of our mind. It is not our goal to put our holders off using them, if anything, we believe the more options on Harmony in general is for the better. However, we want fees to be competitive and give people another option when trading Knights and Peasants assets.
Custodial
With the interest of token security at the forefront of our marketplace design, we have decided to build and launch our Tavern as a custodial marketplace. This means that when a token is listed for sale, it will be transferred from the owners wallet to the marketplace contract and held in escrow until the sale is cancelled or a buyer is found. We believe it is a trustless way of ensuring that tokens are safe throughout the entire sales process. By handing all control over to a immutable contract, there is a massively reduced chance of any foul play from either party during a trade.
Listing your Knights on our tavern will prevent them from being able to claim their training camp emissions, complete any future quests or take part in other features that require the owner to sign specific transactions to authorise their use. With that said, thanks to the low gas fees on Harmony, "delisting, claiming, relisting" is always an option however we want our holders to know that at any moment their token could be bought and any unclaimed emissions (etc) will be transferred with the ownership of the token.
For example, if user A listed Knight 1337 for 1000 $KNIGHT and the Knight was purchased 10 days later, the new owner would immediately be able to claim those 10 days of emissions from the training camp. We want to make sure that all holders are aware of this whenever a token is listed for sale.
Custom Subgraphs
There are many different ways that have been identified across blockchain projects to help optimise user experience and logic flow when it comes to dealing with "large" sets of data stored on chain. When we think of a Marketplace, we don't always think of the amount of data that we want to present in the frontend. Most users, and developers, might just think we need to show a list of tokens that are currently for sale... although that may be true, think of all the extra features that could improve the quality of the Marketplace, such as the floor price of a collection, the amount of volume that has been moved in a certain amount of time, the last 10 purchase (etc).
Information such as this can be stored within a contract, however, reading this from the chain every time a page is refreshed could become cumbersome, and in the event of RPC issues, could lead to a Dapp showing nothing but errors. This is where a subgraph can come in handy. Unlike many projects at the moment, Knights and Peasants have designed the Tavern from the ground up with direction correlation to a subgraph. Our marketplace will launch with it's own custom subgraph, hosted by us and include our own custom mappings and handlers to give us access to all the data we want, when we want it! Although this will rely on Web2, we internally agreed that this is the most efficient way we can complete our wants at this time.
Last updated