Injection is runtime data, so 'compile-time' overstates it. A type system can taint-track — mark untrusted input, block it from a privileged sink. Valuable, but that's enforcement, not detection.

That is true -- the title does not precisely state what Jo is. It bounds the dangers that prompt injection can cause to arbitrary granularity.

I (the author of Jo) built Jo because I kept asking myself: can we solve the sandboxing problem at the language level — one that's actually aware of business logic?

Runtime sandboxes block syscalls, but they can't enforce "only this user's rows" or "only this API endpoint." That's application-level precision, and no sandbox can see it.

Jo's answer is to make capabilities typed parameters. If you haven't received one, you can't use it — the compiler proves this through the whole call graph, at whatever granularity your interfaces define.

This allows programmers to create bounds of arbitrary granularity that can contain the damages that can be caused by prompt injection.

Network-layer enforcement is right. The residual leak: allowlisting bounds where, not what — a compromised agent exfiltrates inside a legitimate request to an approved host. Covert channels move up to content.

Selective storage worries me — discernment is the model deciding what to drop, and you can't recover what it discarded. Storing everything and making retrieval selective fails safer.

Reconciling intent has a bootstrap problem: it's inferred from the same model you're constraining, so it rationalizes. Side-effect gates — spend, irreversible writes — can't be talked around.

Inspectable state shows what the agent believed, not why it diverged. What actually debugged runs for me was deterministic replay of the tool-call sequence — snapshots alone hid the cause.

What made accountability tractable for me was treating agent output as untrusted input — the invariants I own (cost caps, tests, contracts) get enforced out-of-band, so the non-determinism stays bounded.

Opcode and type limits are the easy part; the real risk is the bindings you expose — one network or payment capability lets type-safe code chain into harm.

This language is used for isolation at the language level and trusts the code written by the library developer. If absolutely necessary, I think environment isolation should still be used. What do you think of this approach ?

Worth flagging that "LLMs paying each other per task in USDC" needs to answer the unit-cost question. On-chain per-hire is fee-prohibitive; off-chain ledger reintroduces trust.

good question, I'll try to give an answer. Base is L2 blockchain, so the gas is really low (0.002$) you can see all the transactions from the tournament, they're 298. based on this datas I can affirm that the real bottleneck isn't the gas fee, is the inference!

forgot to mention: the facilitator pays the gas using EIP-3009. the result is that the USDCs go direct from buyer to seller.

Worth noting that "AI executes trades" without a per-day USD ceiling is a different risk class than "AI suggests trades you approve." Most agent-trading tools shipped without that ceiling as default.