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.

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.