Developing a token listing system for a crypto exchange: from application to trading

Token listing system development: where the process breaks

While there are two or three token listing applications per month, a scheme based on email, a spreadsheet, and messenger chats looks workable.

Then the flow grows, and the same project undergoes manual review several times: the lawyer reviews documents in one version, the reviewer in another, and the decision on the application lives in a message thread that not every participant has seen.

The application registry is kept in a spreadsheet, but it has no owner and no change history. The status is rewritten manually, some projects get stuck between stages, and for some, no one can say who made the decision and when. Lost application decisions surface only after the project has gone to another platform.

Manual project review does not scale: each token takes more and more time, and the timeline for listing a token for trading stops being predictable.

At the same time, risk grows: different employees work with different versions of documents, and a formally completed stage turns out to be confirmed by nothing but a verbal agreement.

Externally, this looks like slow requirements review; in reality, it is the absence of a unified process with checkpoints. We break down how this is closed: where a mandatory status is set, what is checked automatically, and what is deliberately left to a human.

What managed token listing provides

Managed listing is a pipeline of decisions with formalized rules, not manual approval in chats.

An application undergoes contract address verification, compliance with the ERC-20 standard, control of token emission and distribution, and filtering by sanctions and fraudulent addresses.

Automation of token admission removes routine from the team and moves application decision time from weeks to hours.

The second effect is a unified status registry instead of chats and spreadsheets. Each application has one current status, an assigned owner, and a transition history: who moved it further, when, and on what basis.

The question "what's going on with this token" no longer requires manual searching — the state is visible to all process participants in one place.

The third is that a whole class of rejections due to human error goes away. During manual assembly, it is easy to confuse a contract address between networks, duplicate a pair, return to an already rejected application, or publish data before final confirmation. Input checks cut off such cases before they enter the trading loop.

Transparency of the listing process also provides auditability: every decision leaves a trace — input data, check results, the author of the change.

This makes it possible to reconstruct the picture months later, show partners and auditors the justification for admission, and reduce the share of manual operations to isolated exceptions that truly require human attention.

Methods of admitting tokens to trading: comparison

Admission schemes differ not in how an application is submitted, but in when a human appears in the process and what remains in the decision log.

Application intake is almost the same everywhere — a form in the applicant's account, an address for incoming requests, or integration via an API — but after that, the forks begin.

The choice depends on the flow: up to several applications per month, a manual scheme is reasonable; as it grows to dozens, a hybrid is needed; and in a high-volume flow with standard requirements, automatic status transitions remove routine from the team.

The limitations of each scheme are visible only at its own scale.

Manual does not scale in terms of timelines, automatic does not take on substantive project evaluation, and hybrid requires discipline in status management — but it is the one that provides a predictable review time without losing control.

Therefore, the scheme is selected based on the number of incoming applications, the share of rejections, and trace requirements for the regulator, not on interface convenience.

How implementation proceeds: stages of engineering work

Implementation proceeds in iterations of one to two weeks: each stage is closed with a verifiable artifact, not a document for approval.

The listing process audit takes the first week; after that, the client's team sees progress on real applications and can change priorities without rewriting the project.

1. Listing process audit. We analyze the current application path: who initiates it, where it is approved, what checks the project undergoes, at which transitions data is transferred manually, and where it is lost. The output is a process map with bottlenecks and an estimate of the scope of work.
2. Role and status scheme. We fix a finite set of states — draft, review, compliance, approval, placement, rejection — and permissions for each transition. Contested cases (application on hold, return from compliance) are described explicitly so that the logic does not sprawl across the code.
3. Integration design. We determine where project data comes from and where the decision goes: contract verification, reconciliation with restriction lists, transfer to the trading loop. For each failure point — a retry and notification to the owner.
4. Setup and development. We assemble the application module, issuer account, notifications, and action log. Every status change is logged with the author and time — this is the basis for reviewing contested decisions.
5. Trial operation. We run the process on applications from past periods and on a limited group of employees: we check transitions, notifications, rollbacks, and system behavior with parallel applications.
6. Training and handover to support. We hand over access, documentation, and regulations, and review typical rejections. We fix the support period and escalation channel so that the client's team can run the process independently.

Handover package: configurations and regulations

The documentation package is not an archive of files but a description of the working environment and the rules for operating it. Each document is tied to a specific part of the listing system, so the client's team can change rules without parsing the code again.

• Configured environments — separate configurations for test and production environments: automatic check parameters, limits, list of supported networks.
• Application flow diagrams — the project's path from submission to trading opening: approval points, "revision / rejection" forks, the owner at each step.
• Access policies and roles — a permissions matrix: who accepts an application, who conducts review, who publishes a trading pair, and who can suspend trading.
• Project review regulations — admission criteria and a working checklist: token distribution structure, contract audit report, readiness for market operations.
• Team instructions — scenarios for common cases: manual application review, trading pause, re-review after project changes.
• Update procedure — how to change listing rules and application forms, how migrations and rollback to the previous configuration work.
• Decision logs — who approved the listing, when, and on what basis; this removes disputes during incident review.

The package is synchronized with the system: a rule change first goes into the regulations, then into the code. Describe which block you need first — we will come back with an estimate and a plan.

Case study: how an exchange eliminated manual application review

How it was

A mid-sized exchange received about 40 listing applications per week. Review was manual: emails in a shared inbox, tokenomics descriptions and audit opinions in attached files, and only the manager handling an application knew its status.

The average decision time reached seven business days, and 40% of applications were returned for revision due to submission errors — mismatched deployment network, incomplete document package, discrepancy between the contract address in the application and in the project repository.

What was changed and what the result was

We built a unified application route: a form with required fields and input format validation, automatic verification of the contract address and network, and a queue split by placement type.

We made RabbitMQ the routing core — an application cannot get "stuck" with one employee; each has an owner and an escalation timer.

After implementation, the exchange consistently handles 110-130 applications per week with the same listing team.

The average decision time dropped from seven days to one or two: standard applications pass review automatically, and lawyers and security are involved only where their decision is truly needed.

The share of rejections due to submission errors fell from 40% to 8% — the remaining rejections are deliberate, for compliance reasons, and this is the filter working normally, not losses out of nowhere.

The team's workload shifted from routine to substantive work: analysts review contested cases and the projects themselves rather than moving statuses between spreadsheets.

The freed-up time went to pre-screening applications before submission, so not only did the number of processed requests grow, but so did the quality of projects that reach trading.

What to do if the panel is already deployed?

If an exchange is already running on its own admin panel, tearing it down and launching listing from scratch is the worst option: the accumulated application history is lost, and the team learns anew.

We start with an audit: which modules handle application intake, checks, and trading pair publication, where state is stored, and which external services are connected to it.

The first stage is reading: our layer looks into the same database or connects to the same panel API, builds a mirror of statuses, and compares discrepancies without changing the working process.

Then modules are migrated one by one, starting with application intake and checks: the new logic runs in shadow mode, decisions are compared with current ones, and the result becomes primary only when they match.

We maintain compatibility with current processes at the level of the status model, roles, and review regulations — employees work within familiar logic, and only the internal implementation changes. New checks are connected in separate steps and do not rewrite the application queue.

There is no need to stop trading: listing is a change in the composition of pairs and their configuration, not a halt in order matching.

The switch happens under load, with dual writes during the transition stage and an idempotency key so that an application is neither lost nor duplicated. The accumulated decision history is transferred in full — it is needed both for reviewing contested cases and for reporting.

Listing system development here is an add-on to a working environment, not a replacement from scratch. Describe what your panel is built on and which processes are tied to it — we will come back with an estimate and a phased transition plan.

Technical questions and client concerns

Five concerns that a client raises before starting listing: protection of application data, flow growth, external project checks, migration of decision history, and support after handover. We address each.

Will it withstand flow growth?

Application intake and processing are separated by a queue: as the number of projects grows, review workers scale rather than the core being rewritten. We deploy updates without stopping intake — an already submitted form is not lost.

Which external checks are taken into account?

Sanctions and reputation lists, and address checks based on blockchain analytics data, are connected via replaceable adapters. A new source is a change to configuration and matching rules, not a core rework.

What about the history of past decisions?

We migrate history from spreadsheets or CRM: statuses are matched by a dictionary, past decisions and compliance comments are loaded with project linkage. After loading, we reconcile the number of applications and decisions, and resolve discrepancies before handover.

Who is responsible after handover?

We hand over the source code, data schemas, and operating regulations with descriptions of typical failures. After that — support within an agreed response window: updating checks, adjusting listing rules, and incident review.

Let's discuss the task and come back with a plan

Estimating the scope of work makes sense only after analyzing the task: seemingly identical listing requirements differ in detail across platforms, and it is these details that determine the effort.

Therefore, the first step is not an estimate but a conversation about how your process is structured from application to trading opening and what checks a project undergoes before admission.

• Roles and permissions: who submits a listing application, who reviews the project, who approves admission of a pair to trading, and who can stop trading.
• Target platforms and their requirements for the application form, project data disclosure, and review timelines.
• Admission rules: mandatory checks, scoring of the project, risk handling, and repeat applications after rejection.
• Integrations: custody of client funds, identity verification, fraud prevention, and accounting of balances and trading pairs.
• Publication regulations: how a pair appears on the marketplace, what data a trader sees, and how delisting a pair and refunding funds are processed.
• Action trace requirements: which events are recorded, how long they are stored, and in what form compliance control sees them.

From these inputs, we assemble a scope estimate, a stage-by-stage implementation plan with a working demo after each stage, and the team composition: analyst, backend engineer, smart contract engineer, QA engineer, and release owner.

We record the order in which work starts in writing — what we do first and what we need from you for access to test environments. Describe the task in free form — we will come back with an estimate and a plan.