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?

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.

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?

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.