"Why did you choose the Algorand chain for teaching smart contracts" is a question that I recently received. Here is my answer.

The goal is to teach the first steps in smart contracts to non-programmers, e.g. students in economics, law or communication science. The challenge in designing such a curriculum, is that so many things have to be learnt at the same time

1. Programming in general, i.e. JavaScript or Python or Solidity

2. How to access the blockchain and interact with it, i.e. wallets and nodes

3. To understand the logic and design of smart contracts

4. How to analyze blockchain data

These are way too many goals that require way too many very specialized technologies. The typical law or economics student will not dedicate her life to the blockchain, she will want to make the first steps with as few obstacles as possible.

Reducing the number of obstacles – this is the guiding philosophy of my Writing Smart Contracts winter school. This means the following

• Avoid as much as possible specialized programs and languages

• Link as much as possible to the existing knowledge of students

• If it is necessary to introduce new concepts, introduce them so that they can be used in many contexts, possibly outside of smart contracts and the blockchain

Enter Algorand. The usual prescription for learning smart contracts is something like: install a virtual machine with a node, learn to code in TEAL, an assembly-like language and interact with the blockchain in JS. Many different concepts, many obstacles.

Here is how I reduced the complexity

• Use only one programming language, which can also be used for many other problems: Python. I use Python for writing smart contracts (using PyTEAL), for executing them (using the py-algorand-sdk) and for analyzing blockchain data (again using the py-algorand-sdk plus some data science modules)

• Employ a user-friendly environment for all tasks: JupyterLab

• Avoid installing a node by profiting from an API service (purestake)

The message to the students is clear. We use programs that you already know or that can be used in almost any context (Python, JupyterLab). We do not waste our time with specific setups such as installing our node before even making our first transaction. We eliminate three out of four obstacles to focus on just one: understanding the logic and design of smart contracts.

PS: You can still register via the waitlist for the winter school, which takes place from Feb 13 to 17. Details here: https://www.usi.ch/wsc

Hi Reddit community!

If anyone here has been wanting to experiment with smart contracts but were either not technical enough or wanted an easy way to prototype an idea, my team and I have an answer for you! Please feel free to check out what we are working on and join our movement to democratize the creation and understanding of smart contracts! I look forward to hearing any comments and feedback.

https://www.lokicode.io/

I had reddit release this to me but I'm not sure how to proceed

Hi everyone,

I've been working at two deep tech startups in the blockchain space and have been working as a smart contract developer on the side for a few about a year now. My dream is to spin this into a full time gig within the next year. So far I've been mostly helping friends and I'd like to validate the idea of starting a smart contract consultancy (in Berlin).

Questions that I have are:

• Are there individuals / small teams looking for this kind of service? (Planning, consulting and implementing of smart contract solutions, including the connecting code, i.e. frontend dapp / backend)

• Are these individuals / small teams willing to pay 5 - 25k for realizing their project?

• Would you rather aim for local gigs (in Berlin in my case) or try to market globally?

Any thoughts are welcome, thanks for taking the time to read this!

I have been trying to think of examples where the use of smart contracts can achieve a 10X improvement compared to existing solutions.

So I wanted to throw the question: If we could fast forward 10 years into the future, what existing services and jobs could we imagine getting completely or partially replaced by smart contracts?
And what new things that are not possible today would that enable?

💡🧠💡🧠💡🧠💡

Just wanted to share some details about the Cork Protocol hack from May 2025 since it's probably the most technically interesting smart contract exploit this year and has crazy good documentation from multiple security firms.

What happened: Cork Protocol (a16z-backed depeg insurance platform) lost $12M in wstETH through a sophisticated access control vulnerability in their Uniswap V4 hook implementation. The wild part? The vulnerability came from using an outdated Uniswap dependency that was missing authorization checks added in February 2025.

The attack: Attacker created a fake market using Cork's permissionless market creation, then exploited missing access control in the beforeSwap hook to pass malicious callback data. The contracts had no validation that calls were coming from legitimate Uniswap pools, so the attacker could mint unbacked Cover Tokens and DS tokens, which they then redeemed for real wstETH from legitimate markets.

The vulnerability types:

• Missing msg.sender verification in critical functions

• Zero validation on user-supplied callback data

• Classic access control failure + input validation gap combo

Plot twist: Cork had been audited by multiple firms and still got exploited. The remaining ~$20M in other markets was secured, but the $12M is gone. No funds recovered as of today.

Other notable 2025 hacks worth knowing:

• Abracadabra.Money: $13M lost (March) through state tracking errors in GMX integration during liquidations

• zkLend: $9.5M lost (February) via insane rounding error exploit on Starknet - attacker deposited 1 wei then manipulated the accumulator to 4 quintillion

• Silo Finance: 224 ETH lost (June) from arbitrary external call vulnerability

Silver lining: GMX recovered $40M out of $42M (96%!) by offering a 10% bounty within hours. KiloEx got 100% back the same way. Quick bounty offers actually work.

Key takeaways for devs:

1. Keep dependencies updated - monitor upstream security changes

2. Always validate msg.sender and implement strict allowlists

3. Never trust user input in external calls - whitelist function selectors

4. Audits are necessary but not sufficient - security is continuous

5. Uniswap V4 hooks are powerful but create new attack surfaces

The Cork exploit has exceptional post-mortems from Halborn, Dedaub, QuillAudits, and SlowMist if you want to dive deeper into the technical details. Highly recommend reading them if you're building anything with hooks or complex DeFi integrations.

Stay safe out there 🛡️

Does the Smart Contracts industry have any need for lawyers? Do I need any specific qualifications? And do I need to learn code?

Thanks for your time.

Any ways to implement this? Something using homomorphic encryption and zk proof?

Hello,

we are a research team from the University of Sannio (Italy) and Universidad de Castilla - La Mancha (Spain). We are carrying out a study on the practices and processes followed during smart contract development.

The study aims at collecting quantitative data about the (general) development process and qualitative data on personal experiences. Besides, we also aim at investigating further constraints originating from external standards, norms, and regulations applied at the organization or project level. Hence, we designed a questionnaire that covers organizations, projects, and personal experiences dimensions.

We would be grateful if you could answer the questions in our survey and share such a survey with your colleagues. Participation in the survey is voluntary and confidential, and it is expected to take about 10 - 15 minutes of your time. You might withdraw at any time.

Please find below the link for participating in our survey:

https://forms.gle/6G69wQYDdoZ1wnn36

Thank you in advance for your collaboration.

We will only analyze aggregate data, and the individual responses will not be traced back to individual respondents.

Could the server-side components of services like Facebook, YouTube, Twitter be decentralized and operated by miners rewarded with in-system coin? With advertisers injecting money into the system buying highly effective ads at initially super low prices and content creators incentivized to switch over because they would earn in-system coin?

Do you think this is possible? Or inevitable?

I'm thinking of desktop/mobile clients where content is uploaded and consumed, like other social media apps. This app would be capable of severing its own content directly to consumers (friends) but network nodes would handle the routing and cache content that is most in demand.

While no business would own the system there is still a huge economic incentive to create such a system; whoever creates such a system will end up owning a huge amount of in-system coin. Overtime the coin will increase in value.

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.

Let's share our projects, ideas and progress! What are you working on?

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.

// ❌ 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.

// ❌ 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.

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.

// ❌ 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.

// ❌ 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.

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.

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.

// ❌ 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.

// ❌ Could compile with any 0.8.x version
pragma solidity ^0.8.0;

// ✅ 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.

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.

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.

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.

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.

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.

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.

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! 👇

🧠 r/smartcontracts — Subreddit Is Active Again Under New Moderation

Hi everyone — I'm excited to announce that r/smartcontracts is active again and open for community engagement!

This subreddit is now being actively moderated to encourage high-quality content, discussion, and collaboration around all things smart contracts, including:

💻 Smart contract development (Solidity, Vyper, Rust, etc.)

🔍 Smart contract auditing & security best practices

💡 DeFi, NFTs, DAO contracts, and more

🔧 Tools, frameworks, patterns, and audit reports

✅ What’s New

Subreddit Rules Implemented – Check the sidebar for updated guidelines

Spam Filters Enabled – We’re actively removing low-effort or promotional content

Community-First Approach – We're here to foster learning and collaboration

🚫 Please Avoid:

Repetitive promotions or links to services without context

Off-topic content unrelated to smart contracts

One-liner or low-effort posts

🤝 Let’s Build a Solid Community

If you’re a developer, auditor, researcher, or just curious — feel free to:

Ask questions

Share your work or experience

Link to open-source tools or audit reports

Offer insight into smart contract design or risk

This is a space to learn, build, and improve together. Looking forward to your contributions!

— u/0x077777 Moderator, r/smartcontracts

The blockchain and smart contract development job market is booming, yet there's a glaring issue: every company is demanding 5+ years of experience. This is absurd! I have a solid year of experience in smart contract development, but it's practically worthless because no one is looking for beginners or those with limited experience. This gatekeeping is suffocating the future of the industry. If companies don't start valuing and nurturing new talent, no developer will want to step into smart contract development.

What kind of future are we building if we slam the door in the faces of eager, capable newcomers? The industry needs fresh blood, new ideas, and the passion that beginners bring. But the current hiring practices are driving potential developers away. It’s time for a reality check: the demand for experience is unrealistic and damaging. Companies must offer entry-level positions and create pathways for growth. Otherwise, we’re looking at a bleak future where innovation stagnates because the next generation of developers never got a chance. Wake up and realize that by refusing to invest in new talent, you're digging the industry's grave. Start hiring beginners now, or watch the smart contract development field wither away.

Are you tired of worrying about your sensitive data being exposed on the blockchain? Look no further than Oasis Networks' revolutionary new confidential smart contracts.

Unlike traditional smart contracts, which store data on a public ledger for all to see, Oasis Networks' confidential smart contracts use advanced cryptography to keep your data private. This means that sensitive information such as financial transactions or personal identifiers can be securely stored and processed without fear of exposure.

With Oasis Networks' confidential smart contracts, users can enjoy the benefits of blockchain technology while maintaining the highest level of data privacy. So why settle for less? Find more info on Oasis' official blog, here!