Whose Accounts Does a Market Maker Trade From? Who Controls What?

Under a retainer model, the market maker trades from the project's own exchange accounts, funded with the project's own capital, accessed through API keys that permit trading and have withdrawals disabled. The tokens and the capital never leave the project's control. Under a token loan model, the project transfers tokens to the desk, which trades them from its own accounts. Both structures are used across the industry, and the custody difference between them is the single largest practical distinction, larger than the fee difference most founders focus on.

"Do market makers hold your tokens?" is the question we get most at EchoTrade, and the honest answer is that it depends entirely on which model you sign.

Worth stating before the comparison: EchoTrade works on the retainer model only. We do not offer token loan deals, so we never hold client tokens. That is a disclosure rather than a claim about the other model, and the description of both below is written to be fair to each.

Whose accounts does a market maker use under a retainer?

In a retainer engagement, nothing moves out of your control.

You open the exchange accounts in your project's name and complete the exchange's KYB process yourself. You fund them with your own capital, both the tokens and the quote currency the desk will quote against. You then generate API keys on those accounts and share the keys with the desk.

The desk uses those keys to place, amend and cancel orders. It cannot move anything out. That restriction is not a matter of trust or contract language, it is enforced by the exchange at the permission level, which is what makes this model structurally safe rather than conditionally safe.

The practical consequence is that ending the engagement takes one action. You delete the API key. Access stops immediately, the capital is already in accounts you own, and there is nothing to retrieve from anyone.

What permissions does a market maker's API key need?

A market maker's API key needs two permissions, read and trade, and should have a third, withdrawals, switched off. Exchange API keys carry separate, individually toggled permissions, and this is where the security of the whole arrangement lives. Binance's [API key documentation] shows the toggles side by side, and notes that withdrawal permission cannot even be enabled without an IP restriction in place. The relevant ones for a market making engagement:

Read. View balances, open orders and trade history. Required.

Spot and margin trading. Place, amend and cancel orders. Required, and this is what the desk actually does all day.

Withdrawals. Move assets off the exchange. Not required, and it should be off. Market making is quoting and cancelling orders, which needs trading permission and nothing beyond it. Moving assets is not part of the job.

Two further controls are worth applying on top:

IP whitelisting. Most major exchanges let you restrict a key to specific IP addresses. Applied properly, a stolen key is unusable from anywhere except the desk's own infrastructure. Ask the desk for its IPs and set this.

Sub-accounts. Where the exchange supports them, give the desk a sub-account funded with the working capital for that venue rather than access to your main account. It contains the blast radius of any mistake and makes the reporting cleaner, since everything in that sub-account is the desk's activity and nothing else.

Whose accounts does a market maker use under a token loan?

The loan model works the other way round.

The project transfers tokens to the desk, typically 0.5% to 2% of supply. The desk provides the other side of the book with its own stablecoins and trades from its own exchange accounts. There is no API key on your accounts because your accounts are not involved.

This is not a security failure. It is what the structure requires: the desk is providing the capital, so it holds the inventory. But it changes the question you should be asking. Under a retainer, the question is what an API key can reach. Under a loan, the question is what the agreement says about the tokens you have transferred, since they are now genuinely out of your control until the term ends.

The terms that matter are the strike price, the expiry, and who chooses the repayment currency. In most loan agreements the desk decides at expiry whether to return the tokens or keep them and pay a preset dollar price. That choice belongs to the desk, not to you. We cover the full comparison in retainer vs token loan.

What about DEX liquidity?

On-chain the picture is different again, because there is no account to grant access to.

Liquidity pool positions are held by whichever wallet created them. If the desk manages a pool for you, either it operates from a wallet the project controls, or the project transfers assets to a wallet the desk controls. There is no exchange sitting in the middle enforcing permissions, so the arrangement is worth writing down explicitly rather than assuming.

Where a project wants on-chain assets managed without handing over keys outright, a multisig with the project as a required signer is the usual answer. It is slower to operate than a single key, which is a real cost, and whether that cost is worth paying depends on the size of the position.

What should I check before granting API access?

Five things, and together they take about fifteen minutes against a 12 to 24 month commitment.

Confirm withdrawals are disabled on every key you generate, and check it on the exchange rather than taking anyone's word for it.

Set IP whitelisting wherever the exchange supports it.

Use sub-accounts where they exist.

Write down who holds what, venue by venue, in the agreement rather than in an email thread. This includes the on-chain positions.

Agree the offboarding process in advance. What happens to inventory, keys and any open positions when the engagement ends. A desk that has a clear answer has done this before.

What are the red flags?

Three requests should stop a conversation until they are explained properly.

A request for withdrawal permission. There is almost never a legitimate reason.

A request to hold your capital under a retainer arrangement. If you are paying a fee for a service, the capital being traded should be yours and should stay in accounts you own. A structure that combines a monthly fee with the desk holding your assets is worth a direct question about why.

Vagueness about custody. A professional desk answers this question in specifics: which accounts, whose name, what permissions, what happens at the end. Hesitation here is information, and this is one of the questions worth asking before you sign rather than after.

Why does custody matter more than the fee?

Custody is the part of a market making agreement with an irreversible failure mode.

A fee that turns out to be too high is a bad deal you can exit at renewal. Assets that left your control under terms you had not modelled are a different category of problem, and the founders who run into it are rarely the ones who were reckless. They are the ones who assumed the model they signed worked the way the other model works.

Ask the question directly, get the answer in writing, and check the permissions yourself. It is fifteen minutes of work against a twelve to twenty-four month commitment. For the wider picture of what the service involves day to day, our guide to crypto market making covers the mechanics.

For our part, EchoTrade works on the retainer model only, across more than 90 exchanges. Your accounts, your capital, API keys with withdrawals disabled, and no token loans on offer. When a founder asks whether we will be holding their tokens, the answer is no in every engagement we run, and it is the same answer whichever call it comes up on.

FAQ

Does a market maker hold my tokens?

It depends on the model. Under a retainer, no: the tokens and capital stay in exchange accounts owned by the project, and the desk accesses them through API keys that permit trading but not withdrawals. Under a token loan, yes: the project transfers 0.5% to 2% of supply to the desk, which trades it from its own accounts until the term ends.

What API permissions does a market maker need?

Read access and spot trading. Nothing else. Withdrawal permission is not required for market making and should be disabled. Where the exchange supports IP whitelisting, restrict the key to the desk's addresses, and use a sub-account rather than the main account where sub-accounts are available.

Can a market maker withdraw my funds?

Not if the API key is configured correctly, because withdrawal permission is enforced by the exchange rather than by the agreement. This is why the permission setting matters more than any contractual assurance: with withdrawals disabled, the desk is technically unable to move assets off the exchange regardless of what it might intend.

What happens to my capital when the engagement ends?

Under a retainer, nothing needs to happen: the capital is already in accounts you own, and revoking the API key ends the desk's access immediately. Under a loan, the borrowed tokens are returned or retained at the desk's option depending on the terms, which is why loan agreements need reading carefully before signature rather than at expiry.

Should I give a market maker access to my main exchange account?

Use a sub-account where the exchange supports one, funded with the working capital for that venue. It limits what any error or compromise can reach, and it makes reporting cleaner because the sub-account contains only the desk's activity.

Who controls DEX liquidity positions?

Whichever wallet created them. There is no exchange enforcing permissions on-chain, so the arrangement should be written down explicitly. A multisig with the project as a required signer is the common solution where a project wants managed on-chain liquidity without handing over sole control of a wallet.

Planning a listing?

We handle the market structure side: order book depth, spreads and uptime across 90+ exchanges. [Message us on Telegram] before you submit the application, not after.