Hey everyone,

​Over the past few months, I’ve been working on optimizing execution speed for high-volume, time-sensitive transactions on Solana (specifically around bonding curve events).

​In standard architectures, sequential RPC calls to fetch token/account state create noticeable latency tails (3.5s to 8s) during network congestion. To eliminate this bottleneck, I re-engineered the pipeline to handle state triggers asynchronously without relying on hot-path RPC reads.

​Here are the core architectural changes:

​Zero Hot-Path RPC Reads: Capturing state updates directly via high-frequency WebSocket streams (BC state watcher) rather than polling RPC nodes during execution.

​Sub-Second Execution Pipeline: Directing transactions via Jito MEV pipelines with parallelized execution paths to ensure predictable block placement.

​Pre-Execution Filtering: Evaluating mint authority, holder concentration, and liquidity metrics in real-time before pushing the order payload.

​I’m curious to hear how other devs here handle RPC latency tails during high-volume liquidity events on Solana. What are your thoughts on bypassing hot-path reads via direct WebSocket state vs. dedicated gRPC setups?

​Looking forward to discussing the technical trade-offs!

Every chain's account model assumes a human: one signer, one seed phrase, block times you can wait out, multisig where the signers can get on a call. Agents get a hot wallet and a prayer — one prompt injection away from drained.

We've been building Fluidic, an EVM-compatible L1 research testnet that starts from the opposite assumption. A few design decisions that fall out of that:

- Witness-gated accounts in consensus (CAE). An agent's spend only executes if N-of-M witnesses attest *in the same tick*. Not a multisig contract — the gate is enforced by the same ordering layer that settles the transfer. An agent with a leaked key still can't move funds alone.

- Native intents. The agent declares an outcome ("swap X for at least Y"), solvers compete to fill it, and matching + settlement happen in the same ~100ms synthesis tick. No block-space auction for searchers to prey on.

- Continuous execution. No blocks. Commutative operations merge in parallel through NTT windows, stateful operations order themselves via vector clocks. Roughly 10 settlement ticks per second instead of one block every 12 seconds — machine-speed finality for machine-speed actors.

What's live today: run a node from a public Docker image, faucet, native transfers/swaps, full Ethereum JSON-RPC for existing tooling, TS SDK.

- Docs: https://testnet.fluidic.foundation/docs

- Explorer: https://testnet.fluidic.foundation/explorer

- Node repo: https://github.com/Fluidic-Foundation/Fluidic-FVM

- SDK: https://www.npmjs.com/package/@fluidic-foundation/sdk

Early research testnet — state may reset, no real funds, known rough edges. What I want from this sub specifically:

1. Does witness-gating at the consensus layer actually close the agent-custody hole, or does it just move trust to the witness set?

2. Is per-tick intent matching a real MEV mitigation, or does extraction just move to the solver layer?

3. What would you need to see benchmarked before taking a continuous (non-block) execution model seriously?

Lately, I see many projects claiming “full transparency” simply because they publish a wallet or a contract address.

But transparency feels more nuanced than that.

A wallet address shows where funds are — not why, under which rules, or what can happen next.

So I’m curious how others here define it in practice:

Is transparency about immutability of rules rather than visibility?

Does it require clear documentation of edge cases (pauses, withdrawals, failures)?

Or is it more about verifiability over time, not just a snapshot?

Interested in perspectives from builders, auditors, and long-time users. What standards do you actually trust — and which ones are mostly cosmetic?

After several weeks of continuous testing, we've decided to move the Chipcoin testnet Post-Quantum activation from block 30,000 to block 20,000.

The decision wasn't made to rush development—it was made because the implementation has reached the level of stability we were looking for.

During the past development cycle we've completed:

• Full ML-DSA (FIPS 204) integration
• New CHCQ post-quantum address format
• Mixed legacy/PQ transaction support
• Browser wallet compatibility
• Explorer PQ support
• Interoperability testing
• Stress testing
• Protocol audit
• Operational readiness checks
• End-to-end dress rehearsals

With these milestones completed successfully, we believe there's little value in waiting another 10,000 blocks before beginning real network testing.

⚠️ Required upgrade

Anyone running a Chipcoin testnet node or miner should upgrade before height 20,000.

Typical update:

git pull
docker compose build --no-cache
docker compose up -d

or for source installations:

git pull
pip install -e .

Then verify:

chipcoin verify-pq-activation

Expected values:

• Testnet activation: 20000
• Devnet activation: 30000
• Software version: 0.1.2

Nodes remaining on the old activation height (30,000) will eventually diverge from the updated testnet once post-quantum transactions become valid.

As always, feedback, testing and new node operators are welcome.After several weeks of continuous testing, we've decided to move the Chipcoin testnet Post-Quantum activation from block 30,000 to block 20,000.
The decision wasn't made to rush development—it was made because the implementation has reached the level of stability we were looking for.
During the past development cycle we've completed:

Full ML-DSA (FIPS 204) integration

New CHCQ post-quantum address format

Mixed legacy/PQ transaction support

Browser wallet compatibility

Explorer PQ support

Interoperability testing

Stress testing

Protocol audit

Operational readiness checks

End-to-end dress rehearsals

With these milestones completed successfully, we believe there's little value in waiting another 10,000 blocks before beginning real network testing.
⚠️ Required upgrade
Anyone running a Chipcoin testnet node or miner should upgrade before height 20,000.
Typical update:
git pull
docker compose build --no-cache
docker compose up -d
or for source installations:
git pull
pip install -e .
Then verify:
chipcoin verify-pq-activation
Expected values:

Testnet activation: 20000

Devnet activation: 30000

Software version: 0.1.2

Nodes remaining on the old activation height (30,000) will eventually diverge from the updated testnet once post-quantum transactions become valid.
As always, feedback, testing and new node operators are welcome.

I run a cross-chain swap comparator that refuses to let users sign anything it can't fully verify: every transaction a provider returns gets its target checked against a per-provider contract allowlist, and on Solana the whole transaction is decoded first, lookup tables included, with every program required to be on the list. Last week that design got tested twice in production, and the way it failed is the interesting part.

Case one: a user's routine Solana swap got refused with "unrecognized program". Not a bug. The aggregator had switched its underlying DEX from one routing program to another (Jupiter to Magpie's router, as it turned out), with zero announcement. The transaction was almost certainly fine, but "almost certainly" is exactly what the allowlist exists to reject. We decoded the refused transaction, identified the new program, verified it against two independent sources including the DEX team's published deployments, and only then added it. Total downtime for that route: a few hours. Total funds signed against an unverified program: zero.

Case two, same week: another provider moved to an intents-based architecture, and their transactions started targeting the source token's own contract instead of their documented router. The allowlist blocked those too. That time we chose to keep showing the quote but strip the execution path until we've reviewed the new flow properly, because a blocked-but-visible route tells the user more than an error line.

What we changed after: refusals like these are now watched by a canary. Every six hours a cron re-quotes the sensitive pairs with real addresses and runs the returned transactions through the exact same inspection code the users get, then alerts on any drift: unknown program, off-list contract, dead pair. The key detail is that it exercises the production code path itself, not a parallel "monitoring" version that would rot.

Takeaways if you're building anything similar: aggregators change their internals without notice and that's normal, so an allowlist is a living thing, not a config file you write once. Hard refusal plus fast human review beats silent acceptance every time. And your monitoring should be a consumer of your real pipeline, or it will lie to you eventually.

Context: I'm the founder of the comparator in question (details in my profile), and both incidents are from the last seven days. Happy to go deeper on the inspection pipeline if anyone wants specifics.

Even if a blockchain system is executed exactly as designed, it can still produce an unintended outcome.

A smart contract follows its rules.

An oracle publishes the value it has received.

A solver selects a route permitted by the protocol.

A user signs the transaction presented to them.

While every individual component may behave 'correctly', the overall result can still be harmful, unfair or operationally unacceptable.

This becomes especially difficult when responsibility is distributed across code, governance, upgrade authorities, front ends, external data providers and users.

The transaction history shows what happened.

However, it does not automatically tell us who had the ability, obligation or authority to prevent it.

For those who have operated production systems:

When an automated process produces a technically valid but undesirable outcome, where should responsibility lie?

Is it with the person who designed the rules, the operator who maintained the system, the governance process that approved the parameters, or the user who authorised the final transaction?

Which controls have actually helped in practice: emergency pauses, bounded automation, delayed execution, human review, clearer transaction simulation, or something else?

I am especially interested in cases where the system did not technically “fail”, but the organisation still had to treat the outcome as an incident.

RWA apps are getting crowded, and I'm trying to understand what makes one technically trustworthy: custody, proof of reserves, redemption, liquidity, smart-contract risk, etc. Has anyone looked closely at metalsio or used it? What would you check before putting money into an RWA platform right now?

The issue with agents interacting with EVM chains is the constant need to track state changes through logs and events. An agent has to guess if a transaction will succeed based on a simulation, then watch the receipt to see if it actually got what it wanted. it's a lot of overhead for a bot.

Radix handles this differently by making assets first-class citizens in the runtime. In Scrypto, tokens aren't just rows in a third-party contract balance sheet. They are physical-like objects moved between vaults.

For an agent, this means it can define an instruction like "take 100 XRD from my account and swap it for at least 50 USDC." If the DEX can't meet that specific condition, the whole transaction fails at the protocol level. The agent doesn't need to parse complex logs to verify the result because the asset movement is the state change. It makes the feedback loop for autonomous logic much tighter.

Are there other networks that can become the agent settlement layer?

technical discussion, no product. i keep seeing "autonomous on-chain agents" framed as a model-quality problem, but in practice the model picking a trade is the easy 10%. the 90% that decides whether it's safe is the execution path between decision and settled tx. some failure modes i keep running into:

- state drift between decision and execution. the agent decides at block N, the tx lands at block N+k, and the pool/price/market has moved or closed. naive agents commit to a stale decision.

- silent tx failure. a dropped or reverted tx that the agent reads as success, so it double-acts or updates its internal balance wrong.

- funding/route failure. the intended path (bridge, LP, funding source) fails and the agent needs a deterministic fallback, not a retry loop that drains gas.

- unbounded blast radius. one hallucinated or adversarial decision with no per-action cap can nuke the whole balance in a single call.

the design tension i haven't fully resolved: the re-verify-before-commit check. deterministic guards in code (re-read state, assert invariants, hard caps) are safe but brittle and miss cases you didn't hardcode. letting the model decide when to re-check is flexible but occasionally skips the check under pressure. hybrid (model proposes, deterministic layer vetoes) seems right but adds latency that matters for time-sensitive actions.

for people who've shipped agents that touch real value on-chain: where do you draw the deterministic-vs-model line, and how do you handle the decision-to-settlement gap? genuinely looking for approaches i haven't considered.

​

I've been building on a chain called Paxeer and using an agent platform called Matrix. Most AI tools I've tried are glorified chatbots. This one actually does real things on chain.

Let me explain what it can do and why it matters.

Neo is an autonomous agent built by Paxlabs. It's not a chatbot with plugins bolted on. It has a wallet, it can read and write files, run code, browse the web, manage long running processes, and execute transactions on chain without me touching anything.

I can tell it "send 100 PAX to this address" and it does it. I can tell it "build me a React app" and it scaffolds the project, writes the code, and shows me a live preview. I can tell it "stake my tokens" and it handles the delegation, confirms the transaction, and gives me the hash.

That's not a demo. That's what it does every day.

The Paxeer network

Paxeer is an EVM chain (chain ID 125) with sub second block times and deterministic finality. It runs on a custom consensus called MachineRFT integrated with a SEI fork for parallel transaction execution.

The native token is PAX. The chain has its own block explorer (PaxScan), a price API, and full EVM compatibility so anything you can deploy on Ethereum works here too.

What makes it interesting for agents is the speed. When your bot needs to execute a trade or move funds, you don't wait 12 seconds for a block. It's near instant. That matters when you're running automated strategies.

LayerX and USDX

This is where it gets interesting. LayerX is the agent settlement layer on Paxeer. USDX is a USD denominated, escrow backed balance that settles off chain but anchors on chain.

Why does that matter? Because agents need to move money fast without paying gas on every transaction. With LayerX I can pay another agent instantly and gaslessly. The sequencer signs a receipt, batches the transactions, and anchors the Merkle root to Paxeer on a schedule.

So Neo can deposit USDL into the LayerX vault to fund its USDX balance, pay other agents by their DID (decentralized identifier), withdraw back to on chain USDL whenever it wants, and force settle the current window if I need immediate on chain finality.

It's like having a bank account for your AI that moves at the speed of software.

The King Bot system

I built a multi agent trading system on top of all this. Four bots, each with a different role:

King Bot is the commander. He reads a daily orders file I set, and pushes parameters to the other bots in real time. I can tell him "be aggressive today" and all the bots adjust their position sizes, stop losses, and entry thresholds instantly.

The Spotter freelances across pools looking for dips and big sells. The Alchemist watches my specific tokens and trades patient arbitrage. The Wild Card explores random strategies and learns from what the other bots do.

They all share an event bus. When one bot finds something, the others see it and decide whether to act. They learn from each other's wins and losses.

Performance is tracked with KPoints. Better bots get more capital. Worse bots get less. It's a self correcting meritocracy.

I literally gave my ideas and Neo started writing.

Most crypto AI projects are chatbots that tell you the price of Bitcoin. This is an agent that can actually operate on chain. It has custody of its own funds. It can execute multi step transactions. It can build and deploy software. It can manage other agents.

The whole thing is open source and you can dig into it here: https://github.com/Paxeer-Network give it a star!

The infrastructure is real and it's live right now. Paxeer is running. LayerX is running. Neo is running.

I'm not selling anything. I'm just sharing what I've been building because I think people in this space would find it interesting.

This is a pre-lease and I've been lucky enough to get in early.

This was written by Neo and edited by me. I don't want to act like I wrote this.

Most people call everything in their wallet a "coin," but a big chunk of those holdings are technically tokens. I sometimes think about where the assets live when looking at the difference.

• A coin is the native asset of its own blockchain. BTC on Bitcoin, ETH on Ethereum. It pays that network's fees and helps secure the chain.
• A token is created by a smart contract on top of an existing blockchain. It doesn't run its own chain - it borrows the security and settlement of the one it's built on.

That's why there are thousands of tokens and relatively few coins. Launching a coin means bootstrapping an entire network. Deploying a token just means writing a smart contract that defines the supply and transfer rules, then shipping it to a chain that already has wallets, exchanges, and users. The token inherits the neighborhood instead of building one.

Quick gut check - a token is not worse than a coin. It's an architecture choice. Coins power networks; tokens make those networks useful for specific jobs.

The main token types, grouped by what they're for:

• Stablecoin: tracks a stable value like the USD (yes, stablecoins are tokens)
• Governance: voting rights in a protocol
• Utility: access or a function inside an app
• Security: represents a regulated financial asset
• NFT: a unique item instead of a divisible unit

I also noticed that one token can blend roles (SKY, for instance, is both a governance token and tied to a stablecoin system).

For scale on how much rides on the token model: the stablecoin market was sitting around $316B in mid-2026. That's all tokens.

So next time someone hands you a new asset, the useful first questions aren't "what's the price" - they're "what chain does it live on, and what standard does it follow?" Those answers tell you how it behaves before any debate about what it's worth.

Curious where people land on this: do you think the coin/token line still matters to a regular user, or is it mostly relevant for builders?

I recently shipped Solana execution in a swap comparator and wanted to share the security model, because asking users to sign opaque base64 blobs from third-party APIs really should not still be the norm.

The pipeline, for every transaction a provider returns:

1. Deserialize the VersionedTransaction and refuse anything with more than one required signature. Multi-sig flows can hide approvals the user never sees.

2. Verify the fee payer is the user's address, not the provider's relayer.

3. Resolve every program id the transaction invokes, INCLUDING programs reachable through address lookup tables (the classic hiding spot), and require each one to be on a per-provider allowlist. Unknown program means hard refusal, logged.

4. Re-inspect server-side at submit time, so a compromised browser can't relay something that was never checked.

5. Replace the recentBlockhash only, then inspect the FINAL bytes that will be signed.

Two bugs we hit in production that might save someone time:

- One provider ships transactions with a placeholder blockhash (1111...) that their SDK normally replaces. If you build against the raw API, you have to re-date it yourself, and you'd better inspect the bytes AFTER doing so.

- Preflight commitment has to match the blockhash commitment, or you get "Blockhash not found" precisely when users sign fast.

Happy to go deeper on any step. Context: I'm the founder of the tool (rempart.app), but this post is about the model, and critique is very welcome.

​

PredictAsiaX is a full-stack prediction market built for Asia.

The platform is currently about 95% complete and still in the final development stage. Core infrastructure has been running in continuous production since 18 April 2026 (89 calendar days as of the latest update). Multi-chain USDT custody, multi-source oracle, settlement engines, public proof system, and the full trading interface are already live. User acquisition has not started, and trading is currently gated while the team finishes the remaining work. All activity to date is internal QA.

Core design:

• USDT-native + multi-chain

Accepts USDT deposits from 8 EVM chains + Tron under a single custodial address per user. Designed around how Asian retail actually moves money.

• 13 languages from day one

Including Arabic and Hebrew with full RTL support.

• Two market surfaces

Long-form markets (sports, politics, crypto, macro, tech, entertainment) with structured settlement.

Fast markets (1-minute / 5-minute / 15-minute / 1-hour binary rounds on BTC, ETH, SOL, XRP, BNB) for high-frequency trading.

• Additional layers

Parlay builder, copy trading, creator economy (anyone can create markets and earn a share of fees), LP earn, and VIP fee discounts.

Settlement & trust:

Settlement is currently off-chain on a double-entry ledger with daily reconciliation. Every settled market produces a public, unauthenticated `/proof/<id>` page that returns market outcome, LLM verdicts from multiple providers, article content hashes + snapshot URLs, and an ed25519 signature. Anyone can independently verify the evidence trail. A hard-void watchdog forces resolution within a bounded time window so no market stays open indefinitely.

The oracle layer runs ~50 external data sources across multiple fallback tiers plus an adaptive multi-provider LLM resolution system with self-critique and per-engine accuracy tracking. There are currently 39 settlement engines (23 general + 16 sports).

Current status:

• Development progress: approximately 95% complete

• Production infrastructure live since 18 April 2026

• Organic public users: 0 (acquisition has not begun)

• Trading, deposits and withdrawals: currently paused

• Remaining work is focused on final checks and launch preparation

Website: https://predictasiax.com

Full platform overview with live screenshots: https://predictasiax.com/overview.pdf

Happy to answer questions about the architecture, oracle design, multi-chain custody, or the public proof system.

Estou desenvolvendo o **Kaystra**, um protocolo de interoperabilidade que permite trocas atômicas entre Bitcoin e redes EVM (Ethereum, Arbitrum) **sem custódia, sem ponte e sem intermediário confiável**. Ele unifica três peças criptográficas: liquidação nativa em Bitcoin, witness encryption verificável e assinaturas adaptadoras — de modo que ou a troca acontece inteira dos dois lados, ou não acontece de forma nenhuma. Ninguém segura os fundos no meio do caminho. O protocolo já passou por validação em laboratório e por auditoria profissional, sem pendências abertas.

Crypto discussions often return to trading and investing, but blockchain technology has many possible applications.

Payments, identity, gaming, data ownership, supply chains, and financial infrastructure are often mentioned.

Which use case do you think has the strongest chance of becoming genuinely useful?

It seems like an aggregator is convenient because it lets you automate route selection. Doing it manually every time is indeed difficult and tedious. If this platform actually works honestly, I'd switch to it, but I need opinions from people who already have experience with this. Especially interested in how things are with slippage? And how fast are the operations in general?

I've been thinking about this recently.

One of the biggest reasons I got into crypto was the idea of self-custody and having more control over my own money. At the same time, I keep seeing crypto debit cards become more popular because they're an easy way to actually spend crypto in everyday life.

I started looking into getting one myself, but then realized most of them require full KYC and you're trusting another company to handle part of the process.

It made me wonder where people draw the line.

Do you see crypto cards as a practical bridge between crypto and the traditional financial system, or do they undermine some of the reasons many people chose crypto in the first place?

Or is it simply a compromise that's unavoidable if you want to use crypto for everyday purchases?

I'm interested in hearing how others think about the tradeoff.

Pushed a fairly substantial cleanup pass in CryptEX v0.6.4.

The main focus in this update was not “new feature for the sake of it”, but tightening the parts that tend to cause the worst user experience in small-network / mixed-platform testing:

- backend path recovery for the GUI/client flow

- better peer convergence when nodes are on competing equal-height tips

- unified mining behavior so GUI and backend mining stop drifting through separate local chain state assumptions

- stronger release coverage across platforms, now including Linux x86_64 and Linux ARM64 artifacts alongside macOS and Windows

A few concrete things that changed:

1. Backend startup recovery

The desktop client is now more defensive about stale or development-only daemon paths. If a saved backend path is missing or clearly points at a transient build artifact, the client recovers to the bundled daemon path instead of just falling over into backend-startup failure.

1. Peer sync / fork convergence

A lot of effort went into the equal-height fork problem and “why are these two nodes not resolving themselves?” class of bugs.

The networking side now does a better job of:

- tracking peer-announced heights

- requesting headers earlier

- using incoming headers to infer remote chain progress

- avoiding useless rebroadcast behavior when a block doesn’t actually advance the active tip

That matters because the failure mode wasn’t just “bad block rejected”, it was also nodes idling on competing views for too long without enough signal to converge cleanly.

1. Unified mining path

Mining behavior is now aligned around the live backend chain state rather than letting different entry points behave like they own separate local truth.

That sounds obvious, but it removes an entire category of confusion where a miner can be “working” from its own perspective while the actual chain manager rejects the result because the state basis was stale, repaired, or simply not the active tip anymore.

1. Better release matrix coverage

The 0.6.4 release now has:

- macOS ARM64

- Windows x86_64 bundle

- Linux x86_64

- Linux ARM64

For Linux, both raw binaries and AppImage packaging are included. The external PoW worker path is also carried across platforms, with the dedicated low-level worker variants kept outside consensus logic.

1. Checksum / release artifact cleanup

The release checksum manifest was also refreshed so the published assets line up with the current payload.

What’s next:

- more native Linux validation, especially AppImage runtime behavior on real target machines

- continued sync-path hardening in small or sparse peer topologies

- more cleanup around release/runtime consistency so platform builds behave closer to identically from the user side

- continued work on keeping miner performance improvements isolated from consensus correctness

The main goal here is simple: fewer “it runs but doesn’t actually converge” situations, and less ambiguity between what the miner thinks is valid and what the node will actually accept.

I have been looking into how automated systems resolve real-world events, and I think publishing only the final answer is not enough.

A more transparent design could include:

• a predefined resolution method
• the original data sources used
• fallback sources when a provider fails
• confidence thresholds for automatic decisions
• a circuit breaker that sends uncertain cases to human review
• timestamps and content hashes for the evidence
• a signed public record that anyone can verify later

The part I find most interesting is the evidence trail.

If an automated system says an event happened, users should ideally be able to see what information it relied on and verify that the evidence was not changed after the decision.

At the same time, publishing too much could expose private infrastructure, provider agreements or attack surfaces.

Where should the line be drawn?

Should these systems publish the full evidence and reasoning, or only the sources, final result and cryptographic proof?

Platform Overview: https://predictasiax.com/overview.pdf

A common assumption is that putting more information on-chain automatically creates more transparency. But in charity and social-impact systems, some of the most relevant information cannot or should not be publicly stored on-chain. Financial transfers can be verified relatively easily.

The harder layer includes:

- recipient information and privacy

- invoices and supporting documents

- explanations behind allocation decisions

- educational, medical or social outcomes

- evidence that funds produced the intended result

- corrections when submitted information was incomplete or false

This creates a difficult design boundary. Too little on-chain information leaves the system dependent on trust. Too much on-chain information can expose sensitive data, create permanent privacy problems and preserve incorrect information indefinitely.

One possible model would separate information into three layers:

1. On-chain: transactions, permissions, timestamps and rule execution

2. Cryptographically anchored: hashes or attestations proving that supporting records existed at a specific time

3. Off-chain: sensitive documents and contextual evidence available only under defined access rules

But this still leaves several failure modes:

- Who verifies the off-chain evidence?

- What happens when evidence is disputed?

- How do you prevent selective disclosure?

- How do you preserve long-term access without exposing personal data?

Where would you draw the line?

Which information should be fully public, cryptographically anchored or kept off-chain in a transparency-focused charity system?

Hey all, I have an idea for a new project however I am new to the crypto space. What should I do some research into/educate myself on specifically before pursuing this further?

Additionally, how would I go about creating a new coin? Could yall share some advice with a newcomer.

Spent the last few months building this as a solo side project and finally shipped it, figured I'd share.

It's called JCA (Josh's Crypto Aid). You build a watchlist, it pulls live prices and news, and an AI (Claude) actually analyzes both together and gives you entry/exit zones with a reason behind it, instead of just dumping charts on you and making you figure it out. There's also a daily picks feature that scans trending coins and surfaces a few that actually stand out, with reasoning attached.

No trading execution, it doesn't touch your wallet or move money, it's purely research/decision support. Built with Next.js, Supabase, and the Claude API.

Link: https://jca-ten.vercel.app/

Still actively working on it, would genuinely love feedback, especially if something breaks or feels confusing. Also happy to answer questions about how any of it was built if anyone's working on something similar.

Say “onchain” and people expect a token. Fair, given the history.

I’m using Base for something less exciting: recording ownership, purchases, transfers and settlement for paid automation agents.

That does not prove an agent is useful or safe. It makes the economic record independently inspectable instead of asking users to trust our dashboard.

Full disclosure: I’m building indie money, currently in open beta.

The surprising cost has not been technical. It is explaining that the chain is plumbing, not the product.

For builders using Base as backend infrastructure: does hiding it improve adoption, or weaken the trust benefit?

UPDATE Day 9 - Still No Access

9 days. No reason. No timeline. No funds.

Ticket: #20260705000154

MEXC's solution: contact the hacker's family"

I have submitted all KYC multiple times.

New Trustpilot review is live.

Sending me copy paste reply https://x.com/i/status/2076366093287870777 MEXC froze my account for 7 days - Support asking me to "contact family member