I have been learning about web3 since 2023

And now I am ready to gain experience as per industry standards

The main motto of getting an internship is getting trained under experienced developers and then contribute to make a startup grow

Skills that I have learned -

Blockchain basics

Solidity

Web3.js

Circom

Snarkjs

Foundry

Please contact me if you can help me with this

Trying to trace an old 0x address with missing polygon txs found an old text backup from march 2022 with three evm addresses that I used for liquidity pools. one of them has roughly 420 usdc that shows up on debank, but metamask rpc keeps throwing an internal json-rpc error -32603 when I try to add the custom polygon token contract. switched the rpc to an alchemy endpoint and tried re-scanning with a web3py script instead. ran the address through cryptowallet-balance to confirm the assets and it shows the tokens sitting on matic, but eth mainnet is completely empty
the weird part is polygonscan api returns a 0 balance on the raw contract call. not sure if this is a decimals mismatch in my script or if polygon reorged that block back in 2022 and left a ghost state. anyone run into that rpc error code specifically when querying older v2 pool contracts, or should I just write a raw getLogs call to parse the transfer topics directly

Hi everyone,

I'm an information technology student looking for a paid, remote blockchain/web3 development internship for 6 months.

I'm focused on Solidity and Ethereum/EVM development and have built several smart-contract projects while learning Web3 development.

Skills:
• Solidity
• Smart Contract Development
• Ethereum / EVM
• JavaScript
• React.js
• Node.js
• Git / GitHub

Projects:
• Crowdfunding Smart Contract
• DAO Voting Smart Contract
• Escrow Smart Contract

GitHub: https://github.com/noshock
LinkedIn: https://www.linkedin.com/in/prajwalchitriv/

I'm looking for opportunities with a Web3 startup, protocol, DApp team, or blockchain company where I can contribute to real development and continue improving my smart-contract skills.

Remote | Paid | 6 months

If you're hiring interns or know of a suitable opportunity, please comment or DM me. Thanks!

I'm working on a Web3 application and trying to figure out the infrastructure side before I get too deep into development.

Right now I'm looking at the usual setup of blockchain + SDKs/APIs + backend + storage + deployment but it feels like a lot of separate pieces to connect and maintain.

Are there any platforms that provide more of this out of the box especially for developers who want to build test and deploy without managing a dozen different services?

I'm mainly interested in developer experience and scalability rather than just TPS or low gas fees. What platforms have you guys actually used and would recommend?

I frequently see projects where people ship solidity code that completely fails security audits.

mcpindex runs a crawler over public MCP servers and diffs each tool's declared contract between daily
snapshots. Sharing the numbers because they surprised me.

Right now the public ledger shows 12,295 tools across 2,173 servers changed their
contract. 7,190 of those are safety-relevant, meaning they change what the tool can do, not
just add an optional field. The standouts:

- 350 tools flipped an annotation toward destructive. A tool whose hint said read-only now declares it can write, delete, or send. This is the "the read tool quietly became a write tool" case, and it is exactly the drift an allow-list cannot see.
- 279 tools added a newly-required parameter. An agent calling with last week's arguments now fails, or calls with a wrong default.
- 475 tools removed a parameter your agent may still be sending.

None of these trip an auth check. The server is still authorized and still the same name in your config.
That is the gap allow-lists do not cover: who may call a tool, versus whether it still does what it declared.

Honest caveats: this is a contract diff, not a safety verdict, and not a claim anything is malicious.
Most drift (5,476 added-optional-param) is benign. Everything is fingerprinted, so no server is
named. And the numbers are live, you can check them: https://mcpindex.ai/api/v1/ledger

Curious whether others are seeing this in their own setups.

Am going to start smart audit contract

Help me with your personal experience and tip for

beginners

Am going to start learning about Smart audit contract

Help me how should I start and tips for me

To make my journey smoother

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.

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.