A market-making report is an operating record. It is not an audit, not investment advice, and not evidence that an exchange will keep a listing. The metric names below follow the way EasyMM's service pages talk about reporting. The exact file format is agreed per mandate. Nothing in a report is proof of organic demand, and nothing in it is a volume target.
Quick answer
A useful crypto market-making report has two layers that show up on a set cadence: a live or at least daily view of quoting (spread, depth, and whether quotes were present), and a weekly written pack that reconciles inventory, venues, and exceptions, with one named person on the project who reads it. Daily noise is not a strategy review. The pack describes the book the desk is responsible for. It is not proof that buyers are organic, and it is not a volume target.
Proposals often say "we send reports" and stop. That sentence is not a reporting pack. You want to know which fields exist, how often they arrive, who on your team owns them, and what the pack is not allowed to be used for. If those answers are missing, the reporting line in the quote is still blank.
EasyMM's market making pages state the cadence in plain language: 24/7 dashboards, daily and weekly summaries, and on-demand metric updates. Complex trading support repeats that same reporting promise. It is not a second product to scope here. The canonical place to put the pack is the market making engagement. Pre-launch teams can write the same field list into pre-TGE scope before the first book opens.
Quick definitions
Dashboard. The ongoing view. EasyMM's pages describe it as 24/7. It is where someone can see the book without waiting for a weekly email. It is not, by itself, a management decision.
Daily summary. Exceptions and inventory movement since the last check. It is not a new strategy, and it is not a place to relitigate the mandate.
Weekly pack. The document a founder can forward to finance or to an exchange contact. It has venue-level numbers, a comparison to the band you agreed, and a short note on what changes next week.
On-demand update. A pull when something breaks: a halt, a large fill, or a label notice. It is not a scheduled fourth report. It is the same fields, sent because the week cannot wait.
Spread, depth, uptime, and PnL already have a measurement article. One line each is enough here, then read how to measure market-making effectiveness if you need the definitions. Spread is the gap between best bid and best ask. Depth is size within an agreed distance of mid. Uptime is presence during the window you agreed. PnL, if it is in scope, is an inventory result, not a profit promise. Do not turn this page into a second glossary.
Cadence: dashboard, daily, weekly, on-demand
The cadence below follows what EasyMM's service pages describe. It does not add an hourly SLA that those pages do not state.
Dashboard, ongoing
Use it to see whether quotes are up, how wide the spread is against the band, and whether both sides have size. A founder should not have to ask for a screenshot to learn that the book was dark. The dashboard is the place that answer already lives. It will show noise. That is fine. Noise is not the weekly decision.
Daily summary
The daily note is an exception list, short enough to read in a few minutes. Three lines cover most days: missed coverage, inventory that moved between venues, and any exchange notice. If none of those happened, the daily note can say so in a sentence. A daily export of every fill is not a summary. It is a data dump your team will stop opening.
Weekly pack
Once a week, someone writes the week down by venue and by pair. This is the document finance can reconcile and a listing manager can forward. It compares results to the agreed band, names any window where the band was widened and why, and lists open issues. It is a management tool. If it cannot be forwarded without a verbal tour, it is not finished.
On-demand
Halts, large fills, and label notices do not wait for Friday. The on-demand update uses the same fields as the weekly pack, limited to the event: what changed, which venue, what the inventory did, and what you are doing next. Agree who sends it and who must acknowledge it. Do not leave "ping the group chat" as the process.
Who reads it
A pack with no owner is a file. Assign one person, not a group inbox.
Founder or CEO. Reads exceptions and risks: a venue that missed coverage, a notice from the exchange, a book that had to widen. They do not need every print.
Finance. Reads inventory units and stablecoin balance by venue, plus any inventory mark if that mark is in scope. They care where the units are, not about a blended slogan.
Ops or the listing manager. Reads the fields an exchange asked to see, in the same definitions the exchange uses. If the venue defined a band, this reader checks that the pack used that band.
One of those three, or a delegate they name, owns the weekly pack: they confirm it arrived, they file it, and they raise the open issues. Shared access is good. Shared ownership is how a warning sits unread.
What good looks like
Good reporting is specific. Each number is tied to a venue and a pair. Next to the spread, the pack writes the band you agreed, and it says whether the week was inside it. Next to depth, it writes the distance from mid you agreed, and it shows both sides. When the desk widened the band, the pack says when and why: a halt, a stale reference, a one-sided fill, an outage. "Market was volatile" without a timestamp is not a reason. It is a mood.
Skip vanity charts. A gallery of green lines that are not tied to a venue, a pair, and a band does not help finance or the exchange. A short outline is enough: coverage, spread versus band, depth, inventory by venue, exceptions, open issues. Send it as headings and short lists. The point is the fields, not a graphic.
EasyMM states 95% uptime as its operating target on the service pages. If your mandate uses that target, the pack should show presence against the window you agreed, and it should separate time the desk failed to quote from time the venue was down or the market was halted. A halted market or an exchange outage sits outside a quoting target. Do not let the weekly note bury that distinction.
What the pack is not
It is not a marketing screenshot of volume. Volume can appear as context. It is not the goal of the report, and it is not evidence about who the traders were. It is not a promise of rank on CoinGecko or CoinMarketCap. Liquidity can support those metrics. Rank is a separate outcome, not a deliverable, and not something the desk controls.
It is also not a substitute for the KPI clause in the agreement. The agreement is where spread, depth, coverage, and remedies are binding. The pack is how you see those fields week to week. Read the agreement article for the contract side, and see in-house vs outsourced market making if you are still deciding whether to hire a desk at all. Do not let a polished weekly PDF replace a clause you never signed.
The same pack during a recovery
If the token is already in a warning or special-treatment process, do not invent a second reporting system. Use the same fields, and add two lines: status versus the issue the exchange actually stated, and what changed this week. The reader should be able to see whether coverage, depth, and inventory moved relative to that stated issue. The path for that work is delisting help, which describes transparent weekly updates and liquidity dashboards during a recovery.
A recovery pack is still not an outcome. It does not promise that a label comes off, and it does not put a duration on the venue's process. It shows the work and the exceptions so your team and the exchange contact are looking at the same week.
How to read the pack on a Monday
Read in this order, and stop when you hit an exception you do not understand. Do not start with a volume figure.
1. Coverage. Were quotes up in the window you agreed, on each venue? If not, the reason should be a timestamped exception (venue down, halt, or a desk miss). A missing reason is the issue.
2. Spread and depth against the band. Inside the band, or widened, and why. Both sides, not the prettier side.
3. Inventory by venue. Token units and quote asset, plus anything that moved. Finance should be able to tie this to accounts without a second meeting.
4. Exchange notices. Anything received, and who answered.
5. Open issues. One owner, one change for this week. A pack that ends with "continue as normal" every week is not a management tool. It is a habit.
If step one is fine and step three does not match the accounts, believe the accounts and fix the pack. Reporting that cannot be reconciled is not transparency. It is a slide.
Write the same fields into the scope before launch
Pre-launch teams have a chance to make reporting a term rather than a favor. In the pre-TGE scope, name the dashboard, the daily exception list, the weekly pack, and the on-demand triggers (halt, large fill, label notice). Name the human who owns the pack on your side. Name the venues and pairs so the first week is not a blended number.
You do not need sample spreads in that scope. You need the fields and the cadence. The first live week fills the blanks. A proposal that offers "regular updates" and will not list the fields is the proposal this article is meant to slow down.
What finance will ask that a dashboard hides
A live screen is good at spread and presence. It is weak at the questions finance actually sends back. Build those into the weekly pack so you are not reconstructing them from chat logs.
Where are the units? Token and quote asset by venue, plus any balance that sits off-exchange as reserve. A single "inventory healthy" label is not a location.
What moved since last week? Transfers between venues, top-ups from treasury, and large fills that changed the mix. Name the direction. Do not make finance infer it from a balance that is merely lower.
What is a mark, and what is cash? If the pack includes an inventory mark, label it as a mark. It is not cash realized, and it is not a profit guarantee. If the mandate does not include a mark, leave the line out rather than inventing one.
What did we pay attention to? Open issues with an owner. Finance does not need a strategy essay. They need to know whether next week changes the balances they reconcile.
Ops reads a different slice of the same file: the band the exchange named, the window in the venue's timezone, and any notice that arrived. If those lines are missing, do not forward the pack to a listing manager and hope the dashboard link is enough. Export the fields. Keep the file. The agreement article is where you make delivery enforceable. This skeleton is what delivery should contain.
On-demand, in practice
Agree the triggers before you need them. A halt, a fill large enough that one side of the book no longer matches the mandate, and any written notice from the exchange are enough for most teams. When one fires, the note should arrive as a short version of the weekly pack: venue, pair, what changed, inventory after the event, and the next action. It should name the person on your side who must reply.
Do not add a trigger for ordinary prints. If everything is on-demand, nothing is. The daily exception list already covers missed coverage and inventory moving between venues. On-demand is for the event that should not wait for that list.
Weekly pack skeleton
Use this as the outline for the file. Leave the figures for your first real week. Sample spreads or sample volumes would be fiction.
Repeat the block below for each venue and pair. A multi-venue book is not one blended number.
1. Venue and pair. Name the exchange and the pair this block covers.
2. Coverage window and quote presence. Did the desk quote when it said it would? Write the agreed window, then the result for the week.
3. Spread versus the agreed band. Tightness only means something next to the band. Write the band, then the result.
4. Depth at the agreed distance from mid, both sides. Size, not just the top of book. Write the distance, the bid size, and the ask size.
5. Inventory by venue. What the project still has, and where. Write token units and quote asset units.
6. Large fills or halts. Exceptions, not every trade. Describe each one, or write "none."
7. PnL or inventory mark, if in scope. A finance view. State in the pack that it is not a profit guarantee. Leave the line out if the mandate has no mark.
8. Open issues and next week's change. This is what makes the pack a management tool. Write one owner and one action.
Daily exception list
Three lines, one sentence each. If a line did not happen, write "none."
Missed coverage. Which venue, which window, and the reason.
Inventory moved between venues. What moved, and in which direction.
Exchange notice. What arrived, and who answered.
What a report will not do
Keep these limits in mind when you read the pack or forward it to anyone outside the team.
It will not prove that traded volume has a particular character, and it will not be used here to accuse another firm. Keep the pack on your own book.
It will not guarantee uptime beyond the firm's stated target, and it will not treat a venue outage as a quoting failure.
It will not promise a ranking on a market data site.
It will not ship with invented sample numbers. Your first real week is the sample.
Conclusion
Ask for this skeleton when you scope market making. If the team is in a warning state, ask for the same skeleton plus the recovery lines on delisting help. If you are not live yet, write the field list into pre-TGE so launch scope includes who reads the pack. The service overview is on services, and shorter answers are on the FAQ.
A crypto market making report should let one named person on your team see, every week, whether the desk quoted, how wide, how deep, where the inventory sits and what went wrong. If you are still choosing a provider, ask to see a sample skeleton as part of the selection process, and if the token trades on several exchanges, make sure the pack splits inventory the way the multi-venue inventory guide describes. Teams under exchange review can map each line to the issue named in the warning system for that venue.
Frequently Asked Questions
Is a live dashboard enough without a weekly note?
No. The dashboard shows the book now. The weekly note is what finance and a listing manager can forward: bands, exceptions, inventory by venue, and next week's change. A screen without that note leaves the decision in someone's head.
Should the report show every fill?
No. Show large fills and halts as exceptions. Every print belongs in an export if you need an audit trail later, not in the note people are supposed to read.
Who inside the project should own the weekly pack?
One named person. Founders read exceptions, finance reads units by venue, and the listing manager reads whatever the exchange asked for. One of them, or a named delegate, confirms the pack arrived and raises open issues. A group inbox is not an owner.
Can we send this pack to an exchange?
Yes, if it uses the venue's definitions and does not mix venues into one blended number. That is a reason to build the pack by venue and pair. It is not a reason to promise the exchange will accept the file as a cure.
Does a good report mean the listing is safe?
No. A clear pack means you can see the book you are responsible for. The exchange decides listing status on its own tests. Reporting supports that conversation. It does not decide it.
What if the market maker only sends a volume screenshot?
Ask for the skeleton on this page: presence, spread versus the agreed band, depth on both sides, inventory by venue, and exceptions. A volume image does not answer whether the desk quoted, how wide it was, or where the inventory sits. If that is all you receive, the reporting line in the quote has not been delivered.
