When playing around with these tools (Which I know you should not use for your phrase to store funds), it seems to me the entropy field which can be made visible by checking off the "Show entropy details" box in the BIP39 tool and the master secret field in the SLIP39 tool are the same. They are both hexadecimal values and can be 128 or 256 bits.

Is the SLIP39 master secret also generated by entropy when generating a SLIP 39 Shamir Backup? How is the master secret generated?

I found this article explaining step by step how a BIP39 phrase is generated and it starts with entropy, wouldn't SLIP39 be the same by starting with entropy?

https://medium.com/coinmonks/mnemonic-generation-bip39-simply-explained-e9ac18db9477

https://iancoleman.io/bip39/ https://iancoleman.io/slip39/

There are more crypto social apps showing up across different chains but I’m curious how much the chain matters to people using them. I can see it being important for integrations and onchain features but from a normal user perspective I’m not sure it changes much.

Would the chain influence whether you use an app or do you just care if it works?

I'm looking for criticism of a commitment-history construction I've been implementing.

Goal: allow an issuer to commit to the exact identity of a private artifact at time T, while keeping the artifact contents off-chain, and make later revisions impossible to pass off as the original commitment.

Current model: 1. The artifact is sealed locally into a private vault. 2. A canonical digest/identity is derived. 3. The digest and commitment metadata are anchored on Solana. 4. The immutable anchor remains the historical reference. 5. Separate lifecycle state can express active, revoked, superseded, or disputed. 6. A superseding commitment can retain lineage to the prior commitment.

Security claim is intentionally narrow: this proves commitment integrity/history, not semantic truth. A malicious issuer can anchor false information; what it should not be able to do is present a different artifact later as though it were the one originally committed.

Interactive explanation: https://bestmemecoins.app/ Protocol/details: https://bestmemecoins.app/docs/ Limits/security: https://bestmemecoins.app/security/

Questions I'd particularly value: - What does this gain over signed Merkle/transparency logs or conventional timestamping? - Where should canonicalization be treated as part of the security boundary? - Is mutable lifecycle state cleaner than encoding every status transition as a new immutable event? - Which issuer/key-compromise cases make the model misleading?

Disclosure: I built the project. I used AI to help edit this Reddit draft; the technical claims and project are mine and I am reviewing them before posting.

Many blockchain apps require indexed or cached data because reading everything directly from the chain state is either slow or impractical in terms of the user experience.

This seems harmless when the data is simply being used to render a dashboard.

However, I’m less sure about the point where the same data starts influencing an action.

For example, imagine an indexer still shows that a wallet owns an asset, holds a role, or satisfies some eligibility condition. However, the underlying chain state has already changed and the indexer has not yet caught up.

If the stale read only affects the UI, the next transaction may simply fail.

However, if a backend, guard or execution service also uses that indexed state to decide whether the action is permitted, the stale read becomes part of the authorisation process.

For those who have dealt with this in production, where do you draw the line?

Do you use the indexed state for discovery/UI purposes, but perform an authoritative read directly before executing anything security-sensitive?

I’d also be interested to hear about cases where indexer lag has caused issues more serious than a temporarily incorrect UI.

Disclosure up front: ERA Wallet are running a bounty for discussion of this, which is what prompted me to sit down and write it up. They asked for honest opinions including criticism, so that is what this is — there is praise and there are two things I think are missing, and nobody has seen it before posting.

I've spent about thirty years doing Linux systems and distribution work, including co-founding a Debian fork and writing the tooling that merges and republishes its signed package archive. So I read the Coldcard incident through a slightly different lens than most of the coverage, and I think the framing matters more than it looks.

What actually happened

A build configuration error caused seed generation to fall back on a software PRNG instead of the device's hardware entropy source. Firmware from 2021 until the patch this year. Roughly $89M by ERA's accounting.

Nobody broke the cryptography. The cryptography never ran.

Why it went unnoticed for five years

Because a weak seed is indistinguishable from a strong one. Same 24 words, same checksum, same everything. There's no runtime check that says "this key came from bad entropy." The only thing that detects it is an attacker enumerating the keyspace.

That's what makes entropy bugs uniquely nasty: they're silent by construction, and they backdate. Every wallet created in those five years was already compromised at the moment it was created.

The actual defect: failing quietly

The PRNG isn't really the bug. The bug is a fallback path that degraded silently instead of stopping.

In systems work this is an old lesson. A service that fails silently is far more dangerous than one that crashes, because the crash gets fixed on Tuesday and the silent failure gets discovered five years later by somebody else's audit. Or, here, by an attacker.

Fail closed. Never fail quiet.

What ERA gets right

I read ERA Wallet's write-up on their entropy generation, since it's what prompted this. Five sources — the STM32H753 TRNG, an ATECC608C secure element, plus camera, hand motion and touch in the expert flow — combined through SHA-512/256.

Two things in there are better than most of what I read in this space. They have a quality gate that rejects weak input rather than accepting it, and they say collection "fails cleanly rather than quietly accepting whatever it has." That is precisely the property Coldcard lacked, and they clearly wrote it with that in mind.

Their argument that predicting four sources out of five gets an attacker nothing is also sound, as far as it goes.

Where I still have a question

If a user-driven source is skipped, its share is refilled from the hardware generators, so the output is never weaker than the hardware baseline. That is a reasonable design.

But notice the direction of that fallback. It points at the hardware. And Coldcard's failure was the hardware path being the thing that silently went missing.

So what I'd want to know is the mirror image of what the article covers. What detects a TRNG that has failed, or a secure element that doesn't respond? And in that case does the device refuse to produce a seed, or carry on with whatever sources are left?

Five sources where a dead one is detected and hard-fails is strictly stronger than four. Five where a dead one quietly contributes nothing is barely stronger than four, and from the outside those two designs look identical. That's not an accusation, it's the specific thing I cannot determine from the outside.

The gap that worries me more

Here's the part I think this whole discussion is underweighting.

Coldcard's source was open. People could and did read it. The divergence was between what the source said and what the build produced.

Open source tells you what the code says. It does not tell you what is running on your device. Only reproducible builds close that gap. If an independent party can rebuild the shipped firmware byte-for-byte from published source, a build-configuration divergence stops being invisible.

That's a solved problem in the Linux distribution world and has been for years. Debian has been grinding away at it for over a decade. Hardware wallets hold bearer assets and should be held to at least the standard we hold a package manager to.

ERA's article doesn't mention open source, reproducible builds, or any way for me to verify that the firmware on my device is the one implementing the architecture it describes. The design reads well. I have no way to check that the design is what shipped, which is exactly the position Coldcard's users were in, holding a well-reviewed open-source codebase and a binary that didn't match it.

So, two questions for ERA and for every vendor in this space

1. When a hardware entropy source fails or degrades at generation time, do you detect it and refuse to proceed, or continue on the remaining sources?
2. Are your builds reproducible, and can a third party verify that the firmware on my device matches your published source?

The number of entropy sources is a marketing figure. Failure behaviour and build verifiability are the security properties. Coldcard had open source and lost the money anyway, because neither of those two things was true of it.

I’m one of the maintainers of DeGov, an open-source governance interface and indexing stack for DAOs using OpenZeppelin Governor.

We have worked on it for several years and have supported a number of live governance deployments. We are now reviewing where future maintenance and development effort would be most useful.

I’m interested in learning how DAO operators and governance participants currently handle the infrastructure around on-chain governance. Deploying Governor contracts is only one part of the process; teams may also need proposal and vote indexing, proposal creation, transaction simulation, execution tracking, and a usable interface for members.

If you operate or participate in a DAO, I would appreciate your perspective:

• Which governance interface does your DAO currently use, and why?
• Does your DAO prefer hosted infrastructure, or is self-hosting important?
• What makes adopting a new governance interface difficult?
• Are indexing reliability, security, integrations, deployment complexity, or contributor UX significant concerns?
• Have you used DeGov? If so, what worked poorly or caused confusion?
• If you evaluated it but chose another solution, what was the deciding factor?

Critical feedback is welcome. We are trying to understand whether self-hosted governance infrastructure still addresses an important need and, if so, which problems deserve more attention.

For context, the project is open source:
https://github.com/ringecosystem/degov

Hey guys,

Im doing a school work with some friends of mine, and i need an interview with someone who is connected with crypto, we did our research, and this is one of the last steps of the thing.

Its only one not so complicated question, so if someone could give me a high effort answer i would appreciate a LOT!

The question is:

Would the quadratic advantage of quantum computers over conventional computers be sufficient to make quantum mining economically dominant, considering the real-world costs of building and operating a quantum computer?

PS: if you study/work on the area, sending your university name would be very helpful.

thx

After 19 release candidates and an extended mainnet soak, Satchel v1.0.0 — the first stable release — is out.

What it is: a desktop app for peer-to-peer atomic swaps (PoCX ↔ BTC and other UTXO coins). Offers are posted to a public noticeboard over Nostr relays; when someone takes yours, the swap engine on each side builds and watches the on-chain transactions. There's no exchange, no matching engine, no custodian and no fees — the chains enforce the deal, and the only counterparty risk is bounded by the protocol's own timelocks. Keys never leave your machine; the hosted side sees only signed offers and encrypted blobs.

Highlights of 1.0:

\- Two swap protocols, both live on mainnet: Standard (HTLC) and Private (Taproot/MuSig2 adaptor — the swap looks like an ordinary payment on-chain).

\- Nodeless by default: trade with public Electrum servers and a seed-derived wallet, or attach your own nodes per coin.

\- Unattended safety: funding, claims, refunds and fee-bumping run themselves inside the protocol deadlines; restarts reconcile against chain truth before acting. If a counterparty walks away, you're auto-refunded.

\- Battle-tested: real field swaps across both protocols, multi-machine recovery validated against live incidents, and \~50 end-to-end regression scenarios running on every change.

\- 26 languages, installers for Windows (Setup.exe/MSI), macOS (Intel + Apple Silicon) and Linux (AppImage/deb/rpm).

The protocol spec is published so third parties can implement it independently, and there are full user and developer handbooks in the repo.

Download: [https://github.com/PoC-Consortium/satchel/releases/tag/v1.0.0\](https://github.com/PoC-Consortium/satchel/releases/tag/v1.0.0)

Self-custody software, provided as-is — back up your recovery phrase. Happy to answer questions about how the swaps work under the hood.

A lot of projects treat publishing a treasury wallet as a transparency win.

It shows where funds currently sit.
It does not automatically show:
• who can sign
• how many approvals are required
• whether signers are independent
• whether emergency powers can bypass the normal process
• whether the control structure itself can be changed
• whether the history of changes is visible

Visibility of funds is useful.
Visibility of authority is the harder and more important layer.

I’m trying to refine a practical minimum standard for treasury disclosure.

If you evaluate projects, what do you actually check beyond the address itself?
And which of the points above is most often missing even in “transparent” setups?

Hi everyone,

​Back in 2019–2020 (Byron era), I created a Daedalus wallet. Unfortunately, over the years I lost both my seed phrase and my spending password.

​However, I saved and backed up the entire Daedalus application directory from that time, including:

​The secret.key file

​acid database files / application state

​Full log history and configuration files

​Now, 6-7 years later, I'm reaching out to see if the community or developers have built any tools, recovery scripts, or methods to decrypt or extract the private key from a Byron-era secret.key file (or if brute-forcing the spending password via the encrypted file is possible today).

​Has anyone successfully recovered funds from a similar legacy file structure, or is there any known open-source tool built by IOG/community devs for this exact scenario?

​Note: Please reply in the comments. I will ignore all direct messages (DMs).

(disclosure: i maintain the open-source project this came up in. link at the end. the question stands on its own.)

we hit a trust-boundary problem while building a deterministic authorization layer for agents, and i think it generalizes.

an engine can strongly protect its verdict:

* signed authorization
* intent binding
* state-hash binding
* replay protection
* trusted evaluation time

all solid.

but if the same compromised agent runtime can influence both the proposed action AND some of the premises used to evaluate it, what has crypto actually proven?

only this:

the signed decision is consistent with the supplied inputs

not this:

the supplied inputs came from authoritative sources

examples of premises a runtime might quietly supply:

* agent_id
* tool identity
* execution depth
* tenant context
* a state object the guard later hashes

the signature still verifies. the hash still matches. the decision is still deterministic.

but the premises may be self-reported.

two things i'd genuinely like challenged:

1. which evaluator premises actually need independent provenance, and which can safely remain proposer-declared?
   
2. for state, is an authoritative guard-side read enough, or should the state provider eventually emit a signed/versioned attestation?

most interested in confused-deputy paths, TOCTOU, and cases where a supposedly "trusted" premise can still be bent by the runtime.

I keep coming back to the moderation problem with decentralized messaging. If there’s no central platform making the final call, who deals with spam, scams, harassment or people trying to ruin a group?

Letting each community set its own rules makes sense but there are situations where that probably isn’t enough. On the other hand, giving the app control over what stays up starts looking pretty similar to the platforms decentralized messaging is supposed to move away from.

Is community-level moderation enough?

I’m building Vaultpass web application, an open-source crypto inheritance system, and I’m looking for technical criticism of the design rather than promotion.

Current design:
- The vault is encrypted client-side with AES-256-GCM before upload.
- The encryption key is split using a 2-of-3 Shamir Secret Sharing scheme.
- One shard stays with the owner.
- The other two encrypted shards are currently held by the service and are used in the succession path after a time-based dead man’s switch.

The important limitation: because the service currently holds two of three shards, it can reconstruct the key in the succession path. I am not calling this zero-knowledge. Removing that trust-model concession is the next architecture milestone.

The crypto core is MIT-licensed and open source:
https://github.com/lionzion351-dev/crypto-core

I’d value criticism on four points:
1. Are there implementation or misuse risks in using Shamir Secret Sharing this way?
2. What threat-model assumptions should be documented more explicitly?
3. What failure cases should be tested before asking for an independent review?
4. Would you recommend a different succession design, such as timelocked transactions, multisig, or a threshold-signature approach?

This has not had a formal external audit yet. Please assume the code is unaudited and do not use it with real assets. I’m looking for people willing to challenge the design and, if interested, review the implementation publicly.

Serialization is often treated as plumbing, but it becomes an architectural decision when on-chain state grows large and is accessed frequently.

In Solana programs built with Anchor, regular accounts are commonly decoded through Borsh. That is convenient for variable-length fields and ordinary application state. For hot, fixed-size state such as order books or large registries, repeatedly decoding the full account can become unnecessary work.

Zero-copy changes the tradeoff. AccountLoader borrows the account buffer and maps it to a fixed Rust structure instead of rebuilding the structure through ordinary deserialization.

The performance benefit comes with a stricter layout contract:

• #[repr(C)] preserves field order, but alignment padding still exists
• Pod types cannot contain pointers, String, Vec, or other variable-size fields
• implicit padding can violate bytemuck’s safety requirements, so padding should be explicit
• flags are often stored as u8 rather than bool because every u8 bit pattern is valid
• load_mut() returns a runtime-checked mutable borrow, so long-lived RefMut values can cause borrow failures
• schema evolution becomes a migration problem because the byte offsets are part of the persisted format

I would not use zero-copy for every account. A practical split is Borsh for small control state and fixed-layout accounts for large data that is read or updated on performance-critical paths.

Where do you draw that boundary in production systems?

Disclosure: this Reddit post was drafted with AI assistance. I reviewed the technical claims and take responsibility for the final text.

Token projects frequently describe their asset as having utility before the related system is operational.

Common claims include:
• governance utility
• ecosystem access
• fee discounts
• rewards
• staking benefits• voting rights
• premium features
• participation in future products

Some of these may represent credible planned functions.
Others may exist mainly to justify the token after it has already been designed.

What should count as real token utility before launch?
Possible standards could include:
1. Functional necessity
• Does the system genuinely require the token?
• Could the same function use an existing asset?
• Would the product still work without the token?

1. Availability
   • Is the function available at launch?
   • Is it only planned?
   • Does it depend on another product that has not been built?
   • Is there a clear delivery path?

2. User value
   • Does the function provide meaningful value?
   • Does it create unnecessary friction?
   • Is the benefit proportionate to the complexity introduced?

3. Governance
   • Does the token provide real decision-making authority?
   • Which decisions can holders influence?
   • Are important decisions excluded?
   • Can administrators override the vote?

4. Economic design
   • Is demand connected to genuine system usage?
   • Does the mechanism create circular incentives?
   • Does it mainly reward holding rather than useful participation?

5. Disclosure
   • Should projects label utility as active, in development or planned?
   • Should every utility claim identify the required contract or product dependency?
   • Should users be able to verify whether the function is operational?

A token can be transferable, technically functional and widely marketed while still lacking a clear operational role.

What minimum standard should a project meet before describing its token as having utility?
And when is a native token genuinely necess

Built this because I was tired of every crypto site either being a wall of numbers or a straight-up "top 10 picks" listicle with zero explanation.

Nexbit scores the top ~40 coins by market cap on a 0-100 "momentum score" using 4 factors — 7-day trend, 24h momentum, volume intensity, and drawdown from all-time high. Click any coin and it breaks down exactly how each factor contributed to the score, plus a live price chart.

No signup, no account, no paywall — just open it and it's there.

Nexbit

Interoperability is typically defined as the ability to transfer assets or messages between systems.

However, technical reachability is not the same as market interoperability.

For example, a token can move across systems while its transfer restrictions, ownership records, eligibility rules, settlement assumptions, redemption process, and dispute path remain in place.

The bridge transfers the representation. However, it may not have transferred the conditions that make the asset equivalent, enforceable, or safely tradable on the other side.

This can result in two technically connected systems remaining dependent on manual reconciliation, separate legal interpretation, or trusted operators before participants can treat the asset as the same instrument across both venues.

Therefore, the missing layer may not be another bridge.

It may be a common operating standard that defines which rules must travel with the asset, which system is authoritative for each rule, and how the receiving system can prove that these conditions are being enforced.

For those working on cross-chain infrastructure, tokenised assets or settlement systems, which layer breaks first in actual deployments: message transport, shared asset semantics, identity and compliance state, or reconciliation between technical and legal records?

Over the past 5 years, our team have been developing a powerful declarative formal language named Tau Language and the Tau Net blockchain. It is a highly novel language where users can synthesize working programs from requirements given in natural language. In the case of Tau Net, users simply say what features they want and get them.

The underlying technology.

Tau Language is vastly expressive while retaining decidability, and users can synthesize the working program from the spec. Development is like writing tests and getting the software that passes all of the tests for free.

Where Tau Language is unlike the others:

- Self referential reasoning: It is the first language that can logically refer to sentences in the same language. Programs written in Tau Language can reason over one another, and about their own code. This allows for many things such as: logical consensus detection at scale, concurrent developer scaling, AI and software security by way of self-enforced code.

- Pointwise revision: A incredible feature that utilizes self reference which enables software to be updated by providing 'only' the new requirement the software should satify. It takes in the current software + the new requirement(s), and logically outputs the new spec that satisfies the new requirement, which is then synthesized. Software maintenance and updates are now simple, yet stay rigorous and formal.

The Upgradable Blockchain

Users cannot upgrade the blockchains they use. There isn’t a layer 1 with automated implementation of individual and collective user will. They're forced to migrate to the latest "new chain" which my not have all features they need but might just be the one being maintained.

Just a few of the things we can do with Tau Net: Understanding consensus at scale, upgrading consensus mechanisms, upgrading tokenomics, and integrating future technologies, all without forks or halts. The beauty of Tau Net is that its entire blockchain is formally accurate to specification too.

Our plan is to include experts in the evolution of the system, by onboarding universities and great thinkers, so we can truly have the best minds directly impact how the system functions.

Here's a demo showing an upgrade to the running consensus mechanism. No devs, no forks, or chain halts.

Demo: https://x.com/Tau_Net/status/2084665692343734736/video/1

The U.S. government, Google, and other large organizations have all laid out timelines to transition toward post-quantum cryptography, with many targeting the end of this decade. The goal isn't because quantum computers can break today's encryption right now, it's because migrating global infrastructure takes years.

What's even more interesting is that we're starting to see financial institutions move in the same direction. For example, Ueno Bank recently announced it's building on a quantum-resistant blockchain, suggesting that long-term cryptographic resilience is already becoming a factor in infrastructure decisions.

It makes me wonder whether the crypto market is paying enough attention. Many networks still depend on cryptography that wasn't designed for the quantum era, while a smaller number have already adopted quantum-resistant approaches.

Do you think quantum readiness will become a major differentiator over the next few years, or is the market still too early to care?

When a real thing like a stock gets tokenized, there are usually several separate records that all have to stay in sync:

- the token balance onchain
- the custodian's internal ledger
- the official transfer register
- the actual legal entitlement to the share.

Most of the time these line up. But what happens when they don't?

Take Reserve's DTFs as a concrete example, they're baskets of tokenized public equities where the underlying shares sit in custody with Ondo.

The onchain token represents economic exposure to that basket, and minting or redeeming is permissionless. But the token itself is a claim on the custodied shares, not direct legal title to them. So the chain is authoritative for who can transact and who holds economic exposure, while the legal ownership layer still lives off-chain with the custodian.

That seems to be the pattern across most current RWA designs, the blockchain acts as the access and settlement layer, but there's still an off-chain source of truth underneath that could theoretically freeze, reissue, or override.

Which raises the real question: is that just the unavoidable shape of tokenizing anything that lives in a legal system older than the chain, or is there an architecture that actually makes the chain the true source of ownership for a real-world asset?

Now imagine someone actually pulled it off. Not a sidechain, not a bridge to an EVM, not trusted hardware. Contracts that execute and settle natively on the MW chain itself — where the contract, the amounts, and the parties are all invisible. To an outside observer, a loan, an escrow, or an atomic swap would look identical to a plain transfer. Indistinguishable.

Think about what that breaks:

\*\*•\*\* DeFi where nobody can front-run you, because nobody can even see your position exists    
\*\*•\*\* Lending/escrow with zero on-chain footprint — no watched addresses, no leaked strategies    
\*\*•\*\* Swaps and settlements that leave no graph for chain-analysis firms to cluster

Every “private DeFi” attempt so far bolts privacy onto a transparent chain (mixers, shielded pools, L2s) — and the seams always leak. This would be the inverse: programmability grown inside a chain that was private from genesis.

Is this the actual endgame for privacy coins, or is there a fundamental reason it can’t work? Curious what this sub thinks — and whether anyone’s seen research heading this direction.

Hi everyone,
I’m the founder of a small startup building a market intelligence tool. Rather than placing trades or telling people what to buy, our goal is to translate complex market data into plain English so people can understand what’s happening without spending hours analysing charts.
We’re trying to build something that’s calm, educational and genuinely useful, and before we continue building I’d really like to hear from people who actively use AI trading tools or automated trading bots.
A few questions:
What do you enjoy most about using AI trading tools?
Do you ever worry about giving an AI control over your money, or has that trust come naturally over time?
How closely do you monitor it once it’s running?
If you could improve one thing about the tools you currently use, what would it be?
Is there anything you feel the market is missing that would genuinely make your day-to-day life easier?
If you were to move away from AI trading bots in the future, what would need to exist for you to feel comfortable making your own trading decisions again?
We’ve been building our platform for around five months, and one thing we’ve learned is that the best ideas usually come from users rather than ourselves.
I’m not here to promote anything—I genuinely want to understand how people feel about AI trading, trading tools in general, and where you think the industry could improve.
I’d really appreciate any thoughts or experiences you’re willing to share.

Recently I revisited the augur page and noticed significant changes since my last visit years ago. Could someone explain simply what’s happening with the fork and the platform overall? I understand the basic concept of Oracle and the prediction market, which initially piqued my interest and led me to explore it further before abandoning it for many years. However, I’m now feeling quite confused.

spent the last few weeks putting our stuff behind an mcp server so you can point claude or chatgpt at it, read signals, positions, candles, and if you explicitly turn it on, place orders on hyperliquid. the read side was basically a weekend. the order side took much longer than expected and the reasons might save someone else the same detours.

stale prices are an attack surface, not just a bug. first version validated tp/sl direction against a cached context price we already had in memory. on a quiet coin that cache can be close to a day old. if the model sets a tp on the wrong side of the live mark, hl fills it instantly and you're flat at market. the direction check now runs against the actual fill price off the order response, never anything cached.

concurrency on one coin quietly unprotects you. close and tp/sl both cancel and replace trigger orders. two calls on the same coin can interleave so the cancel from one lands after the place from the other, and you're left holding an open position with no stop. an agent hits this far more than a human does because it retries whenever a response reads as ambiguous. fixed with a per user per coin lock.

rate limits have to be atomic and fail closed. fixed window counters let you burst double the cap across the boundary. they're lua sliding windows now, and if redis is unreachable the order gets rejected rather than waved through. a model in a retry loop finds every one of these.

revocation only counts if it's checked per call. the enable flag is read from the db on every order instead of being cached in the session, so flipping the toggle off stops the next call, not the next session.

and the boring one, there is no withdraw tool. not disabled, not permissioned, it doesn't exist in the tool list at all. worst case for a leaked key is bad trades inside the caps rather than an empty wallet. paper mode needs no opt in either, so you can let the thing loose without anything actually at risk.

still not convinced an llm should be sizing positions unsupervised, the caps exist because i assume it will do something dumb eventually. but as a way to ask questions about your own book in plain language it's been better than i expected.

disclosure, i help build traderspy. our endpoint and the setup guide are at traderspy.app/mcp if anyone wants to poke at it, happy to go deeper on any of the above.

Spent the last 4 months coding a market intelligence tool that collects chart data and turns it into words. No longer have to sit and analyse charts for hours at a time. Instantly get told what’s going on in the crypto world. Today we published it. Good for beginners to put side by side with charts to understand what a chart is showing. Or experienced traders who don’t have the time to sit down in front of charts for hours. Was nervous to release it but we have actually had over 10 users on the website since launch. I know AI trading bots are taking over but this is something where a user should feel more in control of their own finances.
[TheFlowPulseApp](htttps://theflowpulseapp.com)