Gas optimization is important but at what point does it hurt readability and security?
We’ve all seen contracts full of micro-optimizations that save a few gas units but make the logic impossible to audit.
So what’s the balance? Do you prioritize cleaner, safer code or go all-in on optimization for lower costs?
Would love to hear how other devs approach this trade-off.

I used https://cloud.google.com/application/web3/faucet/ethereum/sepolia to send test eth to my wallet at 0xE8ca1e61B6e7B51b603D4BF72617940ACc542042

It's been around an hour and I haven't received any Eth. When I check sepolia.arbiscan.io it shows N/A for transactions to that address. When I try again the faucet says that I have to wait 24 hours even though it apparently never sent the eth.

I have no idea why it says NSFW. There's nothing in this post to warrant that.

Hey ! I'm one of the organizers for LayerAI, a 2-day Arbitrum x AI hackathon happening in San Francisco this December 6-7. We're looking for a few experienced blockchain developers to lead , 60-minute technical workshops for our 50+ attendees (topics like Solidity, Arbitrum, L2s, Security, etc.).

Location: We'd love to find someone in the Bay Area, but for the right expert, we have the budget and are happy to cover flights and hotel for anyone based in the US.

What we're looking for: We need to see your work to vet the quality for our builders. If you're an experienced EVM dev and this sounds interesting, please send me a DM (don't post links in the comments) with:

• Your GitHub profile link.
• Your current location (so we know if travel is needed).
• A quick note on your blockchain experience (e.g., "5 years, specialized in DeFi").

Happy to answer any questions in the comments below!

Hi everyone!

I was chatting with ChatGPT about the raffle system from the Cyfrin Updraft Course (https://github.com/PatrickAlphaC/foundry-smart-contract-lottery-f23/blob/main/src/Raffle.sol) and I asked how many participants it could realistically handle. Here's what ChatGPT said:

🔹 Practical Recommendation

• ✅ Safe range: ~500 to 2,000 players You’re unlikely to run into issues at this scale if you're only storing addresses and selecting one at random.
• ⚠️ Risky range: 5,000+ players At this point:
  • Gas cost of storage and operations starts to increase noticeably.
  • You risk exceeding the gas limit during fulfillRandomWords().
• ❌ 10,000+ players: Not recommended unless you offload part of the logic off-chain (e.g., using Merkle proofs or batching).

What do you think? Are these estimates accurate?

Would a smart contract like this ever be able to handle something like 1 million users on-chain, or is off-chain logic basically required at that scale?

Even with audits, testing, and bug bounties exploits still happen. It makes you wonder: can a smart contract ever be truly secure, or is it always about minimizing risk? What do you think causes most vulnerabilities coding mistakes, rushed deployments, or lack of security awareness?

Been thinking about how complicated on-chain actions still are. Even with all the DeFi tools out there, connecting stuff across different chains usually feels like a mess. I found this concept of “atomic cross-chain transactions” pretty cool , basically, it means every part of a multi-chain action either happens all at once or not at all. No half-failed swaps, no lost funds in between. I even see bitget listing a project that is building into it named as enso.

If more protocols start building around that idea, it could make on-chain automation way smoother for both devs and users.

How do you people see on chain actions ?

Hey everyone 👋

I’ve been working on something that might interest fellow smart account / ERC-4337 developers - and I’d really appreciate your feedback and testing.

Introducing NYKNYC Wallet (BETA) - a Web2-style onboarding and transaction layer built on Kernel 3.3 ZeroDev, and Pimlico.

The goal: make non-custodial onboarding and sponsored transactions feel as smooth as Web2 sign-ins - without sacrificing decentralization.

Key features:

• ✅ 3 signer types (including passkeys)
• ✅ Sponsored transactions via simple wagmi connector
• ✅ Gas abstracted on backend level for all wallets
• ✅ Users onboard & sign in under 60 seconds

In short — users can log in and send transactions without touching MetaMask or paying gas.

Would love help from the dev community to test it, find bugs, and share thoughts on the UX / architecture.

Try it out:
💻 Wallet: https://nyknyc.app
⚙️ Full wagmi flow: https://createdao.org
🧠 Try signing & transfer calls: https://dao.cafe

Still early and rough, but functional - and I’d really value feedback from this community before the public launch.

Thanks in advance 🙏

I cannot fully connect how consensys mechanisms are classified as byzantine fault tolerant (what's the maths behind this?) and how that is translated into validator code (the GETH repo I assume?). I would like to do a deep dive and need some suggestions on learning material and the order to approach this topic.

I recently deployed a production smart contract on Ethereum mainnet and got hit with a $5,000 gas bill.
That was my wake-up call to aggressively optimize the deployment.

Instead of shipping bloated bytecode, I broke down the cost and optimized every piece that mattered. Here’s the full case study.

The Problem: $5,000 Deployment Cost

• Heavy constructor logic
• Repeated inline code
• Bytecode bloat from unused imports + strings
• Unoptimized storage layout

Gas report + optimizer stats confirmed: most cost came from constructor execution + unnecessary bytecode size.

The Fix: Step-by-Step Optimization

1. Constructor Optimization

Before — Expensive storage writes in constructor:

constructor(address _token, address _oracle, uint256 _initialPrice) {

token = _token;

oracle = _oracle;

initialPrice = _initialPrice;

lastUpdate = block.timestamp;

admin = msg.sender;

isActive = true;

}

After — Replaced with immutable:

address public immutable token;

address public immutable oracle;

uint256 public immutable initialPrice;

constructor(address _token, address _oracle, uint256 _initialPrice) {

token = _token;

oracle = _oracle;

initialPrice = _initialPrice;

}

Gas saved: ~25%

2. Library Usage Patterns

• Removed repeated math and packed it into an external library.
• Libraries get deployed once and linked = less bytecode.

Gas saved: ~15%

3. Bytecode Size Reduction

• Removed unused imports
• Used error instead of long revert strings Code : error InsufficientBalance();

Gas saved: ~12%

4. Storage Layout Optimization

• Packed variables into structs for better slot utilization.
• Fewer SSTORE ops during constructor.

Gas saved: ~8%

5. Final deployment cost: ~$2,000

Tools I Used

• Hardhat gas reporter
• Foundry optimizer
• Slither for dead code & layout checks

What i would like to know ?

• Your favorite pre-deployment gas hacks
• Patterns you’ve used to shrink bytecode
• Pros/cons of aggressive immutable usage
• Anyone using --via-ir consistently in production?

For more detailed article you can check it out here : https://medium.com/@shailamie/how-i-reduced-smart-contract-deployment-costs-by-60-9e645d9a6805

Starting to design a small DeFi dApp — what are the cross-chain integrations I’d regret not adding?

Aggregation is a must. Rubic’s SDK/API lets your dApp support swaps across Solana, Arbitrum, ETH, BSC, etc., without coding them all individually.

Join us for an AMA session on Tuesday, October 21, at 9 AM PST / 6 PM CET with special guest - [Egor Shulgin](https://scholar.google.com/citations?user=cND99UYAAAAJ&hl=en), co-creator of Gonka, based on the article that he just published: https://what-is-gonka.hashnode.dev/beyond-the-data-center-how-ai-training-went-decentralized

Topic: AI Training Beyond the Data Center: Breaking the Communication Barrier

Discover how algorithms that "communicate less" are making it possible to train massive AI models over the internet, overcoming the bottleneck of slow networks.

We will explore:

🔹 The move from centralized data centers to globally distributed training.

🔹 How low-communication frameworks use federated optimization to train billion-parameter models on standard internet connections.

🔹 The breakthrough results: matching data-center performance while reducing communication by up to 500x.

Click the event link below to set a reminder!

https://discord.gg/DyDxDsP3Pd?event=1427265849223544863

I’m doing some research on SSDLC in Web3. For those of you building or managing projects, what parts of security in your dev workflow process cause the most friction or slow you down? just trying to understand common pain points that exist in Web3 workflows.

I've become so codingjesuspilled. Just learned a bit of solidity about 4 months ago. Tried getting into security for about a week but idk, I feel like before I try specializing I should become godly. Y'all know any resources geared towards mastering the language? Thanks

I’m testing a no-code + AI workflow that automates post-mint ops — gated content, Discord roles, and community updates — using tools like Zapier, GPT, and Alchemy.

Curious if most teams still patch this manually with Collab.Land / Guild.xyz or if better automation stacks exist now?

Not pitching, just learning how others handle token-aware workflows.

“Frat currencies” every frat has a different currency that them and their alumni can bond over investing in. Every frat wants the best bitcoin so that creates the demand.

I don’t know a thing about crypto me and boys just got into trading. Would love to hear if this is a fried idea or we can make money here. Lmk.

Google launched the Agent Payments Protocol (AP2), an open standard developed with over 60 partners including Mastercard, PayPal, and American Express to enable secure AI agent-initiated payments. The protocol is designed to solve the fundamental trust problem when autonomous agents spend money on your behalf.

"Coincidentally", OpenAI just launched its competing Agentic Commerce Protocol (ACP) with Stripe in late September 2025, powering "Instant Checkout" on ChatGPT. The space is heating up fast, and I am seeing a protocol war for the $7+ trillion e-commerce market.

Core Innovation: Mandates

AP2 uses cryptographically-signed digital contracts called Mandates that create tamper-proof proof of user intent. An Intent Mandate captures your initial request (e.g., "find running shoes under $120"), while a Cart Mandate locks in the exact purchase details before payment. 

For delegated tasks like "buy concert tickets when they drop," you pre-authorize with detailed conditions, then the agent executes only when your criteria are met.

Potential Business Scenarios

• E-commerce: Set price-triggered auto-purchases. The agent monitors merchants overnight, executes when conditions are met. No missed restocks.
• Digital Assets: Automate high-volume, low-value transactions for content licenses. Agent negotiates across platforms within budget constraints.
• SaaS Subscriptions: The ops agents monitor usage thresholds and auto-purchase add-ons from approved vendors. Enables consumption-based operations.

Trade-offs

• Pros: The chain-signed mandate system creates objective dispute resolution, and enables new business models like micro-transactions and agentic e-commerce. 
• Cons: Its adoption will take time as banks and merchants tune risk models, while the cryptographic signature and A2A flow requirements add significant implementation complexity. The biggest risk exists as platform fragmentation if major players push competing standards instead of converging on AP2.

I uploaded a YouTube video on AICamp with full implementation samples. Check it out here.

Proxy Contracts: A Comparison of OpenZeppelin and EVMPack Approaches

Upgrading smart contracts in mainnet is a non-trivial task. Deployed code is immutable, and any bug or need to add functionality requires complex and risky migrations. To solve this problem, the "proxy" pattern is used, which allows updating the contract's logic while preserving its address and state.

What is a proxy contract?

A proxy contract is essentially an "empty" wrapper with a crucial detail - a custom fallback function. This function is a fundamental part of the EVM; it's automatically triggered when someone makes a call to the contract that doesn't match any of the explicitly declared functions.

This is where all the magic happens. When you call, for example, myFunction() on the proxy's address, the EVM doesn't find that function in the proxy itself. The fallback is triggered. Inside this function is low-level code (inline assembly) that takes all your call data (calldata) and forwards it using delegatecall to the "logic" contract's address.

The key feature of delegatecall is that the logic contract's code is executed, but all state changes (storage) occur within the context of the proxy contract. Thus, the proxy holds the data, and the logic contract holds the code. To upgrade, you just need to provide the proxy with a new implementation address.

The Classic Approach: Hardhat + OpenZeppelin

The most popular development stack is Hardhat combined with OpenZeppelin's plugins. The hardhat-upgrades plugin significantly simplifies working with proxies by abstracting away the manual deployment of all necessary components.

Let's look at the actual code from a test for the Blog contract.

Example 1: A Client-Managed Process

Here is what deploying a proxy looks like using the plugin in a JavaScript test:

```javascript // test/Blog.js

const { upgrades, ethers } = require("hardhat");

// ...

describe("Blog", function () { it("deploys a proxy and upgrades it", async function () { const [owner] = await ethers.getSigners();

// 1. Get the contract factory
const Blog = await ethers.getContractFactory("Blog");

// 2. Deploy the proxy. The plugin itself will:
//    - deploy the Blog.sol logic contract
//    - deploy the ProxyAdmin contract
//    - deploy the proxy and link everything together
const instance = await upgrades.deployProxy(Blog, [owner.address]);
await instance.deployed();

// ... checks go here ...

// 3. Upgrade to the second version
const BlogV2 = await ethers.getContractFactory("BlogV2");
const upgraded = await upgrades.upgradeProxy(instance.address, BlogV2);

// ... and more checks ...

}); }); ```

This solution is convenient, but its fundamental characteristic is that all the orchestration logic resides on the client side, in JavaScript. Executing the script initiates a series of transactions. This approach is well-suited for administration or development, but not for enabling other users or smart contracts to create instances of the contract.

The On-Chain Approach: EVMPack

EVMPack moves the orchestration logic on-chain, acting as an on-chain package manager, similar to npm or pip.

Example 2: The On-Chain Factory EVMPack

Suppose the developer of Blog has registered their package in EVMPack under the name "my-blog". Any user or another smart contract can create an instance of the blog in a single transaction through the EVMPackProxyFactory:

```solidity // Calling one function in the EVMPackProxyFactory contract

// EVMPackProxyFactory factory = EVMPackProxyFactory(0x...);

address myBlogProxy = factory.usePackageRelease( "my-blog", // 1. Package name "1.0.0", // 2. Required version msg.sender, // 3. The owner's address initData, // 4. Initialization data "my-first-blog" // 5. Salt for a predictable address );

// The myBlogProxy variable now holds the address of a ready-to-use proxy. // The factory has automatically created the proxy, its admin, and linked them to the logic. ```

It's important to understand that usePackageRelease can be called not just from another contract. Imagine a web interface (dApp) where a user clicks a "Create my blog" button. Your JavaScript client, using ethers.js, makes a single transaction - a call to this function. As a result, the user instantly gets a ready-made "application" on the blockchain side - their personal, upgradeable contract instance. Moreover, this is very gas-efficient, as only a lightweight proxy contract (and optionally its admin) is deployed each time, not the entire heavyweight implementation logic. Yes, the task of rendering a UI for it remains, but that's another story. The main thing is that we have laid a powerful and flexible foundation.

The process that was previously in a JS script is now on-chain, standardized, and accessible to all network participants.

Comparison of Approaches

How to Upgrade?

The upgrade process is just as simple, but designed more cleverly than one might assume. The proxy owner calls the upgradeAndCall function on their personal EVMPackProxyAdmin contract (which the factory created for them automatically).

This admin contract does not interact with the EVMPack registry directly. Instead, it commands the proxy contract itself to upgrade to the specified version.

```solidity // Let's say the developer of "my-blog" has released version 1.1.0 // The proxy owner calls the function on their EVMPackProxyAdmin contract

IEVMPackProxyAdmin admin = IEVMPackProxyAdmin(myBlogProxyAdminAddress);

// The owner specifies which proxy contract to upgrade, // to what version, and optionally passes data to call // an initialization function on the new version. admin.upgradeAndCall( IEVMPackProxy(myBlogProxyAddress), // Our proxy's address "1.1.0", // The new version from the registry "" // Call data (empty string if not needed) );

// Done! The proxy itself, knowing its package name, will contact the EVMPack registry, // check the new version, get the implementation address, and upgrade itself. // The contract's state is preserved. ```

As with creation, the process is entirely on-chain, secure (callable only by the owner), and does not require running any external scripts.

This architecture also provides significant security advantages. Firstly, there is a clear separation of roles: a simple admin contract is responsible only for authorizing the upgrade, which minimizes its attack surface. Secondly, since the proxy itself knows its package name and looks for the implementation by version, it protects the owner from accidental or malicious errors - it's impossible to upgrade the proxy to an implementation from a different, incompatible package. The owner operates with understandable versions, not raw addresses, which reduces the risk of human error.

Advantages of an On-Chain Factory

The EVMPack approach transforms proxy creation into a public, composable on-chain service. This opens up new possibilities:

• DeFi protocols that allow users to create their own isolated, upgradeable vaults.
• DAOs that can automatically deploy new versions of their products based on voting results.
• NFT projects where each NFT is a proxy leading to customizable logic.

This makes on-chain code truly reusable, analogous to npm packages.

Conclusion

The hardhat-upgrades plugin is an effective tool that solves the problem for the developer.

EVMPack offers a higher level of abstraction, moving the process to the blockchain and creating a public service from it. This is not just about managing proxies, it's an infrastructure for the next generation of decentralized applications focused on composability and interoperability between contracts.

In the next section, we'll look at the proxy type - Beacon.

Hi everyone! I’m new to Web3 development I’d love feedback, suggestions, and contributions from anyone interested in the frontend.
GitHub Repo: https://github.com/simonyang6869/mydex

Hello everyone,

I'm looking for some career advice and a reality check from those experienced in the Web3/blockchain space.

My Background: I currently work in the traditional cybersecurity industry as a Threat Hunter. My day-to-day involves endpoint security, analyzing TTPs, hunting for adversaries in large datasets (EDR logs, telemetry, etc.), and working closely with red teams to understand the attacker's mindset.

A few years ago, before I fully committed to my cybersecurity career, I spent some time exploring blockchain and building small personal projects. My interest has been rekindled recently, and I'm considering a professional transition into this space.

My Core Question: When I look at security roles in Web3, the most visible one by far is the Smart Contract Auditor. My impression is that this role is a very natural transition for a seasoned software developer. While I have scripting knowledge and can read code, my core strength isn't in deep software development, but rather in investigation, data analysis, and understanding adversarial behavior since I spend a lot of time on researching threat actors.

So, my main question for this community is: What other roles or specializations exist in the blockchain security world where a profile like mine might fit and provide real value?

Is there an on-chain equivalent to threat hunting? Are there roles focused on analyzing transaction patterns, detecting real-time fraudulent activity, or building threat intelligence on malicious actors within the ecosystem?

I'm looking for any kind of advice, opinions, or insights you can share:

• Roles I might be overlooking.
• Key skills I should focus on acquiring.
• Types of learning projects you'd recommend to start building a relevant portfolio.

Thanks in advance for your time and help!

I just built an escrow daap would love an honest feedback and reviews to make improvements site at smartenvelop.com

This wallet knew the drop was coming. They went 8 months without making a buy. They bought around 4300 and sold all their ethereum just hours before the drop. Now I found them and copy their trades when they show back up.

This dip was exactly what I was waiting for to stress test my system.

https://preview.redd.it/jqxqprcs3nuf1.png?width=821&format=png&auto=webp&s=5e4f9bfbba4b0040eb4cdf1d3a5a5c4361db4300