DEV Community: mrcnm

I've been implementing NAND-tree quantum algorithm in Qiskit Python

mrcnm — Mon, 17 Aug 2026 15:27:06 +0000

So, recently I started working with the Qiskit, a python library for quantum computing. Thankfully, it allows to simulate a few qubits on local devices, so I didn't go broke after a few sessions.

Anyways, there is a model, called NAND trees. A NAND tree is basically a binary tree where every branch combines the two values below it using a NAND gate. The input bits sit at the leaves, and for the script to work upward until it gets a single value at the root. For a small tree this is easy, but for bigger trees, as more and more values need to be checked, it can get quite computationally expensive.

So, this is where the quantum computers can help. Instead of calculating from bottom to the top, the tree is turned into a graph and the different routes through it become paths that a quantum state can evolve across. A line, or "runway", is attached to the root of the tree, and the input bits change the connections near the leaves. The output after this operation is different depending on NAND tree, which allows to calculate them.

I build the tree and runway as one graph, encode the input at the leaves, and send a quantum wave packet toward the tree. The wave spreads across the available paths, interferes, and the amount transmitted or reflected is used to predict the NAND-tree result.

So, that's what i tried to reproduce in my project.
Although it is still experimental, but prototype works like a pleasure. Although technically unlimited, the algorithm is not implemented perfectly, so there are issues with scalability, but experimental trees for up-to 8 leaves work perfectly! But, the more leaves are added, the more time and resources are required, so sadly it's just an experiment as of now.

But any feedback will be helpful, as this may allow us to fully reproduce the algorithm!

here's the project, with the deeper explanation of algorithm too: https://github.com/mncrftfrcnm/qiskit-nand-tree-implementation

Thank you for reading!

I Let Claude Code Control a Crypto Exchange API (Safely)

mrcnm — Fri, 12 Jun 2026 14:25:26 +0000

This sounded like a bad idea at first.

Not “bad” in the fun startup way. More like: this could accidentally place a real order if I get lazy.

I had been experimenting with Claude Code and API workflows, and eventually I wondered what would happen if I gave it access to a real crypto exchange API. In my case, I was working with the MEXC API.

That sentence alone probably needs a disclaimer.

I did not want to build an autonomous trading bot. I did not want to paste API keys into chat. I did not want to tell an AI agent to “go trade for me.” That is not the point of this project.

What I wanted to test was more specific:

Can an AI coding agent safely help with exchange API workflows if the workflow is scoped, dry-run first, and human-approved?

That experiment became this repo:

https://github.com/mncrftfrcnm/mexc-agent-trading-skills

It is still alpha. It is experimental. It is not production-ready. It is not financial advice. It is not affiliated with MEXC.

But it works.

And more importantly, it changed how I think about AI agents and dangerous APIs.

The scary part is not the model

When people talk about AI agents doing risky things, the conversation usually turns into:

“Is the model smart enough?”

That is not the question I care about anymore.

The better question is:

“Why does the agent have access to things it does not need?”

That is where the real danger starts.

A crypto exchange API is not like a weather API. A bad request does not just return the wrong forecast. Depending on the permissions, it can place orders, cancel orders, read private account data, stream account events, or expose sensitive credentials in logs.

The model does not need to be malicious for something to go wrong.

It can simply:

confuse Spot and Futures
use the wrong endpoint
assume the wrong symbol format
place a live order when you meant dry-run
print a signed URL while debugging
mix up base quantity and quote quantity
skip a confirmation step because your prompt was vague

These are normal developer mistakes.

The difference is that an AI agent can make them very quickly and very confidently.

So my goal was not to make Claude Code “autonomous.”

My goal was to make it useful without giving it too much freedom.

My first mistake: too much documentation

At first, I treated the API docs like a normal developer resource.

I gave the agent a lot of documentation and expected it to figure out the right path.

That sort of worked for simple things.

But once the workflow got more specific, the problems became obvious.

The MEXC API has different areas:

Spot REST
Spot WebSocket
Futures REST
Futures WebSocket
public market data
private account data
signed requests
test orders
live orders
listen keys
positions
balances
order books
rate limits
error responses

That is a lot for one agent to hold in its head for a simple task.

If I asked something like:

Prepare a BTCUSDT buy workflow.

the agent had to infer too much.

Is this Spot or Futures? Market or limit? Test order or live order? Should it check symbol rules first? Should it sign the request? Should it check balances? Should it use base quantity or quote quantity?

A human developer would ask those questions too.

The problem was that the agent had too much room to guess.

That is when I stopped thinking of the documentation as “context” and started thinking of it as “permissions.”

The better idea: skills instead of giant docs

The repo is built around a simple idea:

Do not give the agent the whole API.

Give it the skill it needs for the current job.

Right now, the project is split into four main skill areas:

mexc-spot-rest
mexc-spot-websocket
mexc-futures-rest
mexc-futures-websocket

This sounds basic, but it makes a big difference.

If I am working on a Spot REST task, the agent does not need to think about Futures WebSocket streams.

If I am reading public market data, the agent does not need private account-stream instructions.

If I am preparing an order, the workflow should be very different from a read-only ticker query.

That separation made Claude Code much easier to work with.

It stopped feeling like I had thrown a giant API manual at the model and hoped for the best.

It felt more like giving a junior developer a specific runbook.

That is a much better mental model.

What “safe” means here

I am using the word “safe” carefully.

This project does not magically make live trading safe.

It does not remove risk.

It does not mean the agent is always right.

What it does is add friction in the places where friction should exist.

For example, a safer workflow should look like this:

1. Use a scoped skill.
2. Start with read-only data.
3. Prepare the request.
4. Run a dry-run.
5. Redact secrets.
6. Show the final action clearly.
7. Ask for explicit human confirmation.
8. Only then consider live execution.

That is the difference between “Claude Code can help me operate an API” and “Claude Code is randomly controlling my exchange account.”

The second one is terrifying.

The first one is useful.

I do not paste secrets into chat

This is one of the most important parts.

The workflow should never require pasting API keys directly into the conversation.

The repo expects credentials to come from local environment variables:

MEXC_API_KEY=your_api_key_here
MEXC_API_SECRET=your_api_secret_here

That does not mean environment variables are perfect. They can still leak through logs, shell history, screenshots, bad scripts, or careless debugging.

But it is much better than pasting real credentials into a prompt.

The rule I follow is simple:

No real keys in chat.
No secrets in source files.
No .env files committed.
No signed URLs printed for convenience.
No listen keys or private account payloads copied into public places.

This part is boring, but it matters.

Most security failures are boring right until they become expensive.

The API key should not be powerful

Another obvious rule: the API key should have the smallest permissions possible.

For this kind of experiment, withdrawal permissions should be disabled.

Actually, for most agent experiments, the first key should probably be read-only.

There is no reason to start with a key that can trade.

The progression should be slow:

public market data
→ signed read-only account data
→ dry-run order preparation
→ test order where supported
→ tiny live action only after explicit confirmation

Skipping straight to live trading is the fastest way to turn a fun experiment into a postmortem.

Dry-runs are the most important feature

The biggest practical improvement was dry-run behavior.

Before doing anything live, the agent should show what it intends to do.

For example:

{
  "symbol": "BTCUSDT",
  "side": "BUY",
  "type": "MARKET",
  "quoteOrderQty": "25",
  "mode": "dry-run"
}

This gives me a chance to review the request before it touches the exchange.

And the review is not just a formality.

I want to check:

Is this Spot, not Futures?
Is the symbol correct?
Is the side correct?
Is the amount correct?
Is this a market order or limit order?
Is it using quote amount or base amount?
Is it still in dry-run mode?

The agent can prepare the request.

The human should approve the risk.

That boundary matters.

Vague approval should not count

One small thing I added to my own workflow: vague approval is not enough.

These should not trigger a live trade:

ok
yes
go ahead
looks good
continue

For live actions, the confirmation should repeat the actual action.

Something like:

I confirm live Spot market buy BTCUSDT with quoteOrderQty 25 USDT.

Is that annoying?

Yes.

That is the point.

When money is involved, I want the workflow to be slightly annoying.

A little friction is better than an accidental order.

A safer prompt

Here is the kind of prompt I would use with Claude Code:

Use only the mexc-spot-rest skill.

Goal:
Prepare a BTCUSDT Spot market buy using 25 USDT.

Rules:
- Do not place a live order yet.
- Start with a dry-run.
- Do not print API keys, secrets, signatures, listen keys, or private account data.
- Check symbol information and current market data first.
- Check account balance only if credentials are already configured locally.
- Use a test order if supported before any live order.
- Ask for explicit confirmation before live execution.
- Do not treat vague approval as permission to trade.

That is much better than:

Use the MEXC API to buy BTC.

The second prompt leaves too many decisions open.

The first prompt gives the agent a job, a boundary, and a review process.

What worked

The scoped-skill approach worked better than I expected.

Claude Code was more focused when it did not have to read everything.

It was easier to guide.

It was easier to correct.

And when something went wrong, it was easier to find the source of the mistake.

If the issue was in Spot REST, I could inspect the Spot REST skill.

If the issue was in Futures WebSocket, I could inspect that skill.

That sounds small, but it makes debugging much less painful.

The agent also became less likely to mix unrelated concepts because the context was smaller.

Instead of asking it to reason over the whole exchange API, I was asking it to operate inside one lane.

That made the whole workflow feel more controlled.

What still needs work

This is still alpha, and I do not want to oversell it.

Futures workflows especially need extra caution. Futures are more complicated than Spot. There are positions, leverage, margin modes, liquidation risks, contract rules, and more ways to make painful mistakes.

Even if the agent prepares something that looks correct, I would not treat Futures live execution as “safe.”

At this stage, the repo is better viewed as:

an experimental structure for safer agent/API workflows

not:

a finished trading framework

That distinction matters.

The project is useful, but it still needs testing, review, and hardening.

The pattern is bigger than crypto

The part I find most interesting is that this pattern is not really about MEXC.

It applies to any powerful API.

Payment APIs.

Cloud infrastructure.

GitHub automation.

Database admin tools.

Deployment systems.

Internal dashboards.

Anywhere an AI agent can affect a real system, the same question comes up:

How much access does the agent actually need?

Most of the time, the answer is: less than we give it.

A good agent workflow should have:

scoped context
limited permissions
dry-run mode
clear logs
secret redaction
human approval for dangerous actions

That is not as exciting as “fully autonomous AI.”

But it is much more practical.

My checklist now

If I am letting an AI agent near a serious API, this is the checklist I want in place:

[ ] Dedicated API key
[ ] Withdrawal permissions disabled
[ ] IP restrictions if available
[ ] Read-only access first
[ ] Minimal permissions
[ ] No secrets pasted into chat
[ ] No .env files committed
[ ] Sensitive values redacted
[ ] Spot and Futures separated
[ ] REST and WebSocket separated
[ ] Dry-run before live action
[ ] Test order where supported
[ ] Explicit confirmation for live action
[ ] Tiny size only if live testing is necessary
[ ] Manual review of every live request
[ ] Key rotation plan if anything leaks

This checklist does not make the system perfect.

It just prevents the easiest mistakes.

That alone is worth it.

The repo

The project is here:

https://github.com/mncrftfrcnm/mexc-agent-trading-skills

It currently includes skills for:

MEXC Spot REST
MEXC Spot WebSocket
MEXC Futures REST
MEXC Futures WebSocket

It also includes helper scripts, request-signing workflows, WebSocket notes, safety rules, and layouts for Claude / Claude Code / Claude Desktop and Codex-style repository agents.

Again, this is alpha.

It is experimental.

It is unofficial.

It is not financial advice.

It is not production trading software.

But it works as a real example of a better pattern:

Do not give an AI agent a huge API and hope it behaves.

Give it a small job, clear boundaries, and a human approval gate.

Final thought

Letting Claude Code control a crypto exchange API sounds reckless.

And it would be reckless if the workflow was:

Give it keys.
Give it docs.
Tell it to trade.
Hope nothing breaks.

That is not what I built.

The workflow I want is:

Give it a scoped skill.
Limit the key.
Start read-only.
Dry-run first.
Redact secrets.
Ask for confirmation.
Let the human decide.

That is the difference.

The future of AI agents is not just about making them more autonomous.

It is about knowing where autonomy should stop.

Building safer AI-agent workflows for the MEXC trading platform API

mrcnm — Wed, 10 Jun 2026 11:34:12 +0000

I’ve been working on a small open-source repo for AI-agent workflows around the MEXC API.

The project is not meant to be a “trading bot.” The goal is more specific: to give coding agents like Claude Code, Codex-style agents, and similar tools a safer structure for working with live exchange API workflows.

The first implementation is for MEXC.

GitHub repo:

https://github.com/mncrftfrcnm/mexc-agent-trading-skills

What the project is

This repo contains experimental skills/prompts for AI coding agents that work with MEXC API workflows.

The skills are split into four main areas:

MEXC Spot REST
MEXC Spot WebSocket
MEXC Futures REST
MEXC Futures WebSocket

Each skill gives an agent a smaller, focused set of instructions instead of making it read a large API reference every time. The repo also includes helper scripts, endpoint recipes, WebSocket notes, and safety rules for handling credentials and live actions.

In simple terms, the skills can help an agent:

query public market data
check account information, such as Spot or Futures balances
see available tokens/assets in an account
build signed REST requests
use local API credentials from environment variables
use dry-runs before sending live requests
use Spot test orders before live Spot orders
work with WebSocket streams for market data, order-book updates, and account/order events
avoid printing API keys, signatures, listen keys, or private account data

The main idea is to make unsafe behavior harder by default.

Why I made it

Coding agents are useful when working with APIs, but live trading APIs are different from normal developer APIs.

If an agent makes a bad request to a normal test API, maybe the request just fails. If it makes a bad request to a trading API, it could place an unwanted order, cancel something, change account or position settings, expose credentials, or leak private account data into logs.

That is the problem this repo is trying to reduce.

The project focuses on safer defaults:

use local environment variables instead of asking users to paste API keys into chat
prefer dry-runs and read-only requests first
require explicit confirmation before live authenticated write requests
redact sensitive values in dry-run output
separate Spot and Futures workflows
separate REST and WebSocket workflows
clearly mark experimental areas, especially Futures live-order workflows

Repo structure

The repo includes compatibility layouts for different agent environments.

For Claude / Claude Code / Claude Desktop, there are Claude-ready skill folders.

For Codex-style repository agents, there is a separate Codex-oriented layout.

The main skills are:

mexc-spot-rest
mexc-spot-websocket
mexc-futures-rest
mexc-futures-websocket

The REST skills include local helper scripts for request construction and signing.

The WebSocket skills include workflow notes for public streams, private streams, reconnect behavior, listen keys, order-book updates, and handling sensitive stream data.

What the Spot REST skill includes

The Spot REST skill focuses on one-off REST API workflows, including:

public market data
server time
symbol and exchange information
signed account reads
balance checks
Spot test orders
order lookup
signed request construction
dry-run output with sensitive values redacted

The helper script is designed so an agent can construct and sign requests without manually rebuilding the signing process every time.

What the Spot WebSocket skill includes

The Spot WebSocket skill is for live Spot streaming workflows.

It includes guidance for:

public trade streams
ticker and depth streams
protobuf-based public messages
listen-key based private streams
account and order updates
reconnect behavior
local order-book recovery
avoiding listen-key exposure in logs

This is meant to give an agent a clear workflow for streaming data instead of mixing WebSocket logic into normal REST tasks.

What the Futures REST skill includes

The Futures REST skill focuses on Futures API workflows, including:

public contract data
contract details
server status
account assets
position information
signed Futures requests
contract metadata checks
precision and leverage-related information
safer request patterns for live workflows

Futures live-order support is still treated as experimental. The repo keeps warnings around Futures private write endpoints because endpoint availability, permissions, and maintenance status can vary.

What the Futures WebSocket skill includes

The Futures WebSocket skill is for live contract market data and private Futures events.

It includes guidance for:

public contract streams
tickers, deals, depth, funding, and price-related streams
private account, order, and position streams
ping/pong behavior
reconnects and resubscriptions
order-book recovery from snapshots
redacting private authentication payloads and account data

What is currently tested

The repo currently includes self-tests for the Spot REST and Futures REST request-signing helpers.

The CI workflow also:

runs the Spot REST helper self-test
runs the Futures REST helper self-test
compiles the Python files
runs gitleaks secret scanning
runs TruffleHog verified secret scanning

That means the repo already checks the local helper scripts, Python syntax, and basic secret hygiene in CI.

Current project status:

Spot REST helper signing: self-tested
Futures REST helper signing: self-tested
Python files: compile-tested
Secret scanning: included in CI
WebSocket workflows: documented and structured as agent skills
Live trading workflows: guarded by confirmation rules and warnings, not claimed as production-ready

Safety model

The repo is designed around the idea that agents should not casually perform live trading actions.

By default, the helper scripts prefer dry-run behavior. Authenticated live non-GET requests require explicit confirmation flags. Sensitive values such as API keys, signatures, and listen keys are treated as private and should not be printed or stored in logs.

The project also recommends:

dedicated API keys for this project
disabled withdrawal permissions
IP restrictions where possible
minimum required API permissions
small test sizes if live testing is ever done
reviewing every symbol, side, order type, price, quantity, leverage, and account type before any live action

Important disclaimer

This project is unofficial and not affiliated with MEXC.

It is not financial advice, investment advice, trading advice, or a recommendation to buy, sell, or hold any asset.

Live trading APIs can affect real balances, orders, and positions. This repo is meant for developer experimentation and structured agent workflows, not unattended live trading.

GitHub repo:

https://github.com/mncrftfrcnm/mexc-agent-trading-skills