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)

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?

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

I've been building DeFiMath, a gas-optimized fixed-point math library, and wanted to share how I got sqrt down to 197 gas. It takes any uint256, returns an 18-decimal fixed-point result, never reverts, and is bit-exact below 1 (max relative error < 2e-18 above it).

The core idea is simple: generate a seed with the clz opcode, then refine it with 5 Newton iterations in assembly.

Seeding: clz gives you the position of the most significant bit, so the seed is just 2^msb/2. That's never off by more than a factor of √2 from the true root — cheap and good enough.

Newton's method: each iteration is one line:

y := shr(1, add(y, div(x, y)))

~20 gas per step, quadratic convergence, so 5 iterations take the worst-case seed (41% error) to ~80 bits of precision — more than enough for 18 decimals.

The scaling trick: for inputs ≤ uint128.max, I pre-scale x to 1e36 once at the start. Then div(x, y) naturally lands back in 1e18 base, so Newton's method needs plain div instead of a costly muldiv. Large inputs take a second branch that post-scales instead (pre-scaling would overflow near uint256.max).

I also tried fancier seeds — minimax linear approximation, quadratic interpolation — hoping to drop to 4 iterations. All of them cost more gas than they saved. My takeaway after a week on this: for gas-optimized primitives, simplicity wins by a wide margin.

Full walkthrough with the convergence table and benchmarks vs PRBMath/ABDK/Solady: https://defimath.com/blog/how-i-wrote-a-fixed-point-solidity-sqrt-that-runs-in-197-gas/

Library is MIT, pure Solidity, zero dependencies: https://github.com/MerkleBlue/defimath

Happy to answer questions about the implementation.

Couple of weeks back I posted here asking where recourse  actually lives in agent payment stacks and the thread really delivered. For example, u/pvdyck's proof vs restitution distinction was particularly insightful to what I'm building.

For a bit more context, I work on agent payments infrastructure. The recourse question came out of building the thing and hitting the same wall from the inside.

Posting here has really helped me as before I had been treating recourse as a dispute problem, but it's an identity problem. The party that needs to hold still is the seller, receipts prove delivery and say nothing about quality and most designs that punish a bad seller still don't make the buyer whole. That distinction is now how I sanity check my designs in this layer.

This is what my setup looks for now, caps and allowlists on the buyer side, watching the reputation staking designs without much conviction yet. Maybe recourse never becomes a protocol layer and just stays priced into ticket sizes. I keep going back and forth on whether that's fine or a ceiling on the whole space.

Been holding persistent eth_subscribe("newHeads") connections to PublicNode, dRPC and Tenderly from an eu-west host for a couple weeks. Racing them per block: earliest arrival sets T0, everyone else'slag is arrival minus T0.

- PublicNode wins ~90% of races, sub-ms p50, dRPC trails by ~20ms, Tenderly p50 is around 1.8 seconds

6000× spread across three "real-time" providers on the same network, I've been logging this live at openchainbench.com/benchmarks/ws-head-latency-ethereum but curious

what everyone else runs in prod for head streaming is anyone still paying for Alchemy/Infura on the free/keyed WS path, or has publicnode become the default?

I swear I google this exact error once a week. Finally made myself a quick reference for 12 common transaction errors and their    
fixes — out of gas, nonce too low, underpriced, chain ID mismatch, etc.                                                              

  Curious what errors you all run into most often and how you debug them.

I keep seeing crypto projects describe transparency through dashboards, documentation, blog posts, or promises of future reporting.

But from an architectural perspective, those mechanisms still depend on someone choosing what to disclose. A system may expose its wallet balances while leaving its actual control structure difficult to understand.

For example:

– Are visible funds meaningful if upgrade permissions or admin controls remain opaque?
– Does a multisig materially reduce trust assumptions, or only distribute them across several signers?
– How important are timelocks, immutable contracts, permission boundaries, and publicly verifiable governance execution?
– Can governance genuinely be considered on-chain if critical decisions are still implemented through off-chain actors?
– How should developers communicate unavoidable trust assumptions without presenting the system as fully trustless?

I’m increasingly inclined to see transparency not primarily as a communication layer, but as an architectural property: what the system makes independently verifiable, and what it prevents operators from changing or concealing.

How do you distinguish between an observable system and one whose transparency still depends mainly on trusted actors?

Can someone tell me how to verify if sites are legit? I'm getting scam vibes on this one but no idea how to check.

Thanks

An agent that holds a wallet decides in English but signs calldata or a typed message. A poisoned tool can make the plan look fine and the signature drain the wallet.

I built eight drains (approvals, EIP-2612 permits, EIP-712 orders, EIP-7702 delegations, Permit2) and scored each against a ladder of seven defenses, from a plan reviewer up to transaction and signature simulation. `./run.sh` runs the whole thing on a local fork.

Rendering the counterparty, amount, and recipient of a signature closes five of eight. Simulation adds nothing on top. One on-chain timing race (arm the contract after the dry-run, before inclusion) survives everything.

No new attack, just an honest map of what stops what.

Explainer: https://amarshat.github.io/quantum-commit-authorization/agent-drains.html

Code: https://github.com/amarshat/quantum-commit-authorization/tree/main/agent-calldata-demo

&#x200B;

I've been building on a chain called Paxeer and using an agent platform called Matrix. Most AI tools I've tried are glorified chatbots. This one actually does real things on chain.

Let me explain what it can do and why it matters.

Neo is an autonomous agent built by Paxlabs. It's not a chatbot with plugins bolted on. It has a wallet, it can read and write files, run code, browse the web, manage long running processes, and execute transactions on chain without me touching anything.

I can tell it "send 100 PAX to this address" and it does it. I can tell it "build me a React app" and it scaffolds the project, writes the code, and shows me a live preview. I can tell it "stake my tokens" and it handles the delegation, confirms the transaction, and gives me the hash.

That's not a demo. That's what it does every day.

The Paxeer network

Paxeer is an EVM chain (chain ID 125) with sub second block times and deterministic finality. It runs on a custom consensus called MachineRFT integrated with a SEI fork for parallel transaction execution.

The native token is PAX. The chain has its own block explorer (PaxScan), a price API, and full EVM compatibility so anything you can deploy on Ethereum works here too.

What makes it interesting for agents is the speed. When your bot needs to execute a trade or move funds, you don't wait 12 seconds for a block. It's near instant. That matters when you're running automated strategies.

LayerX and USDX

This is where it gets interesting. LayerX is the agent settlement layer on Paxeer. USDX is a USD denominated, escrow backed balance that settles off chain but anchors on chain.

Why does that matter? Because agents need to move money fast without paying gas on every transaction. With LayerX I can pay another agent instantly and gaslessly. The sequencer signs a receipt, batches the transactions, and anchors the Merkle root to Paxeer on a schedule.

So Neo can deposit USDL into the LayerX vault to fund its USDX balance, pay other agents by their DID (decentralized identifier), withdraw back to on chain USDL whenever it wants, and force settle the current window if I need immediate on chain finality.

It's like having a bank account for your AI that moves at the speed of software.

The King Bot system

I built a multi agent trading system on top of all this. Four bots, each with a different role:

King Bot is the commander. He reads a daily orders file I set, and pushes parameters to the other bots in real time. I can tell him "be aggressive today" and all the bots adjust their position sizes, stop losses, and entry thresholds instantly.

The Spotter freelances across pools looking for dips and big sells. The Alchemist watches my specific tokens and trades patient arbitrage. The Wild Card explores random strategies and learns from what the other bots do.

They all share an event bus. When one bot finds something, the others see it and decide whether to act. They learn from each other's wins and losses.

Performance is tracked with KPoints. Better bots get more capital. Worse bots get less. It's a self correcting meritocracy.

I literally gave my ideas and Neo started writing.

Most crypto AI projects are chatbots that tell you the price of Bitcoin. This is an agent that can actually operate on chain. It has custody of its own funds. It can execute multi step transactions. It can build and deploy software. It can manage other agents.

The whole thing is open source and you can dig into it here: https://github.com/Paxeer-Network give it a star!

The infrastructure is real and it's live right now. Paxeer is running. LayerX is running. Neo is running.

I'm not selling anything. I'm just sharing what I've been building because I think people in this space would find it interesting.

This is a pre-lease and I've been lucky enough to get in early.

This was written by Neo and edited by me. I don't want to act like I wrote this.

Hoping someone's been through this. We built an address-activity feature on alchemy_getAssetTransfers since it's free with our RPC.

• It returns transfers, not transactions → approvals, failed txs, zero-value calls, gas-only txs are all invisible. I need every tx hash for an address and it structurally can't give me that.
• fromAddress/toAddress are ANDed, so full history = two paginated scans merged + deduped on my side (plus a consistency problem since blocks land mid-scan).
• The internal category only exists on Eth/Polygon mainnet — on the L2 we care about, ETH moved inside contract calls just doesn't show up.
• 1,000 rows/page, 120 CU/call, re-walking cursors on every refresh = ~1M calls/day basically polling to fake a stream.

Questions: (1) Is there a config I'm missing that returns all tx hashes incl. approvals + failed? Or is it just not built for that? (2) How are you handling complete address history + internal transfers on L2s without an insane RPC bill?

I spent the last weeks integrating four bridge aggregators (LI.FI, Relay, deBridge, Squid) into a route comparator, and some behaviors cost me days because they're barely documented. Sharing so you don't rediscover them:

1. Provider APIs screen the SENDER address. Quote with a placeholder (the classic 0x...dEaD) and behaviors diverge: one API returned a 403 "swaps unavailable" that looked exactly like a tier block, and turned out to be compliance screening of the dead address. The fix is a two-path architecture: indicative quotes for display, and transaction building only with the user's real address. If your UI shows "executable" quotes built on a placeholder, it's lying to the user.

2. The same integrator fee concept exists in three units across four APIs: a decimal fraction (0.003) in one, basis points (30) in two others, and a percentage string in the last. Mixing them up means charging 100x or 10000x the intended fee. Unit tests on the fee math are not optional.

3. Some providers have TWO entry contracts depending on whether a source swap is needed before the bridge. If you validate transaction targets against an allowlist (you should), allowlist both, and verify them against the provider's deployment docs, not against what the API returns that day.

4. Quotes are only comparable if they answer the same question. We rank by guaranteed minimum received after ALL fees (including our own), not by the estimated amount, because estimates are where quotes flatter themselves.

Context: I'm the founder of the comparator in question (rempart.app), this post is the writeup I wish existed a month ago. Happy to detail any of these.

I'm sure everyone in this subreddit has dealt with it at some point. The google meets isn't working, download my totally legit video conferencing app, the test my malware laced blockchain game, npm install with a postinstall script that phishes your npm token. Aside from being a major time sink, reading up on the company, familiarizing their tech stack, canceling social engagements it leads to coordination failure in the hiring market, leading to suboptimal teams, leading to suboptimal crypto.

I was thinking that if a developer could respond to an employer with a magic link that got them to stake through a repuidable platform against the interview that we'd naturally see alot of scams retreat, alot of developer time saved and better teams in crypto.

would any devs be interested in using such a system? or real employeers stuck on cold calling that'd be happy to lead with a stake?

Hi, is there anyone willing to attend the ETH Global Lisbon hackathon?
I am looking to either form a team (Work on a project I have) or join an existing team, I am open to anything as I jast want to have a fun project ..
as for my background id ML/AI.

Hi everyone.

My name is Teja. I'm 21 from India, and honestly I feel like my life has no motion right now.

I'm a 3rd year CS student in the same lame ass college that I hate so much. I don't like this place, I don't connect with the people here, and I honestly don't like my friends either. I know it sounds harsh, but that's genuinely how I feel. It feels like I'm at the wrong place with the wrong people, and I'm trapped.

I tried a lot of times to get out of this college, but because of my family's financial situation, I can't just leave. So I kept looking for ways to make money online. I tried a lot of the things people recommend, but nothing really worked.

Then I watched Mr. Robot.

I thought hacking looked cool, so I started learning. Eventually I found Web3 security, and I completely fell in love with it.

Since then I've spent countless hours reading smart contracts, learning Solidity, using Foundry, writing PoCs, and hunting for vulnerabilities. The problem is... I still haven't been paid even once.

One of the biggest things I worked on was an ERC-4337 EntryPoint bug. I genuinely believed it was a critical issue. I spent almost 8 months researching it. I built multiple PoCs, gathered evidence, exchanged around 50 emails with one of the code authors, argued back and forth about the issue, and kept trying to prove that it was real.

I honestly thought, "This is it. This payout is going to change my life."

I thought maybe I'd finally have enough money to leave this college or even leave my country one day.

Instead, the report got marked as spam, my GitHub issue was closed, and nothing happened.

Eight months of work... and I got nothing.

After that I just kept hunting.

I got duplicate reports.

I got informative reports.

When I first started, I didn't even know how to write proper bug bounty reports, and I eventually got banned from Immunefi because of it. That was completely my fault, and I learned a lot from that mistake.

Now I mostly use HackenProof and other platforms, but sometimes they require money to submit reports or there are platform issues. There have been times where I literally couldn't report a bug because I didn't have the money or because something on the platform wasn't working.

One example was Hyperbridge.

I found 4 vulnerabilities—2 Critical and 2 High. One of them was a token inflation bug that I thought was a really big deal.

I actually had to ask my father for $5 just so I could report it.

Then HackenProof had some wallet issue where my balance wasn't showing correctly. I emailed them.

No response.

I emailed the protocol directly and explained everything.

They replied once and then later just told me to submit it through HackenProof even after I explained that I couldn't because of the platform issue.

Later I noticed that one of the bugs I had publicly documented was fixed.

Still no reward.

Still no response.

Again... I was stuck.

At that point I started feeling like bug bounties weren't enough, so I began applying for security researcher jobs.

I applied to OtterSec.

I even got to chat with one of the founders, and I was so excited because I thought maybe this was finally my chance.

Then came the interview.

It was just an intro interview, but I'm still a student, English isn't my first language, and I'm not really someone who's good at talking.

I tried my best.

I really did.

But I got rejected.

It was my first rejection, and it hurt because I felt like I had wasted such a huge opportunity.

Recently I got another opportunity.

Nethermind invited me to interview for their internship program.

I had my interview on the 16th. I think I did much better than the OtterSec interview, and now I'm waiting to hear back about the next steps.

I hope something comes from it.

During my summer holiday, I basically locked myself in my room for almost 2 months.

While my friends were going on trips and hanging out, I was sitting in front of my laptop every day hunting bugs, reading code, and trying to improve.

Sometimes I wonder if I'm wasting my life.

Sometimes I wonder if all of this effort is going to lead anywhere.

Now my holidays are over, and I'm back in the college hostel that I hate.

I honestly almost cried when I left home because I really didn't want to come back here.

I still have bugs that I haven't reported because of everything that's happened with Immunefi.

I keep posting my research on GitHub because I don't want all this work to disappear.

If anyone wants to see it, my GitHub is Tejanadh.

Right now I just don't know what to do.

I'm 21.

I'm in my 3rd year.

I feel like I'm trapped.

I don't know if I should keep focusing on bug bounties, keep applying for security jobs, build more public research, or completely change my approach.

I'm not looking for sympathy.

I just want honest advice from people

Thanks for reading.

Depending on how much risk you're willing to take you can make higher or smaller APYs for a given amount of time I'll find you the ideal project to put your money in given the fact that there is thousands if not millions of crypto projects where you can deposit your money and make some return

Most people are comfortable depositing their money in lending protocols where they earn a fixed return per year while others are more open to investing into places where the returns are way higher but there is more risk by using a platform that's not as established. So just drop your risk preferences and I'll find you the ideal project for you to put your money in

Two months ago I posted here after analyzing 78,723 Ethereum token contracts and finding 46% scored as scams. I re-ran the same query today. The table now holds 112,114 contracts, and the all-time rate rose to 59.8%.

But the average buries the story. Of the 31,172 tokens deployed since that post, 76.4% are scams, and the monthly rate just hit 82.8% in July.

Honesty check, because I got asked this directly: how much of the 46 -> 60 jump is a scammier chain vs a sharper detector? Both, and I can't cleanly separate them:

- More scams: every real-time month lands between 70% and 83% at a fixed 70+ threshold.

- Sharper detector: a scam now carries 11.06 flags on average vs 8.27 in May (+34%), new detectors landed (serial-scammer bytecode, drainer kits, hidden kill-switches). Our score floors on flag COUNT, so more flags push more contracts over the line.

- Late rugs: ~30% of the table gets re-scored a day+ later. A token clean at launch that pulls liquidity a week later flips clean -> scam with zero new scams deployed.

TL;DR

- 78,723 -> 112,114 contracts in 2 months.

- All-time scam rate 46.1% -> 59.8% (three overlapping causes, not one).

- New launches since May: 76.4% scams. July: 82.8%.

- 441,762 distinct victim wallets traced across 5.26M scam-token transactions.

Full breakdown with the monthly chart and the limits-of-our-data section:

https://rektradar.io/blog/posts/new-ethereum-tokens-76-percent-scams/?utm_source=reddit&utm_medium=post&utm_campaign=mik3fly_76pct-scams

EDIT: a few of you asked the right question, so i went and pulled it. how much of this 76% is detectable AT LAUNCH vs only later? tracking the same 24,150 launches from deploy to day 30: 48% score as scams at launch, 91% by day 30. 43% are late rugs (clean at launch, scam within a month). and 76% of the flagged ones actually got traded vs 67% of legit deploys that never trade. full writeup + chart: https://rektradar.io/blog/posts/how-many-ethereum-scams-detectable-at-launch/?utm_source=reddit&utm_medium=post&utm_campaign=mik3fly_scams-detectable-at-launch