⚖️
A clearer price picture
Show the community's current view of a reasonable price range, with enough context to understand how many people voted and whether opinions differ.
A healthier market.
More room to grow.
I'd like to explore a simple community market program for Cozy: a place where players can understand current prices, see what people are looking for, and find their own reason to build a shop.
✳
This is a proposal, not a finished rulebook.
The scope, voting method, eligibility, and any petition requirements still need discussion and approval. The goal is to make the economy more useful and welcoming—not to target individual sellers or dictate every trade.
The scope, voting method, eligibility, and any petition requirements still need discussion and approval. The goal is to make the economy more useful and welcoming—not to target individual sellers or dictate every trade.
01 · The idea
Help players find their place in the economy.
I have seen how quickly prices can shift and how difficult it can be to know what is worth producing or selling. I'd like us to make that information easier to find, especially for players who are thinking about opening their first shop.
🧭
Useful opportunities
Give players a weekly view of what others are asking for and which requests still need suppliers—without promising profit or declaring one shop better than another.
🌱
Room for new shops
Make it easier for new and established players to spot a niche, plan a farm, offer a service, or supply something the community actually wants.
The principle: the program should provide useful information and a fair process. It should not become a public call-out system, a way to force every seller to charge the same amount, or a promise that every listed item will sell.
02 · Policy choices
Three ways this could work.
I think we should start with the least restrictive model, learn whether it helps, and only consider stronger rules if the community explicitly wants them.
A. Advisory market guide
Community votes create a suggested range. Buyers and sellers can use it as a reference and still agree on any price they choose.
Recommended starting pointB. Petition-linked guidelines
Staff could decide whether shops that require a shopping petition should follow clearly stated guidelines as part of that approval. This needs an explicit decision and clear wording.
Needs staff discussionC. Mandatory price limits
Shops would be required to stay within approved ranges. This is much more restrictive and would need clear server approval, exceptions, and enforcement rules.
Not proposed for the first versionMy preference is Model A first. We can separately discuss whether any agreed guidelines should apply to shops that require petitions. Access to the market information should be useful to everyone, regardless of where their shop is located.
03 · Who it covers
Keep the scope fair and clear.
The discussion has included a 100-block area around End spawn, a 500-block area, or all shops. I don't think we should confuse where the information is available with where a rule might apply.
Market information
- ✓Make the guide and demand board available to all players, including shops farther from End spawn.
- ✓Keep the information useful to new players as well as established shopkeepers.
- ✓Don't publish seller rankings or identify individual players as the cause of price changes.
Any agreed rules
- ✓Ask staff to clarify whether the relevant area is 100 blocks, 500 blocks, or something else.
- ✓Discuss separately whether shops requiring a petition must follow any approved guidelines.
- ✓Don't assume voting or using the guide automatically makes a shop subject to mandatory prices.
04 · Community price guide
One choice per player. Results everyone can understand.
I'd like to use the emoji-range idea discussed with NykteusDark, with a bot making the voting process easier and keeping the published table up to date.
1️⃣
Choose a range
Each listing has a clearly defined item and quantity—such as one stack, one shulker, or one individual item. Voters select a range rather than typing a price.
🔁
Change your vote
A player can have one current choice per listing. Choosing a different option replaces the previous choice instead of counting as another vote.
📊
Update the results
The results table can refresh when votes change, showing the leading range, vote count, and distribution—not just a winning emoji without context.
What a listing should show
| Field | Why it matters |
|---|---|
| Item and variant | Prevents unlike items, enchantments, or specifications from being lumped together. |
| Quantity / listing type | Separates a stack, a shulker, and an individual item or tool. |
| Price ranges | Uses one published range table, with consistent diamond and diamond-block conversion. |
| Vote totals and spread | Shows how many people participated and whether there is broad agreement. |
| Last updated / status | Distinguishes a provisional result from a reviewed market summary. |
The exact price bands and listing categories still need testing. The ranges should handle boundaries cleanly and avoid pretending the votes reveal an exact, objectively correct price.
05 · Fair representation
Buyers and sellers both have something to contribute.
A concern raised in the discussion is that most voters may be buyers, which could make the result lean toward lower prices. I don't think we should solve that by choosing an arbitrary multiplier before understanding the data.
A sensible first approach
- ✓Collect one valid vote per eligible player for each listing.
- ✓Define transparent eligibility for the voter role and shopkeeper role.
- ✓Display buyer and shopkeeper results separately at first.
- ✓Test combined or weighted formulas using sample data before selecting one.
Why show both views?
A buyer may consider 5 diamonds reasonable while a seller believes the work and supply costs make 15 diamonds sustainable. That difference is useful information, not something a formula should hide.
A weighted result may help represent different groups, but it cannot remove genuine disagreement. Small samples and coordinated voting should remain visible in the published results.
06 · Weekly demand board
Help people decide what to make next.
This is the other half of the idea: a weekly summary of what players want, what remains unfulfilled, and what someone might investigate supplying.
📬
Most requested
Items players are asking for, including requested quantities and useful specifications.
🧺
Unfulfilled requests
Requests that still need a supplier, with fulfilled requests updated or removed from the active list.
🌿
Potential opportunities
Ideas to investigate based on demand and available supply—not guarantees of profit or promises that customers will appear.
For example: requests might distinguish between a few stacks and full shulkers, or between different rocket specifications. A popular item can still be oversupplied, so demand should be considered alongside existing supply and the market guide.
07 · Trust and upkeep
Make it difficult to misuse.
The program will only work if people trust the process. These are safeguards I'd like us to consider with staff and the community.
Clear eligibility
Explain how voting access is earned, how shopkeeper status is verified, and how inactive accounts are handled.
Privacy first
Publish aggregate item results rather than individual votes or public accusations about sellers.
One current vote
Changing a selection replaces the old one. The system should reject duplicate or invalid votes and provide a way to flag bad listings.
Visible methodology
Show sample sizes, result calculations, dates, and meaningful differences between voter groups.
Keep history
A new month can start a fresh voting period while previous summaries remain available for understanding trends.
Review the process
Staff or an agreed community group can review abuse reports and suggest changes without dictating every price.
08 · Suggested rhythm
Weekly demand. Ongoing votes. Monthly review.
Weekly demand cycle
Collect requests, summarize demand, identify unfulfilled requests, and publish the next opportunity board.
Ongoing price discovery
Collect votes and update provisional results, with vote counts and uncertainty visible.
Review window
Consider a short provisional period—perhaps two or three days—before a result is included in a reviewed summary.
Monthly market review
Archive the period's summary and start fresh voting without carrying old votes into the new period.
The cadence is a suggestion. We still need to decide whether the review window applies to each item or to a scheduled batch of listings, and whether results should be called provisional, reviewed, or official.
09 · How it could be delivered
One source of truth, two ways to use it.
If the idea is approved, I'd like to help with the planning and, if permitted, the implementation. The aim would be to make the information easy to use in Discord and on the Cozy website.
🤖
Discord bot
- ✓Manage listings, eligibility, and one current choice per voter.
- ✓Update result tables when votes change.
- ✓Schedule demand boards, review windows, and monthly summaries.
- ✓Provide moderation and correction tools for approved staff.
🌐
Website view
- ✓Searchable market guide with current and historical summaries.
- ✓Weekly demand board and unfulfilled requests.
- ✓Vote counts, update dates, and an explanation of the method.
- ✓Possible integration with cozymc.com, subject to site access and staff approval.
The bot and website should read from the same approved market data, so results don't contradict each other. This page demonstrates the proposed flow; shared voting across different visitors will require an approved backend and data store.
10 · Proposed next steps
Plan first. Test fairly. Build when ready.
I don't want to rush a complicated system into the server before the rules and calculations are clear. This is the order I'd suggest.
Agree on the policy
Clarify purpose, geographic scope, petition-linked requirements, and who can approve changes.
Set the market method
Define price bands, voter eligibility, buyer/shopkeeper representation, sample sizes, and reset rules.
Design the demand board
Decide how requests, quantities, fulfilled orders, and possible opportunities are collected and summarized.
Test the maths
Use hypothetical data to test uneven participation, conflicting opinions, low turnout, and vote manipulation.
Run a small pilot
If approved, test a limited selection of items and review whether the results are understandable and useful.
Build and review
With permission, integrate Discord and the website, gather feedback, and let the community decide what should change.
11 · Community input
What should we decide together?
I'd appreciate feedback on the direction before anything is treated as a rule. Enter a name to unlock this preference poll, then choose one option in each section. You can change your choices later.
Add your perspective
This prototype lets people try the proposed voting flow. It does not make server policy or control shop prices.
Enter a name to continue.
Results are shared through the Cozy proposal service when the Cloudflare Worker is configured.
Prototype note: your choices are saved only in this browser on this device. Other visitors will not see your votes yet. A shared website poll needs a server-side database and an agreed privacy policy before launch.
🔒
Poll locked
Add a display name on the left to unlock the questions.
Before anything is finalized
Questions I think we should answer.
Should this be a petition, or a separate program?
I'd ask staff which approval route they prefer. The market guide and demand board can be proposed as a program, while any mandatory petition-linked requirements should be decided explicitly rather than assumed.
Who can vote, and how is a shopkeeper role granted?
Eligibility should be transparent and manageable. We need to decide whether it is based on playtime, staff approval, an application, or another method, and how to handle people who are both buyers and sellers.
What does a result actually mean?
For the initial version, I suggest a community estimate rather than a required selling price. If any binding rule is considered later, it needs separate approval and clear enforcement and exception rules.
Can the website poll be shared between visitors?
Not in this standalone demonstration. Shared votes need a backend that stores and validates submissions, identifies duplicate voters appropriately, and provides staff controls. The prototype currently saves to this browser only.