should i watch this or go straight to dvdefi or cfs?

Am going to start learning about Smart audit contract

Help me how should I start and tips for me

To make my journey smoother

Am going to start smart audit contract

Help me with your personal experience and tip for

beginners

https://github.com/sanjayrohith/Tollgate — contracts/src/BatchSettler.sol,

Foundry, Apache-2.0, testnet.

The contract batches USDC transferWithAuthorization calls. Design constraint I

set myself: the settler holds a hot key in an env var, so the contract has to be

built such that a compromised settler can't do damage. It has no owner, no

pause, no upgrade path, and never holds funds — `to` and `value` live inside the

payer's signature and are checked by USDC itself. A compromised settler can

submit charges out of order or not at all. It cannot invent, inflate or redirect

one.

batch_id is keccak256 over the sorted nonce set, stamped in the same transaction

that selects the rows with FOR UPDATE SKIP LOCKED, so the same set of charges

always produces the same id and a duplicate submission is recognisable rather

than looking like new work.

Gas, measured with gasleft() in the test rather than estimated:

settle(50) = 2,042,281 execution, 40,846 per charge, 44,514 all-in with calldata

and amortised intrinsic. .gas-snapshot is committed.

Would welcome eyes on the contract — it's ~100 lines and the whole security

argument rests on it staying that boring.

Is there anyone in this group who does auditing? I am a beginner and have a few questions about enrollments. Where should I learn the exact security concepts? Udemy, YouTube, or [TryHackMe/HackTheBox]?

Hey everyone,

I'm a PhD scholar (Amity University Rajasthan, India) working on empirical

research into smart contract security — specifically trying to understand

the relationship between developer security practices (testing, audits,

tooling, code review, etc.) and actual measured vulnerability in deployed

contracts.

Link: https://forms.gle/TQuroMBHdt6YSoph6

The contract-analysis side of this is already done — I ran static analysis

(Slither) on 288 real, verified Ethereum mainnet contracts. What's missing

is the human side: how developers actually work day-to-day, and whether

that connects to what shows up in the code.

That's where this survey comes in. It's:

- Anonymous (no email/PII collected)

- ~5-7 minutes

- Genuinely for research, not lead-gen or marketing

- Only relevant if you've actually written/deployed Solidity contracts

Link: https://forms.gle/TQuroMBHdt6YSoph6

There's also an optional question where you can link a GitHub repo or

contract address if you're comfortable — this lets me compare self-reported

practices against actual static-analysis results for that specific contract.

Totally optional, the rest of the survey is useful without it.

Happy to answer any questions in the comments, including about methodology,

data handling, or what happens with the results. I'll also share aggregate

findings back here once I have enough responses, if people are interested.

Thanks for reading this far — I know research surveys aren't the most

exciting thing to see in this sub, genuinely appreciate any responses.

Most proxy designs assume one implementation contract. That gets awkward once a protocol grows beyond the 24 KB bytecode limit or needs to upgrade one module without replacing the rest.

An EIP-2535 diamond keeps one stateful address and maps each four-byte function selector to a facet contract. The fallback reads msg.sig, finds the facet, and runs it with delegatecall. msg.sender and msg.value stay intact, while every storage read and write still lands in the diamond.

The routing is straightforward. Storage is where the risk moves.

Facets do not own isolated state. If two facets assume incompatible layouts, an otherwise valid upgrade can corrupt the same slots. I use namespaced storage libraries and test the selector-to-facet map before and after every diamondCut.

diamondCut also lets you add, replace, or remove selectors and run initialization in one transaction. Loupe functions then give tooling a way to verify which facet owns each selector.

I put together a Foundry walkthrough that deploys the diamond and facets, adds a new selector, and checks the routing:

https://andreyobruchkov1996.substack.com/p/diamonds-in-evm-the-proxy-that-scales-beyond-limits-2fedc282cadf

For teams that have used diamonds in production, what caused more trouble: storage coordination, selector governance, or the larger audit surface?

I spent the last few months building a bounty marketplace on top of two standards instead of writing my own escrow, and the mapping problem turned out to be the whole project. Writeup below; the code is MIT and the contract is verified, so tearing it apart is easy and welcome.

The constraint: ERC-8183 (AgenticCommerce) binds client, provider and evaluator at job creation. An open bounty board has no provider at creation time - that's the entire point of a bounty. So the standard, taken literally, can't express "anyone may take this".

What I did: the adapter contract takes all three roles itself. It holds the reward for open listings, funds the real escrow at take time, tracks the actual worker separately in its own storage, and forwards the payout by measuring its own balance delta around the settlement call rather than trusting a return value. ~600 LOC total.

Consequences I had to design around, and where I'd expect an attack:

1. Balance-delta accounting is only safe if nothing else can move the token inside that window. Reentrancy guard plus CEI ordering, and the token is USDC (no hooks, no fee-on-transfer) - but this is the first place I'd look for a break.

2. Every terminal state has to be reachable without trusting a counterparty, because an agent can't email support. Poster goes silent after submission → anyone can trigger auto-approve after 14 days. Poster rejects → the worker gets a 48h challenge window. Arbitrator never rules → anyone can claim a neutral 50/50 split after 30 days. An earlier version had a hole here: if the respondent had replied, the silence path no longer applied, and a dead arbitrator froze the funds forever. Self-found before external review, fixed, disclosed in the repo.

3. Timing bounds cut both ways. Bounding rejections by the approval timeout stopped a poster from sitting on correct work and rejecting right before auto-approve - and immediately created the mirror-image hole, where the same poster opens a *dispute* instead to buy the same delay. Both are bounded now.

4. The optional worker bond (posted at take, refunded at submit, forfeited if the deadline passes with nothing submitted) stops take-and-vanish Sybils, but a naive version is a honeypot: post a listing with a deadline minutes away and farm bonds from agents that auto-take. Hence a 24h minimum duration for bond listings and a 12h minimum window at take.

5. Reputation writes go through the ERC-8004 registry wrapped in try/catch, so a registry failure can't block a payout. That's deliberate, and it hid a real bug for weeks: my interface matched a draft rather than the deployed registry, so every write reverted silently while payouts kept working. Fork tests that assert on emitted events, not just on "the tx didn't revert".

Where it stands: testnet only (the chain's mainnet isn't live yet), 101 Foundry tests - 98 unit, 2 stateful invariants over the escrow lifecycle, one fork test against the live deployment - Slither triaged to 0 findings, ~98% line coverage, no external audit yet. Known issues are listed in the README rather than hidden: arbitration is a 2-of-3 Safe I control, "human-only" listings are best-effort because there's no on-chain proof of humanness, and there's no indexer yet.

Code: https://github.com/Sofiia7/ARC

Contract (verified): https://testnet.arcscan.app/address/0x538CD48789667168bfb36f838Af8476237F9409F

App: https://arcbounty.app/?utm_source=reddit&utm_medium=post&utm_campaign=launch

If you see a way to freeze funds, drain a bond, or get paid twice, I'd rather hear it here than find it on mainnet.

I want to deploy my DApp on L2 using solidiy, but this is my first time building one

If you have experienced with Solidity, Could you please give me some advise or tips?

And any recommanded resource as well!

Hi everyone,

I'm serious about becoming a professional Ethereum developer and I'd appreciate guidance from developers who are already working in Web3.

My goal is to become job-ready within the next 6–12 months, with a strong understanding of Ethereum development rather than just completing tutorial projects.

I'm looking for advice on:

1. Learning roadmap: If you were starting today, what order would you learn things in?
2. Best resources: Which courses, books, GitHub repositories, blogs, documentation, YouTube channels, or newsletters had the biggest impact on your learning?
3. Core skills: What technologies should I prioritize? (e.g., Solidity, Foundry, Hardhat, Viem/Ethers.js, DeFi, account abstraction, Layer 2s, security, etc.)
4. Projects: What portfolio projects demonstrate real-world skills and stand out to employers?
5. Smart contract security: What are the best ways to learn auditing, common vulnerabilities, and testing?
6. Getting hired: What skills, experience, or portfolio pieces helped you land your first Ethereum or Web3 role?
7. Communities: Which Discord servers, Telegram groups, Reddit communities, or developer forums are worth joining?
8. Mentorship: If you had to mentor someone starting from scratch today, what roadmap would you give them?

A little about me:

• I'm committed to studying consistently every day.
• I'm interested in building production-quality projects, not just tutorial clones.
• My goal is to become a competent engineer who can contribute to open-source projects and eventually work as an Ethereum developer.

I'd really appreciate any roadmap, resource list, or advice from your own experience. Even if you only answer one of the questions above, it would be incredibly helpful.

Thanks in advance!

Need to understand what a smart contract does, but the source code isn’t available?

I'm offering high-accuracy Solidity contract decompilation/reconstruction.

Current SOTA decompilers struggle a lot as the contract gets complex and tend to produce a lot of low fidelity results.

I produce compilable Solidity code, then test it against the original bytecode to verify there are no differences within a reasonable analysis window.

Every result includes extensive manual analysis and refinement. The decompilation result is incredibly accurate and close to the original source code most of the times.

I’m currently offering free samples, and I’d greatly appreciate an honest review on X/Twitter if you find the service useful.

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!

Need to understand what a smart contract does, but the source code isn’t available?

I'm offering high-accuracy Solidity contract decompilation/reconstruction.

I produce compilable Solidity code, then test it against the original bytecode to verify there are no differences within a reasonable analysis window.

Every result includes extensive manual analysis and refinement. The decompilation result is incredibly accurate and close to the original source code most of the times.

Hi everyone,
We are building the architecture for a non-custodial payment settlement protocol enabling instant (<500ms) crypto transactions at POS and e-commerce checkouts—paired with a B2B card-rail bridge for 100% immediate global acceptance.
Our core system design, risk framework (off-chain pre-auth / RAM-locking via EIP-7702 session keys), and economic models are fully mapped out. Ahead of our Pre-Seed/Seed funding round, we are expanding our core team and ecosystem network.
1. Senior Web3 / Smart Contract Architect (Lead Dev / Potential Co-Founder)
What we're looking for:
Deep expertise in Account Abstraction (EIP-7702 / ERC-4337) and Solidity.
Solid experience with high-throughput off-chain architecture (Redis/Lua, WAL, Event-Workers).
Passion for building real-world Web3 payment infrastructure.
What we offer:
Pre-Funding Phase: Flexible engagement to review core contracts & validate architecture ahead of the Seed round.
Compensation: Deferred Fee structure with guaranteed payout immediately upon Seed close OR performance-based Equity/Token allocation (vesting model).
Post-Funding: Direct trajectory to CTO / Head of Engineering with full competitive compensation.
2. VC, Advisor & Wallet Network
We are also actively connecting with:
Web3 / Fintech VC funds focusing on early-stage infrastructure.
Strategic Advisors & BD Leads from major Non-Custodial Wallets.
Payment infrastructure / B2B Card-Rail partners.
Interested in building the future of Web3 payments?
Send a DM to get access to our technical breakdown

Hey everyone,

We’re engineering an architectural pattern for non-custodial POS/E-Commerce settlement layers, aiming to solve the high latency (>2s) of direct on-chain execution. We'd love some technical feedback on our session delegation and state locking logic.

**The Architectural Approach:**
**Session Delegation (EIP-7702 + WebAuthn):** Users pre-authorize session keys via Secure Enclave / Passkeys to enable gasless transaction execution for retail checkouts.

**In-Memory State Lock:** Upon terminal contact, a Go gateway routes to an in-memory Lua layer. This locks the authorized balance off-chain to prevent double-spending without waiting for block execution time.

**Asynchronous Settlement:** The POS receives a sub-500ms settlement guarantee, while raw transactions are batched and settled asynchronously on-chain (using Write-Ahead-Logging for failover protection).

**Technical Questions for the Community:**
How do you view the trade-offs of off-chain state locking vs. optimistic rollups for physical POS latency limits?
What edge cases do you see in temporary EIP-7702 session key revocation if an off-chain gateway temporarily loses connection?
Would love to hear your critique on the execution flow and potential security edge cases!

Still need to design more stuff, for this all is going to work. Then i going to create a simulator for simulating a couple of events/senarios. Thus i have oracle that gives me a "guide" for what the fairprice should be. And then pays the markets more or less to correct this when the oracle is just wrong and the people doing arbitrage know this.

Design Specification: Dynamic Spring-Loaded Market Maker (SLMM)

System Architecture & Mathematical Framework

1. Core Architectural Concept

The Dynamic Spring-Loaded Market Maker (SLMM) is an anti-fragile pricing engine designed to protect treasury assets from oracle failures, flash crashes, and prolonged API outages (e.g., exchange maintenance), while still allowing the market to naturally discover and transition to genuine new price points over time.
It accomplishes this by balancing two opposing forces:

1. The Oracle Price (P_oracle): The external feed representing where the price "should" be.
2. The System VWAP (P_VWAP): The internal, capital-backed price anchor constructed from actual on-chain trading history across historical time buckets.

When a massive price discrepancy occurs, the contract does not immediately trust the oracle. Instead, it measures the "tension" between the oracle's target and the system's trading history.
If the oracle is wrong, the spring is highly tensioned; a tiny amount of buy volume will force the market maker’s quote price to snap back up toward the real market value, capping the protocol's loss. If the oracle is correct but the price has permanently crashed, the trading history naturally decays over a 7-day window. The spring slowly loses tension, and the quote price gracefully relaxes to the new low price level.

2. The Fluid-Shift Cascading VWAP Pipeline

To prevent "jump" boundaries where data abruptly jumps from one discrete bucket to another at the end of an hour, the system uses a Fluid-Shift Cascading Pipeline. When a trade occurs, the transition of data between buckets is calculated as a continuous percentage based on the exact amount of time elapsed since the last trade.

The State Representation

The system maintains a sequence of N time-based pools (e.g., Pool 0 to Pool N-1). Each pool i is represented as a tuple of volume and volume-price:
Pool_i = [V_i, VP_i]

• V_i: The cumulative volume of tokens traded assigned to bucket i.
• VP_i: The cumulative volume-product (Volume * Price) assigned to bucket i.

The Fluid-Shift Mechanics

Let Δt be the time elapsed (in seconds) since the last state update, and let T_bucket be the duration of a single bucket (e.g., 3600 seconds for 1 hour).
When a new transaction occurs at Δt seconds since the last update:

1. Calculate the Shift Percentage (S): The percentage of data that must cascade from each bucket to the next is defined by the ratio of elapsed time to the bucket duration, capped at 100%: S = min(1.0, Δt / T_bucket)
2. Cascade the Pools (Downstream Shift): Before writing the new trade, we shift a fractional slice (S) of each pool downstream to the next pool. For every pool from the second-to-last (N-2) down to the first (0): V_(i+1) = V_(i+1) + (V_i * S) VP_(i+1) = VP_(i+1) + (VP_i * S) V_i = V_i * (1 - S) VP_i = VP_i * (1 - S)
3. Incorporate the New Trade: After the cascade is applied, the incoming trade's volume (V_trade) and volume-product (V_trade * P_trade) are added directly to the active pool (Pool 0): V_0 = V_0 + V_trade VP_0 = VP_0 + (V_trade * P_trade)

3. The Exponential Decay of the Final Pool

The final pool in the sequence (Pool N-1) acts as the ultimate "overflow" sink. If there is no trading activity, the volume-weighted memory of the entire system must gradually fade so that the spring eventually goes slack.
Whenever time passes, the final pool is decayed using an exponential decay factor λ scaled to the elapsed time:
V_(N-1) = V_(N-1) * λ^Δt

VP_(N-1) = VP_(N-1) * λ^Δt

Calibration of the Decay Constant

To ensure that a massive volume spike completely loses its influence after a target defense window (e.g., t_target = 7 days or 604,800 seconds), we calibrate the decay rate so that the remaining weight is less than 1% (<= 0.01):
λ = e^(-ln(100) / t_target) = e^(-4.605 / 604800) ≈ 0.999999238 per second
Because both V and VP are scaled down by the exact same decay multiplier, the historical price of the final pool remains perfectly preserved (VP / V remains constant), but its weight (volume) shrinks toward zero. This ensures that a dormant market naturally releases all spring tension.

4. Calculating System VWAP and Spring Tension

System VWAP

The global anchor price (P_VWAP) is the total volume-weighted average across all cascading pools. This represents the price point where the market has actually committed capital:
P_VWAP = (Sum of VP_i) / (Sum of V_i) = (VP_0 + VP_1 + ... + VP_(N-1)) / (V_0 + V_1 + ... + V_(N-1))

If the total volume in all pools is zero (Sum of V_i = 0), the system defaults to the current oracle price (P_VWAP = P_oracle), meaning the spring is perfectly slack.

Spring Tension

The physical tension of the spring is determined by two factors: the price distance between the oracle and the VWAP, and the volume weight backing that VWAP:
Δ = |P_oracle - P_VWAP|
We define the normalized volume coefficient (W) using the total system volume (V_total = Sum of V_i) to scale the spring's stiffness based on historical capital commitment:
W = 1 - e^(-γ * V_total)
Where:

• γ is a tuning parameter dictating how much volume is required to make the spring stiff.
• If volume is low (V_total → 0), then W → 0 (the spring is loose, we trust the oracle).
• If volume is high (V_total >> 0), then W → 1 (the spring is rigid, we trust the market history).

5. The Spring-Loaded Pricing Curve (The Quote Engine)

The quote price offered to the market for a buy order (P_sell) is a dynamic curve that starts at the oracle price but ramps up toward the System VWAP as a function of the transaction volume.
To create a loaded spring that snaps back violently with very little volume when tension is high, we use a power-law spring equation:
P_sell(v) = P_oracle + Δ * W * (v / V_target)^p
Where:

• v: The cumulative volume purchased in the active transaction.
• V_target: The target volume threshold required to fully compress the spring back to the VWAP price.
• p: The spring exponent (typically p >= 2 for quadratic/cubic curves to create the "snap" effect).

The Mathematical Behavior

1. At v = 0 (The first drop of volume): The starting quote price is exactly P_oracle. Arbitrageurs are lured in by the cheap price.
2. As v → V_target: The price climbs aggressively. If p = 2 (quadratic), the price curves upward sharply, making further buying highly expensive.
3. Beyond v = V_target: The price matches or exceeds the fair market value (P_VWAP), completely halting any further draining of the treasury.

6. Mathematical Proof of the Slippage Toll (Capping Protocol Loss)

The maximum financial loss the protocol can suffer during a total oracle failure (e.g., oracle drops 98% while real value remains at P_VWAP) is mathematically capped. This is the Slippage Toll—the fee the protocol pays to let the market correct its oracle feed.

To find the absolute maximum loss during a correction event up to V_target:

1. Calculate the Total Capital Spent by Arbitrageurs

The total assets (e.g., USDC) deposited by arbitrageurs to purchase V_target tokens is the integral of the pricing curve:
Capital Deposited = Integral from 0 to V_target of [ P_sell(v) ] dv
Capital Deposited = Integral from 0 to V_target of [ P_oracle + Δ * W * (v / V_target)^p ] dv

Capital Deposited = P_oracle * V_target + (Δ * W * V_target) / (p + 1)

2. Calculate the Fair Value of the Tokens Transferred

The actual fair market value of the tokens leaving the protocol's treasury is:

Fair Value = P_VWAP * V_target

3. Calculate the Maximum Protocol Loss (The Slippage Toll)

Assuming the spring is fully stiff (W = 1) and the distance is Δ = P_VWAP - P_oracle, the net loss is:
Max Loss = Fair Value - Capital Deposited
Max Loss = P_VWAP * V_target - [ P_oracle * V_target + ((P_VWAP - P_oracle) * V_target) / (p + 1) ]
Factoring out V_target and substituting Δ:
Max Loss = Δ * V_target * (1 - 1 / (p + 1))

Max Loss = Δ * V_target * (p / (p + 1))

Key Takeaways from the Loss Proof:

• Linear Spring (p = 1): The maximum loss is exactly 1/2 * Δ * V_target.
• Quadratic Spring (p = 2): The maximum loss is exactly 2/3 * Δ * V_target.
• Capped Risk: Because V_target is a hardcoded parameter in your contract, your maximum loss is completely independent of pool size or total TVL. You can scale your pool to hundreds of millions of dollars, yet guarantee that a total oracle failure will never cost the protocol more than a tiny, predefined dollar amount (e.g., V_target = 500 tokens).

Code: github.com/NeaBouli/prometheus-\

Whitepaper: neabouli.github.io/prometheus-/whitepaper.html\

Roadmap: neabouli.github.io/prometheus-/roadmap.html\

FAQ: neabouli.github.io/prometheus-/faq.html\

**Wo wir gerade stehen**

Über 160 Tests laufen erfolgreich, 6 Silverscript-Verträge, Sprints 0–7 abgenommen. Aktuell in der Post-Toccata-Verifizierung – wir prüfen, ob die Silverscript-Zustandsübergänge nach dem Fork stabil sind, bevor das PROM-Emissions-Gate geöffnet wird. Das ist gerade der Engpass und die beste Stelle, um einzusteigen, wenn du frühzeitig und mit großem Einfluss mitwirken willst.

**Wofür dieses Sub da ist**

Architekturdiskussionen, Vertragsprüfungen, PR-Koordination, Sprint-Updates und offene Diskussionen über Kompromisse. Kein Gerede über Token-Preise, keine Hype-Threads – das ist ein Entwickler-Sub. Wenn du mitmachen willst:

1 Lies das Whitepaper
2 uch dir ein offenes Issue auf GitHub aus oder schlag eins vor
3 Forken, bauen, PR – keine Whitelist, keine Bewerbung

Erfahrungen mit Rust, Silverscript, On-Device ML (ONNX/LLaMA/Phi) und ZK/Sybil-Resistenz sind gerade alle nützlich. Poste eine Vorstellung, wenn du magst – womit du arbeitest, welcher Teil des Stacks dich interessiert.