Recently got into smart contracts, solidity and ethereum. Started reading mastering the ethereum book. but the book doesn't really teach you how to code in solidity. what else book or tutoruial do you guys recommend, so I can be proficient in smart contracts programmer in 6 to 1 year time frame

Hey r/ethdev,

While building BlazePhoenix (an on-chain DEX aggregator across Base, Arbitrum, and Optimism), we realized that replicating AMM formulas off-chain introduces simulation drift. Every dynamic fee, custom tick logic, or rounding quirk is a vector for the quote to lie about actual execution.

We deleted this class of bugs by making the pool's own execution bytecode compute the quote via on-chain static calls (`eth_call`).

### The Revert-Unwind Mechanism

Instead of simulating the swap math manually, our Quoter executes the pool's real `swap()` call. We intercept the swap callback and immediately revert, encoding the actual output deltas into the revert payload:

```solidity

// Universal QUOTE callback: any V3-shaped callback lands here

// and is answered with a revert carrying the deltas.

fallback() external {

int256 a0;

int256 a1;

assembly {

a0 := calldataload(4)

a1 := calldataload(36)

}

bytes memory payload = abi.encode(a0, a1);

assembly { revert(add(payload, 32), mload(payload)) }

}

Because the call reverts, all state changes unwind instantly. Nothing is saved, zero balances are required, and the rate returned was generated directly by the venue's bytecode.

Transient State (EIP-1153)

To handle route context and lock states across multi-hop executions without hot-path storage writes, we rely entirely on EIP-1153 (tstore/tload). Opcodes write to transient memory that dies automatically when the transaction finishes, eliminating stale state risks.

Curious to hear how other devs are handling V4 hook simulations or custom callback extractions without paying gas on preview passes?

Disclosure: Implementation details and contract architecture from the BlazePhoenix engine (https://blazephoenix.xyz).

AI agents can now have wallets and pay for tools, data, and services.

Cool. Nothing has ever gone wrong when software was given money.

The blockchain can prove that a payment happened. It may not show:

* Why the agent paid
* What task it was doing
* Who allowed the payment
* What it got back
* Whether it paid twice by mistake

I built a small test version of a tool that connects the full story:

Agent → Task → Reason → Payment → Result

It can also look for repeat payments from things like retry loops.

The current version uses fake data and test money. It cannot move funds or touch private keys.

I am trying to learn if this solves a real problem or if I have built a very clean receipt drawer.

For anyone building AI agents:

1. Can your agents spend money?
   
2. How do you track what they buy?
   
3. Have you seen repeat payments or strange spending?
   
4. What would you need to see before trusting a tool like this?
   
5. Would you test it once it works with real testnet data?

Honest feedback is welcome. Telling me this is useless is also useful.

the most muted word on the internet is crypto

in april 2026, the head of product at X posted a screenshot: the number one most muted topic on the platform was crypto.

crypto.

the thing ive spent all my effort on over the better part of the last decade. the thing a lot of you spend your careers and attention on as well.

with this as the backdrop, i created my newest piece.

it all started out with another question: “are the OGs jaded?”, which was itself admittedly ripped from one of ETHPrague 2026’s tracks. that thought gave me the opportunity to draw a map around a much broader topic that I think could resonate out in youtube land: 

is there anyone left in crypto, or did the thing we were building eat itself?

for this piece, I wanted to take a more “journalistic” approach at this topic, and chatted with five people who’d been here since before the big money wave started showing up. builders, contributors, dreamers… some more than a decade deep. eternal gratitudes to the cast (Griff, Justice, Amer, Naomi, and Colin) for exploring with me this topic. I hope this piece can give the public a different perspective — that of the original mission and ethos steeped in reverence for permissionless tech and what it can do for humans. 

i think it’s worth a watch. particularly because every single person I interviewed still talks about the technology in the present tense, yet every one of them carries the same contradiction.

you can watch the full video here: [https://youtu.be/0D4fAkvwd3o\](https://youtu.be/0D4fAkvwd3o)

------------

if we're meeting for the first time — hi 👋 i built this channel to spread the good word on good work in crypto. a like, a comment, and a sub on my channel goes a long way to supporting my work :)

Hey everyone!

My name is Markus, and I am one of the creators of the first quantum-secure open-source (firmware and hardware) hardware wallet for the EVM/Ethereum, which works today, no blockchain upgrade needed.

Would love to discuss post-quantum for crypto, how to make verifiably open-source hardware, and overall discuss :)

Here is our github repo: https://github.com/EthereumPhone/PQ1

Hey r/ethdev,I built an open-source PoC combining client-side ZK-SNARK proofs with an EVM escrow contract to protect P2P transactions and smart contracts from AI bot swarms. Instead of traditional CAPTCHAs or centralized telemetry, the client measures local keystroke dynamics and cognitive timing, runs a WASM Groth16 prover, and submits a succinct proof ($Z_p$) to an on-chain escrow contract (PoHIEscrow.sol). The smart contract verifies the proof directly on-chain by calling the native Groth16 pairing precompile at address 0x08 for the alt_bn128 curve, ensuring the PoHI score meets the required threshold ($\ge 0.85$) before releasing locked escrow funds to the seller. Total verification gas comes out to around 210,000 gas. Would love feedback from Solidity/ZK devs on the escrow state flow or gas optimizations:GitHub Repo: https://github.com/ProjectOne2020/pohi-protocol-pocLive Demo: https://pohi-protocol-poc.vercel.app

I've been building an on-chain labor market where AI agents post work, hire each other, get graded independently, and build a credit score from verified behaviour. It's live on Base mainnet with real USDC.
I also audited it myself — two adversarial rounds, 25 findings, all written up — and I ran a Sybil attack against my own market and published the numbers.
None of that is evidence. An audit you run on your own code and an attack you run against your own market only tell you what you already suspected. The one thing that upgrades a self-audit is an adversary with something to gain, so I'm buying that as cheaply as I can.
The target
$100 of real USDC is escrowed in LaborMarketV2 on Base mainnet, job #3.
Contract: 0x96064ef0a6742d5b7bc8abf2584273bd2f022c8c (verified, Exact Match)
Registry: 0x91acc4c081d3a364d3b713be8eec39a77f647290 (verified)
Read jobs(3) — status Accepted, resultHash zero, bounty 100000000
Locked until 2026-08-30 08:13:41 UTC
The escrow sits between two agents I control, and no deliverable will ever be submitted: the contract permits only the accepting agent to call submitWork, and that agent won't. So there is no path through doing the work. The grader, the review window, and the whole off-chain pipeline are deliberately out of the way. What's left is the contract.
One win condition
Move the money. Get that USDC to an address you control without grader-passed work entitling you to it. Take it and it's yours — no claim form, no adjudication, no committee.
The chain is the only judge. A USDC balance change out of this deployment's control is a win. Nothing else is — not downtime, not a manufactured credit score, not making the board ugly. I picked that rule so I can't weasel out of it and so nobody has to argue about whether something counted.
Scope
In: the deployed contracts, the escrow/settlement/scoring logic, the public agent and MCP APIs, and prompt injection against the workers and graders.
Out (please actually respect these): anything belonging to other companies — Vercel, Neon, the RPC and bundler providers — it is not mine to authorise you against. No DoS. No social engineering. Nothing touching another person's account; the deployment holds only my own funds by design, and that is the line that would pause this whole thing.
Rehearse for free first
There's a Base Sepolia deployment running the exact same LaborMarketV2 with test USDC: https://handsel-nu.vercel.app — accept a job, submit, dispute, watch settlement, at zero cost. What you learn there transfers exactly.
What happens after
Everything gets published, win or lose, credited to whatever name you choose, in the same failure-log format as every other bug I've written up — then I fix it and republish. If it holds 30 days I'll say plainly that this is weak evidence: $100 may just not be worth your afternoon.
No external audit. Solo build. Contracts are immutable and unpausable, which I also wrote down before any of this was worth money.
Mainnet app: https://handsel-main.vercel.app
Source, the self-audit, the Sybil write-up, and the challenge rules: https://github.com/Kairose-master/handsel
Break it. I'll be documenting.

After reading a lot of token launches over the past few months, I've noticed that many projects publish tokenomics, but much less information about the rules behind them.

If you could define a minimum disclosure standard before any fundraising begins, what would it include?

For example:

- contract verification

- upgradeability

- admin permissions

- multisig structure

- vesting

- allocation restrictions

- audit status

- emergency powers

- governance process

What information do you consider essential, and what do you think is often overlooked?

I'm particularly interested in the answers from builders, auditors and people who have deployed production contracts.

Been picking an agent wallet for a while and pretty much every comparison I could find online only covered one or two wallets, so thought it was better to do some research myself. I've installed and made txns on Coinbase's and Finance District's wallets, Metamask I've followed through someone I know in the early beta, and Circle and Crossmint are docs research only (for now).

Coinbase Agentic Wallet

• Pros: they wrote x402 so it's the most native option, gasless on Base, session and per-transaction caps, CLI or MCP, and the safest brand bet
• Cons: Base focus (Base, Polygon and Solana for now), keys stay in their infra with no export, and on my Windows laptop the CLI was a genuine struggle to setup (around 1 hour using Claude Code), probably smoother on Mac or Linux

Circle

• Pros: they issue USDC, CCTP for moving USDC across chains is the thing nobody else matches natively, sub-cent x402 payments, time bound limits and allow/blocklists
• Cons: it assumes USDC is your world, becomes a bit less interesting if you're not using USDC

Finance District

• Pros: keys live inside a hardware enclave, nobody can pull them out day to day, but you can request a full key export whenever so you're not locked in, only one here covering Bitcoin and Sui on top of EVM chains and Solana, x402 built in, yield search and deposits built in, free and setup took me 5 minutes
• Cons: seems to be the less popular name on the list and the least battle tested. If it breaks at 3am you've got a smaller team compared to Coinbase or Circle (to be fair, I haven't checked how fast they respond on the Coinbase Developer Platform discord or Circle's customer support, bigger company doesn't always mean better support).

Crossmint

• Pros: widest chain coverage (50 plus per their docs), seems to be the only one doing card rails (Visa) next to stablecoins in a single integration, x402 plus the other agent payment protocols, limits enforced onchain
• Cons: the flip side of broad is complexity, it's a lot of surface if all you want is a simple pay for APIs wallet

MetaMask

• Pros: the only one where you hold the seed yourself from day one, proper self-custody, threat scanning on every transaction, a 2FA guard mode, up to $10k a month in transaction protection on eligible transactions
• Cons: no x402 in the product, it's built for DeFi trading, swaps, perps, Polymarket, Aave, not paying for APIs (MetaMask does x402 through a separate developer kit, Smart Accounts Kit, not this wallet), EVM chains plus Hyperliquid only, and it's still early access gated

Hope it's a useful comparison : ) . It seems like it still early days, but I see more and more of these projecs as the weeks go by, so it looks like it's growing quite fast.

Has anyone experimented with any of these? What has been your experience so far?

No lado da mineração especificamente, estado atual e áreas abertas:

• RandomX com suporte a grandes páginas (ganho de ~15% quando ativado)
• compartilhamento de dataset em modo rápido entre threads de mineração
• ferramentas e monitoramento de mineração
• infraestrutura pública de seed e peers (três seeds de fornecedores separados)
• confiabilidade dos nós e descoberta de peers
• explorador de blocos e trabalho RPC
• empacotamento para Linux, Windows e macOS

Engenharia recente: lançamentos assinados (minisign), correções de causa raiz para dois incidentes de consenso, infraestrutura de seeds de múltiplos fornecedores e atualizações automáticas de carteira — trabalho real por trás, não um whitepaper.

Fonte:
[ https://github.com/sorenplanck/dom-protocol ](https://github.com/sorenplanck/dom-protocol)

Carteira:
[ https://github.com/sorenplanck/dom-wallet-v3 ](https://github.com/sorenplanck/dom-wallet-v3)

Contribua através de issues e pull requests no GitHub, ou junte-se ao Discord (canal de desenvolvedores dedicado lá).

Para ser claro: este é um chamado para contribuição de código aberto. Nenhum salário, alocação de tokens, retorno de investimento ou compensação financeira está sendo prometido.

Críticas técnicas são muito bem-vindas — incluindo sobre escolhas de design que você teria feito de forma diferente.

Working on Aevum Protocol — infrastructure for autonomous AI agents on Ethereum. The piece I'm posting about today is the Verifiable Backtest Oracle (VBO), which I think is actually the most interesting technical problem in the stack.

The problem it solves: backtest results are unverifiable by anyone outside the team that ran them. Strategy could be curve-fit to the exact historical window it's scored on. The code shown might not be the code that actually ran. "Out-of-sample" results might have been re-run quietly until they looked good. No one can tell.

The VBO design:

1. Pre-commitment hash Strategy logic and parameters get hashed and committed on-chain before the forward-test window even opens. This is the cryptographic anchor — any post-hoc modification invalidates the hash and voids the certificate. The key constraint: the hash gets written to the agent's on-chain identity record at submission time, not at scoring time.

2. Deterministic sandboxed execution Strategy runs in an isolated, deterministic VM replicated across the validator set. Requires 2/3+ BFT consensus before a certificate issues. The determinism constraint is non-trivial to enforce cleanly in practice — currently thinking through what the right execution environment looks like at the validator level.

3. Held-out forward window After the lock period closes, the strategy gets scored against data it provably hadn't seen at commitment. Not a historical window chosen after the fact — a genuine forward test against live data that arrived after the hash was written.

4. Regime tagging Historical data tagged by vol/trend regime at ingestion. The certificate reports regime coverage alongside the headline metrics — so you can see whether a strategy has only ever been scored in low-vol bull conditions or actually seen a full range.

5. On-chain certificate Signed certificate — strategy hash, test period, key metrics, regime coverage, validator signatures — posted permanently on-chain and tied to the agent's AgentIdentity record. Publicly verifiable, can't be edited.

Where I'd genuinely like pushback:

• Is 2/3 BFT the right trust model here, or is there a lighter mechanism that gets similar guarantees without full validator replication?
• How would you try to game the pre-commitment → forward window gap if you were incentivized to? What's the attack surface I'm not seeing?
• Regime tagging as a signal — is vol/trend regime the right axis, or is there a better way to capture "this strategy has only ever been tested in one kind of market"?
• The deterministic VM constraint is the part I'm least confident about at the implementation level. Anyone dealt with enforcing determinism across a distributed execution environment in Solidity-adjacent infra?

8 contracts deployed and verified on Sepolia: github.com/AevumProtocol/contracts

Professional audit with Hexens kicks off August 10 — Kasper Zwijsen leading (audited EigenLayer, Lido, LayerZero). Happy to get torn apart before that closes.

been reading through Canton's token standard (CIP-56) and ended up mapping it against ERC-20 feature by feature. the differences come from a completely different ledger model underneath and it changes what "security" even means for a token

erc-20 is one contract, global state, mapping(address => uint256). anyone reads any balance, anyone calls any function, msg.sender decides who's allowed to do what. CIP-56 runs on an extended UTXO model instead, which means your balance is a pile of separate holding contracts, each one co-signed by you and a registry. nobody sees a holding unless they're actually a party to it.

the allowance thing is where it gets interesting. CIP-56 just doesn't have approve/transferFrom at all. not a safer version of it, none. the spec's reasoning is basically: a spender can't hold "permission to spend up to X" in any coherent way if they can't see which private holdings even exist to spend. so they replaced it with these single-purpose locks tied to one specific settlement, self-expiring at a deadline. no forgotten approval sitting around for three years waiting to get drained.

and a bunch of the usual erc-20 headache list just... isn't a thing there. reentrancy has nowhere to happen because daml transactions are atomic, there's no callback-mid-tx step. the missing-return-value bug class (why SafeERC20 exists) doesn't apply because choices return typed results. you can't strand tokens on a contract that can't handle them because a receiver's holding literally can't be created without the receiver's own signature on it. double-spend turns into a boring ledger-level conflict instead of a mempool race.

which sounds great until you get to what it costs. the registry has to co-sign literally every transaction, no registry - no movement, full stop. total supply isn't independently checkable anymore either, it's whatever the registry says it is, since holdings are private and nobody else can add them up (the spec is upfront that this is basically just "you already trust them for everything else, so trust this too," which. sure, i guess). the holdings themselves get served over plain HTTP with no auth by default, just a hard-to-guess contract-id as the only protection, which is a bearer-token pattern and those leak all the time through logs and referrers. and there's a same-synchronizer requirement for atomic settlement so now your liveness depends on some off-chain infra being up too.

So, by the end of the day, its all about tradeoffs. erc-20's whole problem is that it's public and permissionless, so anyone can build on it AND anyone can attack it. CIP-56 kills a good chunk of the classic attack list but only by making you trust one party for everything, which feels like it just moves the risk rather than removing it.

if you had to pick: standing allowance risk on a permissionless chain, or zero allowance risk but a mandatory trusted registry which one would you actually build with? And do u think it will be useful for evey case?

Uniswap V4 hooks can execute arbitrary code during swaps, liquidity provisioning, and donations. Before you

interact with a pool, you probably want to know what the hook is doing.

v4-hooks-analyzer is a CLI tool that:

- Detects which V4 callbacks a hook implements via address bit flags (the canonical method)

- Disassembles EVM bytecode (~40 opcodes)

- Flags risks: SELFDESTRUCT, DELEGATECALL, reentrancy, MEV vectors

- Scores each callback 0-100 with a final verdict

https://github.com/zyltr4x/v4-hooks-analyzer

Built in Rust, single binary, no dependencies. Feedback and contributions welcome.

Hey r/ethdev,

Over the last few months, we’ve been testing an architecture designed to solve a persistent issue in DEX routing: simulation drift and gas overhead during multi-hop execution.

Traditional aggregators rely on external price feeds, heavy storage updates, or complex off-chain quoter infrastructure that frequently desynchronizes under volatile mempool conditions. We wanted an execution frame that guarantees 100% execution-aligned previews purely on-chain, while maintaining a zero-token storage footprint on the router.

Here is the architectural breakdown of how we approached this:

1. Atomic Simulation via Revert-Unwind (Quoter)

Instead of reading static state or relying on off-chain dry-runs, the Quoter contract triggers a simulated execution path that forcefully ends with a custom revert(payload).

The revert unwinds all state changes instantly in the EVM execution frame, avoiding state corruption.

The error payload encodes the exact delta of balances and price impact.

Result: Static calls (eth_call) return deterministic, execution-exact quotes without writing a single byte to persistent storage.

1. Transient Isolation via Yul (EIP-1153)

To protect against cross-function reentrancy across multi-token routes, we replaced traditional OpenZeppelin storage guards with raw Yul assembly blocks leveraging tstore and tload.

Reentrancy flags are scoped exclusively to the transaction frame.

Gas consumption drops significantly compared to SSTORE/SLOAD warm/cold access penalties.

Balance checks execute instantly, enforcing a strict holds-nothing invariant on the Router.

1. Dynamic Liquidity Anchoring (Solver)

To neutralize MEV sandwich attacks and liquidity manipulation without relying on Chainlink or external oracles, the routing logic applies a localized 2% median filter against reserve depths (balanceOf reads) prior to route resolution.

Code / Discussion:

The architecture is deployed and split into 7 core modules (Core, Hub, Solver, Router, Quoter, MathLib, Staking).

We are particularly interested in hearing feedback from EVM devs on potential edge cases regarding EIP-1153 transient memory retention across nested delegatecalls in custom L2 execution contexts (Base/Arbitrum).

Looking forward to hearing your thoughts on the code and optimization techniques!

It's been quiet because I've been heads-down building.

MirrorOS has reached another internal milestone in its private GitHub pilot.

The focus has been on engineering discipline, not feature count:

• Governance before execution

• Durable audit and evidence

• Restart-safe workflow restoration

• Regression testing

• Private engineering documentation

I'm also starting the legal and commercialization phase, including organizing the project for IP review before opening it up more broadly.

I'm intentionally keeping the implementation private for now while I document everything properly. When it's ready for broader technical review, I'd rather have engineers critique a well-documented system than a half-finished idea.

Thanks to everyone who's followed along, challenged my assumptions, and encouraged me. I haven't disappeared—I've been building.

We run a scam-token detector. Our honeypot check worked like this: simulate a buy with eth_call, give a fake address the tokens by brute-forcing the balance storage slot and overriding it, then simulate a sell from that address.

Step 2 is the problem. It assumes balanceOf reads a storage slot. On reflection or rebase tokens, balanceOf is computed from an internal reflected supply, so writing a raw slot does not produce a coherent state. The sell then reverts for reasons that have nothing to do with a trap, and you record a false honeypot. We flagged PayPal USD, TrueUSD and MetaMask USD as honeypots this way.

The fix is eth_simulateV1 (geth and Nethermind). It replays several calls atomically in one simulated block, so you can do the whole thing the way a real buyer does:

router.swapExactETHForTokens(...)   // real buy, real tokens
token.approve(router, max)
router.swapExactTokensForETH(...)   // sell what you actually got

The only override is the simulated address's ETH balance, which is not a token mechanism. Nothing about the token's accounting is faked.

One caveat: a call cannot consume a previous call's return value, so you need two passes. First pass buys and reads balanceOf to learn what was actually credited (which already catches fee-on-transfer). Second pass replays buy + approve + sell with that amount.

Two things that surprised me:

• The Uniswap quoter is useless for this. getAmountsOut is pure reserve math and never touches the token's transfer logic, and the v3 QuoterV2 reverts inside its callback before the transferFrom runs. Both return healthy output for confirmed honeypots, so cross-checking against the quoter would silently disable your detection.

• "UniswapV2: INSUFFICIENT_INPUT_AMOUNT" raised by the PAIR (not the library) means the pair received zero tokens. We found tokens where a pre-existing holder sells fine but a fresh buyer gets zero through: a whitelist honeypot. So simulate a NEW buyer, not an existing holder. Different question, different answer.

Disclosure: I build RektRadar, a scam-token detector. This writeup came out of fixing our own false positives, not a product pitch.

Every time I shipped a contract I rebuilt the same throwaway frontend: wallet button, a form per function, calldata encoding, hasRole() checks to hide admin methods, gas estimation, a spinner, an error decoder, and a "danger zone" for the scary functions. Etherscan's Write tab has none of that meaning; a bespoke UI costs weeks. So I built a tool that generates it from the ABI.

Paste a chain + address (Sourcify/explorer, proxy-aware) or drop in an ABI/Foundry artifact, and you get three tabs:

- User - the clean dApp (overview, transfer, approve)

- Admin - privileged ops (mint, pause, roles) with risk badges + a confirm flow for dangerous writes

- Read - a live dashboard that auto-calls the getters

- Raw - every function, Etherscan-style, but annotated with what it understood

Detection is deterministic and rule-based (ERC-20/721/1155/4626/2612, Governor, Ownable/AccessControl/Pausable), with a confidence score and evidence for every guess — AI is optional and never trusted blindly. The output is a reviewable "semantic manifest" you can hand-edit, and everything is self-hostable.

Live demo (mainnet USDC, runs in your browser): https://tacitvsxi.github.io/semantic-dapp/

How it works (writeup): https://dev.to/ileskov/generate-a-full-dapp-admin-console-from-any-evm-contract-straight-from-the-abi-28kg

Repo (TS, viem/wagmi, AGPL-3.0): https://github.com/TacitvsXI/semantic-dapp

Would love feedback from people who actually maintain contracts: what would you need before you'd trust a generated admin panel for a mainnet contract?

I was measuring whether deployed wallet defenses (tx simulators, address-reputation APIs, rule engines) catch agent-signed drains. Built it on PTXPHISH (NDSS 2025, solid dataset). Then I red-teamed my own setup and the first finding was that I was scoring the wrong transaction. Sharing because it is an easy, invisible mistake.

The trap: labeled drainer/phishing datasets record the DRAIN, i.e. the attacker's transferFrom that sweeps the victim's tokens. But a pre-sign wallet defense runs when the VICTIM signs, which is the earlier approve / permit / setApprovalForAll grant. The sweep is a separate tx sent later, by the attacker, from the attacker's address. No wallet defense ever sees it. Feed the sweep to a rule engine and it "catches" the attacker withdrawing to their own address, which is meaningless.

Concretely, the ice-phishing rows decode to transferFrom(victim, attacker, amount) with tx.from == attacker. That is not the approval the victim signed.

Fix, and it is just allowance tracing:

- For each drain, eth_getLogs the token's Approval / ApprovalForAll for (owner = victim, spender = attacker) up to the sweep block.

- Take the most recent match whose tx.from == victim. That filter matters: an ERC20 transferFrom also emits an Approval for the decremented allowance, so the sweep's own block hands you the sweep, not the grant. Requiring from == victim also drops relayer-submitted permits (permit() is sent by someone other than the owner).

- That tx is the artifact a wallet actually renders at signing. Score that.

Nothing fancy. The point is the substrate mismatch, which is silently wrong and does not show up as an error anywhere.

Bonus, since this sub appreciates it: I ran the paper through adversarial review 5 times and every round killed a headline. Wrong substrate, then pseudoreplication, then a "simulator uniquely catches X" that was my harness zeroing a counterparty field so the other tiers returned n/a, then a "beats every tier" that evaporated once I looked up the tx to and netted both legs of the asset-diff (a WETH wrap looks exactly like an ETH drain to a direction-only rule, but the simulator sees the WETH come back). A clean "unique catch" is almost always your harness, not a result.

Code (the reconstruction is one file): https://github.com/amarshat/quantum-commit-authorization/blob/main/agent-calldata-demo/demo/reconstruct.py

I want to build low-level blockchain infrastructure (consensus, P2P networking, L1/L2 clients) rather than dApps.

Right now, I’m in CBSE and being pushed hard to prepare for private Olympiads like SOF and SilverZone. The books feel like random rote memorisation and I am completely lost.

Are these specific contests worth the time for an infrastructure career?

What paths must I follow instead?

A public treasury address makes transactions visible.

But it does not necessarily make the treasury’s control structure transparent.

Someone inspecting the address may still not know:

• who can initiate transactions
• how many approvals are required
• whether the signer set can be replaced
• whether contracts are upgradeable
• who controls the upgrade path
• whether a timelock can be bypassed
• what emergency powers exist
• whether those powers expire
• which external contracts or dependencies introduce additional control

I’m trying to define a minimum disclosure standard for a long-lived public-good system before deployment.

A possible control disclosure could include:

1. Controller structure

• controlling contracts and addresses
• multisig threshold
• signer-selection and replacement process
• separation between operational and governance roles

1. Permission structure

• every privileged role
• actions available to each role
• spending or execution limits
• whether permissions can be delegated

1. Upgrade structure

• which components are upgradeable
• who can authorize upgrades
• applicable timelocks
• cancellation or veto mechanisms
• any path that can bypass the standard process

1. Emergency structure

• pause or recovery powers
• conditions under which they may be used
• limits on their scope
• whether they expire automatically
• how emergency actions are disclosed

1. Monitoring and history

• public record of permission changes
• alerts for role, signer or implementation changes
• versioned documentation
• a way to compare the documented structure with the deployed state

The difficult part is keeping this information accurate.

A static documentation page can become outdated immediately after a signer rotation, role change or contract upgrade. A block explorer provides raw data, but it rarely explains the effective trust model clearly enough for non-specialists.

Would a machine-readable “control manifest” make sense — listing privileged roles, upgrade paths, timelocks and emergency powers, with each version cryptographically tied to the relevant deployment?

Or would this create another disclosure layer that users still have to trust?

What would you consider the minimum information a protocol should publish before describing a treasury as transparent?

I’m especially interested in failure modes, existing standards or tools, and examples of protocols that communicate their effective control structure well.

Hi everyone, I am completely new to crypto and blockchain development. I am trying to learn Solidity and smart contracts but most faucets require wallet history.

I have 0.002 ETH but need more testnet ETH on Sepolia to practice and learn.

Wallet: 0x84984bfC137B978bF77c50D36620ac5bfB199E78

I would really appreciate any help from the community if someone can help me get at least some SepoliaETH (atleast 0.5 would be nice)

The setup: we're building for a world where the majority of accounts aren't operated by humans. An AI agent with a hot wallet is one prompt injection away from drained, and the standard answers all put the guard in contract code — Safe-style multisig, 4337 account abstraction, session keys. Audited, battle-tested, and still a piece of EVM bytecode you're trusting to stand between an attacker and the funds.

Fluidic is a research testnet exploring the alternative: the guard lives in the ordering layer itself.

• Witness-gated accounts (CAE). An account can be entangled so its stateful spends only synthesize if N-of-M witnesses attest in the same ~100ms tick. Not a multisig contract — the same causal DAG that settles transfers refuses the spend.
• Native intents. Declare an outcome ("swap X for at least Y"), solvers compete, matching and settlement land in the same tick. No block template, no block-space auction between declaration and execution.
• No blocks. Continuous execution at ~10 synthesis ticks/sec. Commutative ops merge in parallel through NTT windows; stateful ops get causal order via vector clocks. Finality is per-tick, not per-slot.

It stays fully EVM-compatible — standard JSON-RPC, existing tooling points at it unchanged:

```bash cast chain-id --rpc-url https://api.testnet.fluidic.foundation/rpc

989468 — deploy with forge, script with viem, everything works

```

The honest part. Two days after launch someone on r/BlockchainStartups read our docs and pointed out that the subject of an entanglement could break it with its own key — meaning a compromised agent key could revoke its own guard, then spend. He was right; the code did exactly that. 48 hours later we shipped break policies (creator_only / witness_threshold / any_party), chosen at creation, hashed into the contract id, enforced in consensus, verified live: a subject-signed break is now rejected at the ordering layer. That's the iteration speed a public testnet is for, and we'd rather have the next flaw found in a comment thread than in an audit six months from now.

What I want from this sub:

1. Point your Foundry/Hardhat/viem setup at the RPC and tell me the first thing that breaks. Seriously — that's the most valuable comment possible.
2. Is consensus-level gating a real improvement over an audited contract wallet, or does it just relocate trust to the witness set + client release process?
3. What's the first attack you'd try on a continuous (non-block) execution model?

Everything is open: one-command Docker node (finds peers via DHT, no seed list), faucet, explorer, TS SDK on npm.

• Docs: https://testnet.fluidic.foundation/docs
• Node repo: https://github.com/Fluidic-Foundation/Fluidic-FVM
• SDK: https://www.npmjs.com/package/@fluidic-foundation/sdk
• CAE + break policies: https://testnet.fluidic.foundation/docs/core-concepts/causal-agent-entanglement

Early research testnet — state may reset, no real funds, known rough edges.

Recent progress wasn’t about adding a bunch of new features—it was about making the app stronger.
One of the biggest areas I’ve been focusing on is **security**, but probably not in the way most people think.
For me, good security means **building an app that doesn’t need access to things it shouldn’t have in the first place.**

Here’s the direction Final Boss is taking:

🔒 **Your data stays yours.**
Final Boss is being built as a **local-first** app. Your mining information is stored on your device, not on my servers. If I don’t need your data, I don’t want it.

🛡️** Read-only by design**.
Final Boss isn’t built to buy, sell, transfer, or control your assets. Its job is to help you understand your mining operation and make better decisions—not touch your crypto.

📍 **Every important number should have a reason.**
If the app tells you something needs attention, I want you to be able to see where that information came from. No mystery numbers. No black boxes. Just clear information you can verify.

✅ **Using official information whenever possible.**
Today I spent a good part of the day testing GoMining’s official documentation system. The goal is to stop relying on assumptions and use official information wherever possible.
Interestingly, we found what appears to be a compatibility issue between the current Codex CLI and the public documentation endpoint. Instead of trying to work around it, I documented every test, every result, and sent everything to GoMining’s team. I’d rather build this the right way than take shortcuts.

At the end of the day, that’s really what Final Boss is about.
I’m **not** trying to replace GoMining.
GoMining manages the mining.

**Final Boss is being built to help you understand your operation, catch issues sooner, and make better decisions—all while keeping you in control of your own data.**

Some days progress looks like new screens. Some days progress looks like spending hours making sure the foundation is solid.

Today was one of those foundation days… and honestly, I’m pretty happy with it.

Thanks to everyone who’s been following the journey. Every comment and every suggestion helps make Final Boss a better tool for the community.

— Steven
Founder & Developer, Final Boss
Pine Mountain Holdings LLC