DEV Community: achraf bradji

Building and Updating a Decentralized Payment Streaming System (DPSS) – ERC20 Token Support and More

achraf bradji — Tue, 29 Apr 2025 16:14:11 +0000

In the world of decentralized finance (DeFi), payment streams are becoming an increasingly popular way to facilitate ongoing, automatic payments. But how do we ensure that users can send and receive payments over time without losing control? That’s where the Decentralized Payment Streaming System (DPSS) comes into play.

In this post, I’ll walk you through an update to my DPSS contract, transforming it from a simple ETH-only stream to a more versatile, secure, and feature-rich version that supports both ETH and ERC20 tokens.

What's Changed in DPSS2?
After building the initial DPSS1 contract, I realized that there were a few key features that could enhance its functionality, especially for tokenized payments in the DeFi space. Here’s what’s new in DPSS2:

ERC20 Token Support

The most important update is the support for ERC20 tokens. Initially, the system was limited to ETH. Now, it supports both ETH and any ERC20 token, giving users more flexibility in how they fund and receive payment streams.

This update uses OpenZeppelin’s SafeERC20 library to ensure that token transfers are safe and efficient.

Pause and Resume Streams

Users can now pause and resume payment streams. This is useful in scenarios where the payer or recipient may need to temporarily halt payments but plan to resume later.

This gives more control and flexibility over payment schedules, which is vital for long-term DeFi projects.

Extend Stream Duration

Another important update is the ability to extend the duration of an existing stream. If the payer wants to continue the stream beyond the initial duration, they can fund the stream again, which will extend its duration based on the additional funds sent.

More Detailed Error Handling

Error messages have been improved, making it easier to understand why a stream might have failed or what needs to be done to resolve the issue.

How Does DPSS2 Work?
The contract creates a payment stream that allows a payer to send funds to a recipient over a specified duration. Payments are released gradually based on a calculated rate.

Here’s a simplified version of the logic:

The payer sends a certain amount of tokens (ETH or ERC20) to the contract, specifying the recipient and the duration of the stream.

The contract calculates the rate at which funds will be released (amount / duration).

The recipient can withdraw funds periodically based on the rate, and they can even pause the stream when needed.

Security Considerations
When working with DeFi contracts, security is a top priority. Some of the security features in DPSS2 include:

Reentrancy Guard: To prevent reentrancy attacks, the contract uses OpenZeppelin’s ReentrancyGuard to ensure that functions like withdraw() can’t be exploited.

SafeERC20: By using SafeERC20, token transfers are made safe by handling potential pitfalls in ERC20 implementations.

Why DPSS2 Matters
The new DPSS2 contract brings enhanced flexibility and security to DeFi payments, enabling projects to build more complex payment structures with ERC20 tokens, stream extensions, and pause/resume functionality.

I believe this update provides the necessary tools for decentralized payment systems to handle more sophisticated use cases, especially in the world of long-term subscriptions, payments, and investments.

Check Out the Full Code
If you want to dive deeper into the code, I’ve uploaded the full DPSS2 contract on GitHub. You can fork, modify, and improve it for your own projects.

🔗 [https://github.com/Achraf012/learning-projects/blob/main/Decentralized-Payment-Streaming-System/contracts/v2.sol]

Conclusion
I hope you found this breakdown of DPSS2 insightful. If you’re working on DeFi projects that involve periodic payments, I highly recommend looking into this contract. Feel free to reach out if you have any questions or suggestions. Always happy to collaborate!

Solidity #Blockchain #DeFi #SmartContracts #ERC20 #Ethereum #DeFiDevelopment #PaymentStreams #OpenZeppelin

🚀 Implementing Fee Logic in a Decentralized Escrow System (with Foundry Tests)

achraf bradji — Mon, 21 Apr 2025 14:54:51 +0000

Just wrapped up a fun yet tricky part of my escrow project: fee implementation.

What I added:
Fee payout logic

Dynamic fee recipient address

Full test coverage with Foundry

A special Rejection contract to simulate fee transfer failures

This small feature really made me appreciate how complex simple things can be in Solidity when you care about:

⛽️ Gas efficiency

🔒 Security

✅ Test coverage

One cool challenge:
Making sure the contract reverts properly if the fee transfer fails without deleting the original amount. Sounds easy... wasn’t 😂

Now that everything passes (23/23 tests 💪), I'm moving toward multisig support next.

If you're also diving into Solidity, trust me — testing teaches more than coding.

Let me know what you think, or if you want to walk through your own fee logic!

Feel free to check out the full code and see how I implemented it on GitHub: [https://github.com/Achraf012/learning-projects/tree/main/EscrowProject]

solidity #web3 #foundry #smartcontracts #buildinpublic #testing

Don’t Leave Testing for the End: A Costly Mistake I Made in My Web3 Project

achraf bradji — Thu, 17 Apr 2025 21:32:09 +0000

🧠 Intro
I recently built a Token Sale + Vesting system in Solidity. Like most devs on a roll, I thought:

“Let me finish all the contracts first, then write the tests at the end.”

Bad idea. Here's what happened — and what I learned the hard way.

🔥 What Went Wrong
When I finally got to testing, things started breaking everywhere.

Random reverts on function calls

OwnableUnauthorizedAccount errors

Division by zero panics

Logic bugs that I didn’t notice while coding

It was overwhelming. The error messages weren’t always obvious, and debugging took forever because I wasn’t sure which contract was causing the issue.

🧪 The Turning Point
I decided to step back and test each contract in isolation, one at a time.

✅ First I wrote tests just for the Vesting contract
✅ Then I tested the TokenSale contract independently
✅ Finally, I tested how they interacted

Suddenly everything made more sense. I found the root of most bugs easily and could confidently refactor parts of the logic.

🛠️ Key Takeaways
If you're working on a Web3/Smart Contract project, I highly recommend this approach:

Test each contract right after writing it

Catch issues while they're fresh in your mind

Start with unit tests before integration tests

Test the contract alone first

Simulate edge cases early

Like caps not met, wrong owner calling, or time not yet passed

✍️Final Thoughts
I’m still learning, but this experience was a big eye-opener. Testing smart contracts isn’t just about coverage — it’s about clarity and confidence.

If you’re working on your own Solidity projects, trust me:
Test early. It’s worth it.

🏷️ Tags

web3 #solidity #testing #foundry #smartcontracts #blockchain #learning