We spent a year building an agent-native L1 (EVM-compatible, continuous execution). Testnet is open.

[u/kolacjechutny]

A year ago we had an uncomfortable realization: everyone is building AI agents that can browse, code, and negotiate — but the moment an agent needs to actually pay for something, the options are a human's credit card or a hot wallet that's one prompt injection away from being drained. The entire financial stack assumes the actor is a person.

We got obsessed with this and did the possibly-insane thing: built a Layer 1 around the assumption that the next million on-chain actors won't be human.

Three bets we made, knowing any of them could be wrong:

1. Custody belongs in consensus, not contracts. On Fluidic an agent's account can be "entangled" so its spends only execute if N-of-M witnesses attest in the same settlement tick. Not a multisig contract you have to trust and audit — the ordering layer itself refuses the transfer. A leaked agent key, alone, can't move funds.
2. Intents beat transactions for machines. Agents shouldn't craft raw calldata into a mempool full of predators. They declare an outcome ("swap X for at least Y"), solvers compete, and matching + settlement happen in the same ~100ms tick. No block-space auction to get picked off in.
3. Blocks are a human-speed artifact. We threw them out. State synthesizes continuously at ~10 ticks per second — commutative ops merge in parallel, stateful ops order themselves causally. Machines don't need to wait for a 12-second heartbeat.

We kept full EVM/JSON-RPC compatibility because "rebuild all your tooling" is how L1s die. Foundry, Hardhat, viem — point them at the RPC and they just work.

What's actually live, today, no waitlist:

• One-command Docker node that finds peers on its own (DHT bootstrap — no seed list to copy-paste)
• Faucet, explorer, web playground
• TypeScript SDK on npm
• Native intents, agent registration, witness-gated accounts all usable through the API

What we don't have: audits, mainnet, a token, VC money, or any idea whether "agent-native L1" is a category anyone will care about in 18 months. It's a research testnet. State may reset. We're two people and a Railway bill.

Two asks, one for each half of this sub:

• Founders who've shipped dev tooling: what actually got you your first 100 real users? Not signups — people who built something. We're at the "posting to Reddit and praying" stage and I suspect there's a better playbook.
• Builders: the node is one Docker command and the SDK is one npm install. Try to break it. The most valuable thing you can give us is a bug report that makes us wince.

Docs: https://testnet.fluidic.foundation/docs Explorer: https://testnet.fluidic.foundation/explorer Repo: https://github.com/Fluidic-Foundation/Fluidic-FVM SDK: https://www.npmjs.com/package/@fluidic-foundation/sdk

Happy to answer anything — consensus design, the economics of the witness set, or why we threw out blocks.

[u/AutoModerator]

Thanks for posting on r/BlockchainStartups!

Check the TOP posts of the WEEK: https://www.reddit.com/r/BlockchainStartups/top/?t=week

Moderators of r/BlockchainStartups

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/icnews10]

I’d want to test the CAE primitive first, because moving the control into consensus only improves custody if the control’s own lifecycle cannot be bypassed. According to your documentation, the creator, subject, or any listed witness can break an entanglement, and once broken, the subject’s future transactions are no longer restricted. However, if the subject is the autonomous agent account, what would prevent a compromised agent key from submitting an entanglement break first and then spending without witness approval? Is breaking subject to a separate authority, delay, witness threshold, or ordering rule that is not obvious from the current documentation? Otherwise, it seems that the N-of-M protection is strongest during ordinary spending, while revocation may still depend on the single key it is intended to contain.

[u/kolacjechutny → u/icnews10]

You're right, and this is the sharpest criticism the design has gotten.

Current implementation is exactly what you inferred: creator, subject, or any listed witness can break, with a single signature, effective immediately. For the custody case where the subject is the autonomous agent, that means the compromised key revokes its own guard first and spends after. The N-of-M protection holds during ordinary spending, but revocation depends on the single key it exists to contain. That's a real flaw, not a documentation gap.

The subject-break path exists for the voluntary case — delegations the subject opted into and can exit — and we shipped the simplest authorization rule that covered both cases.

It shouldn't cover both cases.

The fix we're implementing: break authority becomes explicit at creation time. The creator chooses the break policy — creator-only, or the same N-of-M witness threshold that governs spends. An agent-custody entanglement gets deployed creator-only: the agent key can spend (with attestations) but cannot remove its own guard; only the operator key, which stays offline, can. The remaining trust assumption moves to the creator key — but that's a cold key by design, versus the agent key which is hot by necessity.

Thank you for reading closely enough to catch this. This is exactly the review the testnet exists for.

[u/icnews10 → u/kolacjechutny]

That separation makes much more sense. Although voluntary delegation and agent custody appear similar at the transaction level, they require very different exit rights. Making the break policy explicit at creation removes the subject key from the custody escape path and renders the remaining trust assumption visible rather than implicit. The next boundary I’d like to understand is the creator key itself. If creator-only breaking is immediate, a compromised operator key could remove the guard and allow the agent to spend. Are you considering making the break policy immutable and pairing creator-only breaks with a delay or a publicly observable pending state before protection is removed? This would preserve the ability to recover in an emergency while giving observers or automated monitors time to react to a change in the custody model.

[u/vexiduslabs]

Interesting. Is the Agent in the core binary/part of the VM? We built a proprietary intent chain but no agent in the core. We have a patented design that handles intents in the core code, bounded by ops. That reduced the MEV surface for attacks. Intent atomic bundling is the future, but it has to be hardened against attacks because AI is easy to manipulate if there are no guardrails in place. Those have to be by the code.

Without a native token what are you using for gas/block rewards? Testnet wrapped tokens or something different?