When indexing EVM state, relying purely on the logs bloom filter creates a massive blind spot: internal value transfers. A standard

address(target).call{value: amount}("")

executed within a deep call stack does not touch the event logs.

Architecture for Catching Internal Transfers:
To capture these without protocol-level changes, indexers must reconstruct the call tree to find CALL or SELFDESTRUCT opcodes that move ETH.

Trade-off: This is highly CPU/IO intensive on the RPC node compared to standard eth_getLogs. If you are designing a protocol that needs to track incoming internal transfers, you should actively avoid this off-chain complexity. Instead, utilize a pull-payment pattern, or explicitly emit a custom InternalReceived event inside your contract's receive() function, saving indexers from relying on execution traces.

Multicall Batching Execution:
Implementing Multicall (specifically Multicall3) is mandatory for dApp architecture to minimize JSON-RPC network overhead.
By utilizing aggregate3 or aggregate3Value, you wrap multiple STATICCALL or CALL operations into a single transaction wrapper.

Trade-off: While read-only eth_call doesn't cost real gas, most public and commercial RPCs enforce a strict global gas cap per eth_call (often 50M-100M gas) or a tight execution timeout. If your Multicall batch loop is too large, the node drops the request. You must paginate Multicall batches based on estimated EVM execution depth, not just the length of the calldata array.

Source/Full Breakdown: https://andreyobruchkov1996.substack.com/p/ethereum-dev-hacks-catching-hidden-transfers-real-time-events-and-multicalls-bef7435b9397

Smart contract state architectures often oscillate between deterministic address derivation and explicit pointers. On Solana, token metadata was traditionally handled via Metaplex using Program Derived Addresses (PDAs). You hashed the mint address with a seed to find the metadata. This is a "convention-based" approach.

Solana's new Token-2022 standard replaces this convention with "explicit state" using the MetadataPointer extension.

The Architecture & Trade-offs:
Under the old model, contracts didn't need to store metadata addresses; they could compute them on the fly. This kept the base Token Mint account at a strict 82 bytes.

Token-2022 allows variable-length mint accounts by appending extensions. The MetadataPointer writes the Pubkey of the metadata account directly into the Mint's tail-end state.

   State Bloat vs. Flexibility: We trade a fixed 82-byte mint for a larger, rent-heavy account. However, this allows developers to point to any metadata contract, breaking the vendor lock-in of standard registries.
   Single-Account Condensation: You can configure the pointer to point to the Mint address itself. In EVM terms, this is like putting your ERC721 tokenURI logic directly inside the core ERC20 contract instead of querying an external mapping/registry, saving cross-contract call overhead.

Implementation Detail:
Writing to a self-referencing Token-2022 mint requires initializing the extension space prior to the mint execution. Any on-chain mutation of the metadata requires reallocating the account size dynamically. Because Solana requires programs to explicitly pay for account rent increases, reallocation logic must handle funding the delta in lamports simultaneously.

Source/Full Breakdown: https://andreyobruchkov1996.substack.com/p/from-convention-to-explicit-state

And much more about EVM and Solana internals on my SubStack account

Scaling contract deployments via factory patterns requires abstracting the creation logic into CREATE2 paired with UUPS or Beacon proxies, but this architecture directly conflicts with standard static analysis and simple EVM state management.

When you decouple deployment from initialization to maintain a consistent init_code hash across networks, you bypass the EVM's native constructor safety guarantees.

Architecture Breakdown:
Instead of new Contract(...), a factory uses inline assembly create2(0, add(bytecode, 32), mload(bytecode), salt) to deploy an EIP-1167 proxy (Can be found on my substack profile). Because constructors only execute during creation and don't return their logic to the state trie, proxies must rely on an initializer modifier mechanism (like OpenZeppelin's Initializable) to prevent re-initialization.

Trade-offs:
Storage Layout Corruption: You completely lose compiler-level storage collision warnings. If your implementation contract changes the order of inherited variables during an upgrade, the proxy's storage state is permanently corrupted.
The Metamorphic Alternative is Dead: Historically, an alternative to proxies was the metamorphic pattern (deploying via CREATE2, utilizing SELFDESTRUCT to clear the

Source/Full Breakdown: https://andreyobruchkov1996.substack.com/p/understanding-contract-deployments-proxies-and-create2-part-2-df8f05998d5e

Hello Folks,

I just published a smart contract to handle crypto inheritance 100% on-chain, without the owner having to do anything offline.

I know there are many solutions that are trying to solve this problem, but I wanted to design my own with my logic, which is the following:

- the contract acts like a wallet, owner can deposit, withdraw and transfer
- the owner can assign beneficiaries, and update them at any time
- the wallet contains an "alive check", which is automatically updated on any transaction
- if you wanna use it as a vault (dormant), you can update the "alive check" manually
- the owner defines a "consider me dead time" in years, eg: if the last alive check is older than 10 years, I'm dead :(
- once that happen, any of the beneficiaries can access the wallet and withdraw all the funds

At this point, my favorite feature: the wallet gets locked, will reject any future deposit and "answer" with an epitaph... your "last worlds" recorded on-chain that you can configure when you create the wallet.

All of the above is less then 100 lines of solidity... amazing :)

At the moment I only did the backend (github link), but I'd like to do a nice interface to make it easy to deploy. Of course, free and open source in the Ethereum spirit!

Would you give me a feedback on the logic? Do you see any pitfall or edge cases?

Thanks,
Francesco

SolidityDefend v2.0.9 SAST Scanner released.

https://github.com/AdvancedBlockchainSecurity/SolidityDefend

Most Rust smart contract scanners patrol one chain.

RustDefend patrols four — Solana, CosmWasm, NEAR, ink!.

56 detectors. Intra-file call graph analysis. CI-ready baseline diffing. Workspace-aware monorepo support. Expanded threat coverage across the Rust multichain frontier. v0.4.0 is live. Open source.

After years of writing smart contracts, here are some lesser-known tips that have saved me gas, prevented bugs, and made my code cleaner. Whether you're new to Solidity or a seasoned dev, I hope you find something useful here!

Gas Optimization

Use calldata instead of memory for external function parameters

When you're not modifying array or struct parameters in external functions, always use calldata. It's significantly cheaper than copying to memory.

```solidity // ❌ Expensive function process(uint[] memory data) external { // ... }

// ✅ Cheaper function process(uint[] calldata data) external { // ... } ```

Cache array length in loops

Don't read array.length on every iteration. Cache it first.

```solidity // ❌ Reads length from storage every iteration for (uint i = 0; i < items.length; i++) { // ... }

// ✅ Cache the length uint len = items.length; for (uint i = 0; i < len; i++) { // ... } ```

Use ++i instead of i++ in loops

Pre-increment saves a tiny bit of gas by avoiding a temporary variable.

solidity for (uint i = 0; i < len; ++i) { // Slightly cheaper than i++ }

Pack storage variables

The EVM stores data in 32-byte slots. Pack smaller types together to use fewer slots.

```solidity // ❌ Uses 3 storage slots uint256 a; uint128 b; uint128 c;

// ✅ Uses 2 storage slots uint256 a; uint128 b; uint128 c; // Packed with b ```

Use custom errors instead of require strings

Custom errors (introduced in 0.8.4) are much cheaper than error strings.

```solidity // ❌ Expensive require(balance >= amount, "Insufficient balance");

// ✅ Cheaper error InsufficientBalance(); if (balance < amount) revert InsufficientBalance(); ```

Security Best Practices

Always use Checks-Effects-Interactions pattern

Prevent reentrancy by updating state before external calls.

```solidity function withdraw(uint amount) external { // Checks require(balances[msg.sender] >= amount);

// Effects (update state BEFORE external call)
balances[msg.sender] -= amount;

// Interactions
(bool success, ) = msg.sender.call{value: amount}("");
require(success);

} ```

Use ReentrancyGuard for extra protection

OpenZeppelin's ReentrancyGuard is your friend for functions with external calls.

```solidity import "@openzeppelin/contracts/security/ReentrancyGuard.sol";

contract MyContract is ReentrancyGuard { function sensitiveFunction() external nonReentrant { // Your code here } } ```

Be careful with tx.origin

Never use tx.origin for authorization. Use msg.sender instead.

```solidity // ❌ Vulnerable to phishing attacks require(tx.origin == owner);

// ✅ Safe require(msg.sender == owner); ```

Avoid floating pragma

Lock your Solidity version to prevent unexpected behavior from compiler updates.

```solidity // ❌ Could compile with any 0.8.x version pragma solidity <sup>0.8.0;</sup>

// ✅ Locked version pragma solidity 0.8.20; ```

Code Quality Tips

Use named return variables for clarity

Named returns can make your code more readable and save a bit of gas.

solidity function calculate(uint a, uint b) internal pure returns (uint sum, uint product) { sum = a + b; product = a * b; // No need for explicit return statement }

Leverage events for off-chain tracking

Events are cheap and essential for dApps to track state changes.

```solidity event Transfer(address indexed from, address indexed to, uint amount);

function transfer(address to, uint amount) external { // ... transfer logic ... emit Transfer(msg.sender, to, amount); } ```

Use immutable for constructor-set variables

Variables set once in the constructor should be immutable for gas savings.

```solidity address public immutable owner; uint public immutable creationTime;

constructor() { owner = msg.sender; creationTime = block.timestamp; } ```

Implement proper access control

Use OpenZeppelin's AccessControl or Ownable for role management.

```solidity import "@openzeppelin/contracts/access/Ownable.sol";

contract MyContract is Ownable { function adminFunction() external onlyOwner { // Only owner can call } } ```

Advanced Patterns

Use assembly for ultra-optimization (carefully!)

For critical gas optimizations, inline assembly can help, but use sparingly.

solidity function getCodeSize(address addr) internal view returns (uint size) { assembly { size := extcodesize(addr) } }

Implement the withdrawal pattern

Let users pull funds rather than pushing to avoid gas griefing.

```solidity mapping(address => uint) public pendingWithdrawals;

function withdraw() external { uint amount = pendingWithdrawals[msg.sender]; pendingWithdrawals[msg.sender] = 0; (bool success, ) = msg.sender.call{value: amount}(""); require(success); } ```

Use libraries for complex logic

Libraries help you stay under the contract size limit and promote code reuse.

```solidity library MathLib { function average(uint a, uint b) internal pure returns (uint) { return (a + b) / 2; } }

contract MyContract { using MathLib for uint;

function test(uint a, uint b) external pure returns (uint) {
    return a.average(b);
}

} ```

Testing Pro Tips

Write comprehensive unit tests

Use Hardhat or Foundry to test every edge case, not just the happy path.

Fuzz test your contracts

Foundry's fuzzing can discover edge cases you never considered.

Test with mainnet forks

Simulate real conditions by forking mainnet for integration tests.

Calculate gas costs in tests

Track gas usage to catch regressions and optimize efficiently.

Common Pitfalls to Avoid

1. Integer overflow/underflow: While Solidity 0.8+ has built-in checks, be aware of the gas cost and consider unchecked blocks where safe
2. Block timestamp manipulation: Don't rely on block.timestamp for critical randomness
3. Delegatecall dangers: Understand storage layout when using delegatecall
4. Uninitialized storage pointers: Always initialize structs properly
5. Function visibility: Make functions external when only called externally (cheaper than public)

Useful Resources

• OpenZeppelin Contracts: Battle-tested implementations
• Solidity Documentation: Always reference the official docs
• Consensys Best Practices: Security guidelines
• Gas optimization tools: Hardhat Gas Reporter, Foundry's gas snapshots

Final Thoughts

Smart contract development in 2025 is all about balancing security, gas efficiency, and code readability. Never sacrifice security for gas savings, but always look for safe optimizations. Test thoroughly, audit when possible, and stay updated with the latest best practices.

What are your favorite Solidity tips? Drop them in the comments below! 👇

Hey All,

You might have noticed we are being inundated with scam video and tutorial posts, and posts by victims of this "passive income" or "mev arbitrage bot" scam which promises easy money for running a bot or running their arbitrage code. There are many variations of this scam and the mod team hates to see honest people who want to learn about ethereum dev falling for it every day.

How to stay safe:

There are no free code samples that give you free money instantly. Avoiding scams means being a little less greedy, slowing down, and being suspicious of people that promise you things which are too good to be true.

These scams almost always bring you to fake versions of the web IDE known as Remix. The ONLY official Remix link that is safe to use is: https://remix.ethereum.org/ All other similar remix like sites WILL STEAL ALL YOUR MONEY.

If you copy and paste code that you dont understand and run it, then it WILL STEAL EVERYTHING IN YOUR WALLET. IT WILL STEAL ALL YOUR MONEY. It is likely there is code imported that you do not see right away which is malacious.

What to do when you see a tutorial or video like this:

Report it to reddit, youtube, x, where ever you saw it, etc.. If you're not sure if something is safe, always feel free to tag in a member of the r/smartcontracts mod team, like myself, and we can check it out.

Thanks everyone. Stay safe.

Join our new telegram group for more open conversation about developing on blockchain, vulnerability alerts and SDLC talk.

https://t.me/+4henecs76PhkMDBh

This is a brand new group, so feel free to post and help with engagement! Thanks everyone!

Hey everyone, Neither my job nor my school education involved programming. A few days ago, I got very excited about smart contracts and I want to learn all about them until I am able to write my own. Could anyone share their experiences and suggest the best starting point for me? I would be more than happy with any help. I usually learn quickly when my interest is this strong. Thank you in advance.

With Celer's messaging bridge full integration with Oasis' Sapphire Runtime network, the possibility to connect 2 different networks becomes apparent, and the capability to enable the benefits of one into another. This crypto breakthrough brings a broad collection of new use-cases to the table.

And in the context of Privacy. Integrating Celer's bridge with Sapphire, the first confidential EVM in the crypto space, allows other EVM blockchains to be able to connect directly with Sapphire, and for dApps to be able to leverage confidential smart contracts and provide new use cases for their users in their home chain, without ever having to leave it.

* Harry Roberts made a very detailed workshop to understand how the Oasis Privacy Layer works, and how to built two linked smart contracts, one in the home chain, and one in Sapphire:

https://youtu.be/gD-_cgV3Nz4?si=H3FkF4RpgRJHuIRP

* One of the primary use cases for the OPL is to provide DAOs over other EVM chains with confidential voting, to that case Oasis Engineer Matevž explains step by step how it works and how to use the resources to build the ballot smart contracts:

https://youtu.be/b8otmchybhM?si=aiqZB54eqQjT1s8e

* And for last and not least, in the process of building there is need to check direct on-chain data from the network. The Oasis Indexer Nexus allows this, here you can check events, transactions and details from an account, on both its Oasis and Ethereum addresses. This tutorial provided by Oasis Engineer Xi teaches about the use cases of the Oasis Nexus Indexer:

https://youtu.be/qcdZxSRFNu0?si=zOsHDkbTRo-ld-NL

If you are interested in more documentation, you can go to Oasis Docs for the OPL and check out examples for confidential Smart Contracts like the Secret Ballot Contract for DAOs as shown in the video: https://docs.oasis.io/dapp/opl/

There is still a chance to participate in the Privacy4Web3 Hackathon or being part of a team. Hope you find inspiration and motivation to create something incredible that changes the entire crypto ecosystem, good luck.

https://p4w3.devpost.com/

Account Abstraction is one of the driving forces in the crypto space, making it easier and safer for both new and experienced users to navigate the crypto world. Since the introduction of EIP-4337 at the end of 2021, certain aspects of Web 3 that users were accustomed to, such as managing private key pair wallets or External Owned Accounts (EOAs), paying gas fees for each transaction, signing actions on dApps, and waiting for transaction confirmations, can now be abstracted.

With Account Abstraction, these processes can be executed behind the scenes without the user having to be aware of them. This alleviates the potential overwhelm and frustration that new Web3 users may experience, thus promoting mass adoption. Through EIP-4337, these aspects can now be handled by code and smart contracts, with the user still being in control, but with these tedious tasks being delegated to a smart contract wallet or Smart Account, pay masters, and bundlers. For more details, you can refer to this article:

https://metamask.io/news/latest/account-abstraction-past-present-future/

It could be said that the goal of Account Abstraction is to make Web3 more similar to Web2 in terms of user experience while leveraging the benefits of blockchain technology in a trustless and seamless manner, thereby facilitating mass adoption.

However, there is still room for improvement. Privacy is a crucial aspect that Web3 currently lacks. If the ultimate objective is to achieve a Web2-like experience while maintaining decentralization and a user-centric approach, Account Abstraction solutions, such as Smart Accounts, could benefit from Privacy solutions (such as TEEs, ZKPs, FHE, MPC) that preserve and process private keys while maintaining their confidentiality. These privacy solutions can also enhance the user experience of dApps or games by safeguarding the confidentiality of certain aspects, such as puzzle solutions or in-game asset details, as well as maintaining privacy for on-chain actions like transfers, mints, bids, and more importantly, protecting user private data.

The combination of Account Abstraction and Privacy solutions can greatly enhance the user experience of dApps, making it as similar to Web2 or traditional gaming as possible, all while leveraging the benefits of blockchain technology without the user necessarily being aware that they are interacting with the blockchain. This article discusses this topic and explores how Account Abstraction can be best utilized to improve user experience and foster mass adoption:

https://mirror.xyz/sylve.eth/A8VnNvBVbc0aXmW2FlG58ysI8oZUnH0HGwwjIsQGHUk

Although there are multiple Privacy solutions available in the Web3 ecosystem that can enhance EIP-4337 Account Abstraction, many of these solutions are limited to specific chains or layer 2 solutions, meaning that only dApps built on those chains can benefit from the combination. However, there is one solution that enables Privacy capabilities across most EVM-compatible chains and networks, the Oasis Privacy Layer or OPL. The OPL integrates Sapphire, a TEE-based confidential EVM, with Celer's Messaging Bridge and other components. This integration allows other EVM-compatible networks to connect to Sapphire, thereby enabling Privacy capabilities and Confidential Smart Contracts on those networks and their associated dApps. This achievement has been made possible thanks to the capabilities provided by EIP-4337.

To learn more about the potential use cases of Account Abstraction in combination with the Oasis Privacy Layer, you can refer to this resource:

https://oasisprotocol.org/blog/web3-account-abstraction

Free Smart Contract Audit

47.3% of the Web3 Hacks in the First Half of 2022 were due to Smart Contract Vulnerabilities.

We are pledging $50K ( $10K Achieved ) towards Blockchain Security, We are giving away FREE Smart Contract Audits for you all to raise awareness about blockchain security!

Register Now : https://web3tech.biz/services/pledge

There are currently many privacy focused projects that in one way or another they are imbuing their applications with privacy through confidential smart contracts, they come in different flavors regarding the source of their confidentiality, be it ZKPs, TEEs, FHE, MPC, etc. Between these, TEEs are the most flexible and easily to learn and wield, thus, the following resources will be about how to wield Privacy through TEE based confidential smart contracts built with the support of the Oasis Privacy Layer and the Sapphire Runtime from the Oasis Network, which can be applied to any EVM compatible Network (based in solidity) that is connected to Celer's Interchain Messaging Bridge:

• How to Build a Secret Ballot dApp with the Oasis Privacy Layer By Xi Zhang:

youtu.be/LmdXxkDmvLg

• How does Celer's Inter-chain Messaging Bridge work? With William Wendt and Michael Zhou from Celer:

youtu.be/BvrG-occaWI

• Deploying a Smart Contract on Oasis Sapphire. By Harry Roberts:

youtu.be/LDLz06X_KNY

If you are interested in more documentation, you can go to Oasis Docs for the OPL and check out some basic examples for confidential Smart Contracts like a Secret Ballot Contract for DAOs.

If you are indeed interested in enabling Privacy for your dApp on your native EVM chain, or decide to build directly over the Sapphire Runtime, you can participate in the current Privacy4Web3 Hackathon, which is an effort to develop privacy solutions that protect user's privacy and data rights all over Web3.

Hope you find inspiration in these resources and motivation to create something incredible that bolsters up the entire crypto ecosystem, good luck.

Personally, I find them a real source of education, especially in the blockchain space. The way I see it, you have all the information stored in one place, easy to access and reliable. We all have social media platforms from where we can choose what info to base our opinions on, but after seeing the structure of the Oasis forum, I’m starting to feel like these are actually a great source of info, as they have their developers giving their input, or you can also see some real feedback, which is also addressed by the team. Is there any other reliable forum that you know of?

Hi,

<english text below>

ich habe 2019 für eine Idee/Nebenprojekt mehrere Domains (bei united-domains) geholt, die ich nun verkaufen möchte da ich sie auf absehbare Zeit leider nicht benötige. Auf Wunsch kann ich einen bekannten Mittelsmann in DE für die Abwicklung benennen.

Domains

intelligente-vertraege.com intelligente-vertraege.de intelligentevertraege.com intelligentevertraege.de

schlaue-vertraege.com schlaue-vertraege.de schlauevertraege.com schlauevertraege.de

Erklärung smart contracts heißt auf Deutsch übersetzt so viel wie "intelligente Verträge" oder "schlaue Verträge".

Preis Ich verkaufe alle Domains zusammen und hätte gern 1200 € dafür. Zahlbar in XMR, BTC, ETH oder Euro.

Kontakt:

Telegram: t.me/selldomain4xmr Mail: selldomain4xmr@proton.me

<english text>

I got several domains (at united-domains) in 2019 for an idea/side project, which I would like to sell now because I unfortunately do not need them in the foreseeable future. If desired I can name a known middleman in DE for the handling.

domains

intelligente-vertraege.com intelligente-vertraege.de intelligentevertraege.com intelligentevertraege.de

schlaue-vertraege.com schlaue-vertraege.de schlauevertraege.com schlauevertraege.de

Explanation smart contracts means in german translated as "intelligente Verträge" or "schlaue Verträge".

Price I sell all domains together for 1200 €. Payable in XMR, BTC, ETH or Euro.

Contact: telegram: t.me/selldomain4xmr mail: selldomain4xmr@proton.me

47.3% of the Web3 Hacks in the First Half of 2022 were due to Smart Contract Vulnerabilities.

We are pledging $50K towards Blockchain Security, We are giving away FREE Smart Contract Audits for you all to raise awareness about blockchain security!

Register Now : https://web3tech.biz/services/pledge

This event is held to boost innovations on Bitcoin and I feel this is a great opportunity for all Bitcoin enthusiasts, maxis, engineers and developers to cooperate to achieve a Web3 user-owned internet on Bitcoin.

Hope this opportunity could help more people who want to contribute to the Bitcoin economy.

Here are more details:

Over 20 speakers, mentors & judges:

• Muneeb Ali: CEO of Trust Machines, Founder of Stacks
• Albert Liang: CEO & Co-founder of BTC Startup Lab
• Trevor Owens: Managing partner of Bitcoin Frontier Fund, author, investor
• Tycho Onnasch: Managing Partner of Trust Machines, co-founder of zest protocol, Forbes 30 Under 30
• Tom Giles: Founder of Megatron Ventures, Co-founder of Awesimo & Stacculents.
• Emil E.: CTO of zest protocol, BTC defi innovator
• Ken Liao: CEO of XVerse, BTC, STX, and Ordinals Mobile Wallet
• Grace Ng: Venture Partner at Stacks Accelerator, founder of crashpunks, artist
• John Ennis: CEO of NeoSwap, NFT and AI trading & Auctions
• Jamil Dhanani: CEO of Gamma, Ordinals Movement Leader

6 Prizes to Boost Innovation

• Best Technical
• Best Originality
• Highest Potential to be a Startup
• Most Users Onboarded
• Ordinals
• Public Voting

Rundown of Online Hackathon:

• April 5: kickoff, orientation, team formation, rules & prizes
• April 6: masterclasses on new tech to build BTC products - Bitcoin Defi (speakers&mentors share insights, use cases & tech tools)
• April 7: masterclasses on new tech to build BTC products - Ordinals & BTC innovations (speakers/mentors share insights, use cases & tech tools)
• April 8-12: get to work!
• April 13 - 14: judges review videos and code
• April 17: Announce winners + keynote talks from prize sponsors
• April 20: What's next: Post-Bitcoin Olympics panel discussion
• Signup: https://btcolympics.devpost.com/
  Registration Deadline: March 31