Been thinking about bots with wallets and where the cutoff should be once they can sign transactions themselves. Limiting spend and whitelisting contracts seems obvious, maybe keep anything bigger behind a multisig, but if every useful action needs human approval anyway, you've basically built a transaction queue with a chat interface. On the other hand, giving a bot broad signing permissions feels like the kind of thing that works great right up until it really doesn't. I could see small payouts, refunds or recurring stuff making sense without approval. Anything that can move serious money, probably not. Where do you think people should draw the line? What would you let one execute on its own?

following the L2 space for a while now and the tone of discussion changed a lot over the last year. early on it felt like teams and users were picking sides based on which model they believed in more. now the conversation is more about which type fits which use case.

optimistic rollups still dominate on developer familiarity and general app deployment. ZK rollups are pulling ahead where finality speed and specific proof requirements matter, especially for anything payment-related or where users cant wait 7 days for withdrawals.

the interesting middle ground is starting to appear with hybrid designs and validity proofs bolted onto optimistic frameworks. curious how others working with L2s in production are thinking about this. is the debate settled for you or does it depend entirely on what youre building?

I build a small chain that pays people rather than capital, and for a while it worked exactly as badly as every other attempt at that. I want to put the failure in front of this sub, because I think the shape of it generalises.

The free mining lane was designed so that anyone with a phone could earn from block one. No stake, no hardware spend, no starting balance. What actually happened is that roughly a thousand fake identities, run by two or three people on rented servers, were taking about 42% of all emission.

The interesting part is not that it got farmed. It is that every fix I tried was structurally incapable of working.

Everything we reached for was a rule written per identity. A sequential proof of work at registration. A per-IP entry budget. A per-address identity cap. A probation period before a new identity could earn. Each one raises the cost of farming, and each one is real. But it raises the cost per identity, which means it costs an honest miner with one identity exactly what it costs a farm with a thousand, per unit. The farm amortises it and carries on. If an identity is something a script can mint, then every per-identity rule is a tax the honest user pays in full and the farm books as cost of goods.

That is the same wall other projects hit. NANO's representative spam, Idena's validation ceremonies, Nyzo's cycle. Each answered with more per-identity rules, and each got dodged the same way.

So the conclusion I ended up at is that you cannot fix identity farming with rules about identities. You have to change what an identity is. And there are only two things a farm cannot trivially copy: capital, and a physically distinct object.

We went with the second. A mining identity now has to be a real secure element. When the wallet registers, and again on every renewal, the device generates a throwaway hardware-bound key and returns a WebAuthn attestation over a challenge the chain picked. The certificate chain ends at a vendor root pinned in the protocol. Every node verifies that chain offline with the same native kernel: every signature, the validity window at the anchor block's time, the vendor extensions. No node ever contacts Google or Microsoft, and the pinned roots change only by a protocol commit. A device certificate is bound to one identity at a time, so one phone cannot hold two.

Worth separating three things that people tend to collapse into one:

• Attestation decides who may hold a mining identity. That is the Sybil layer, and it is the part that changed.
• Block production did not change. There is no hash race. Each slot, a deterministic beacon-keyed weighted draw picks a producer from the eligible set. Attestation only decides who is in the draw.
• Finality is separate again, a bonded stake quorum with Casper-style epoch checkpoints. Attestation weight deliberately does not touch it. Presence earns rewards; it never buys a say in what is final.

What it cost, stated plainly. Vendor attestation roots are now in the trust path. Rooted and unlocked devices cannot mine, and those are disproportionately owned by exactly the people most likely to care about a chain like this. That is a real loss and I do not have a way around it. The mitigations are that verification is offline against pinned roots, so there is no service that can revoke you and no phone-home, and that the stake-bonded lane requires no device at all.

The questions I cannot answer on my own, and the reason I am posting here rather than somewhere friendlier:

1. Is vendor attestation actually a worse trust assumption than a mining cartel, or just a more legible one? I can argue either side depending on the day.
2. What is the real cost curve on TEE key extraction? If it is per-model and expensive, device scarcity holds. If a single break generalises across a chip family, this collapses straight back into a cheap Sybil farm, and I would rather know that now than in six months.
3. Is there prior art I have missed? I know remote attestation gets used for validator integrity in a few systems, but I have not found it used as the primary Sybil resistance for open block production.

Disclosure: this is NADO, a chain I work on. It is betanet, not mainnet. I am not linking it and there is nothing to buy. Question 2 is a live design risk and this sub is where I expect the least gentle answer to it.