🧵

We're excited to introduce EIP-7809: Native Tokens!

This is a proposal for implementing fungible tokens with native-like properties in the EVM — in a backward-compatible way.

https://github.com/ethereum/EIPs/pull/9026



💡 The basic idea is this: what if fungible tokens could work just like ETH?

• Better UX with simplified token transfers (no more approve + transfer)
• Native financial products become easier to implement (e.g. yield on Blast)
• Potential for innovation on L2s



🔑 Key features of EIP-7809

• Embedding token balances in the global EVM state
• ETH becomes one of many native tokens
• Direct token transfers via new opcodes
• Multi-token transfers in contract calls



⚡️ New opcodes:

• MINT & BURN for supply management
• BALANCEOF for checking balances
• NTCALL for calling contracts and transferring tokens
• NTCREATE for creating contracts with upfront token deposits



📱 For end users:

We're introducing a new EIP-2718 transaction type that replaces the 'value' field with `(token_id, token_amount)` pairs.

Existing tx types remain backward compatible.



⏳ We came up with this EIP during our work on Sablier Mainnet.

Although we eventually discontinued the project, EVM developers might still find it an interesting read:

https://x.com/PaulRBerg/status/1852392802933715061



🙏 Huge thanks to @IaroslavMazur for co-authoring this EIP and to the @Sablier team for their feedback.

We’d love to hear your thoughts!

Read the full EIP on GitHub and join the discussion on @EthMagicians.

https://github.com/ethereum/EIPs/pull/9026

Introducing EIP-7809: Native Tokens in the EVM

🧵

After years of R&D, I'd like to tell you the story of a now-discontinued project called Sablier Mainnet.

In this thread, I’ll cover what it was and the lessons we learned along the way.

Let’s dive in! 👇



The story begins in 2020, when we were working on the next version of Sablier.

What we wanted to do is get rid of the deposit requirement, and enable payment streams that can run indefinitely in an open-ended way.

Here's a Q&A from StackExchange:

https://ethereum.stackexchange.com/q/84226/24693



That led us to notice that all VMs are reactive, i.e., they don't proactively do stuff for users.

So what if the VM itself allowed recurring payments?

What if Alice's EOA could start a subscription to Bob's EOA via an Ethereum tx, without an intermediary contract?



Sablier Mainnet was our answer to those "what ifs".

Inspired by the rise of Celestia and Fuel, we envisioned Sablier Mainnet, an EVM fork meant to be deployed as an execution rollup with two new features:

1. Multiple native tokens
2. Built-in recurring payments



Multiple Native Tokens was a prerequisite for recurring payments, so this is the feature we worked the most on before halting the project.

This was a token design inspired by @fuel_network's FuelVM, in which the EVM is extended to support native fungible tokens.



Sablier Mainnet was supposed to have many other cool features, such as:

- Solvency Monitoring
- Graph of Streams in VM state
- Programmable Cashflows
- A Solidity fork with streaming functionality

I don't have space here to expand, but these slides should help:



All this sounds awesome, right? What went wrong?

1. Insurmountable technical challenges
2. Lack of demand for onchain recurring payments

I'll expand on each category in the following tweets.



Technical challenge #1: Non-constant time complexity

The built-in recurring payments required embedding a directed graph in the VM state.

The graph was also interconnected, meaning updating an edge between user A1 and A2 may have triggered an update for user A100.



@IaroslavMazur, @razgraf, and I have explored various techniques to achieve near-constant time complexity:

→ Lazy evaluation
→ Graph optimization
→ Discretizing payment cadences and amounts
→ Batch tx updates with a bootloader
→ Tx prioritization



But unfortunately, we didn't produce a workable model.

Sablier Mainnet would have been a completely centralized network with no clear roadmap toward decentralization.

That would have been against our ethos at @Sablier.



Technical challenge #2: DoS risk when closing streams

The VM was designed to monitor account solvency, which involved cron jobs for terminating streams when the sender's balance went to zero.

But too many overlapping cron jobs can lead to DoS risk.



We eventually found a solution for the DoS risk (challenge no. 2) using a cold<>hot state duality, but the solution created a vicious cycle where the non-constant time complexity was amplified (challenge no. 1).



Lack of demand #1

As per the answers received below, subscriptions haven't taken off in web3.

→ UX is not better than credit cards
→ They lead to customers overpaying for a service
→ Subscriptions are about renting, web3 is about owning

https://x.com/PaulRBerg/status/1795758836491428004



Lack of demand #2

We talked to potential early adopters, such as @EleniThinks from Loop Crypto.

Her feedback was amazingly helpful.

The limiting factor isn't the backend architecture. It's the frontend and how the merchant<>customer relationship is managed.



We have open-sourced our R&D work on Sablier Mainnet.

Maybe some of you will fork it and build something cool with it?

→ SRFs: https://github.com/sablier-labs/SRFs
→ stdlib: https://github.com/sablier-labs/stdlib
→ SabVM: https://github.com/sablier-labs/sabvm



We are also working on an EIP for Multiple Native Tokens, with the purpose of promoting it as a design that other EVM rollups could adopt.

Big thanks to @IaroslavMazur for his relentless dedication to this effort.

Will share an update soon!



In the meantime, our Lockup and Airstreams products on app.sablier.com have gained significant traction via token vesting and airdrops.

It would be unwise to ignore this growth, and so we have shifted toward a product-first approach.

https://x.com/Sablier/status/1840845642241073656



We learned so much from building Sablier Mainnet.

It's now clear to us that Sablier would be in a stronger position by expanding across established blockchain ecosystems.

Stay tuned for Sablier Flow — our upcoming open-ended streaming product 👀


The Saga of Sablier Mainnet

1/

Now that @Sablier V2 is live, I would like to offer you a technical presentation of some of the key principles that went into building V2 Core.

I think we have one of the most robust codebases in web3 at the moment.

https://github.com/sablier-labs/v2-core

2/

There's a list of our coding practices in the Notion doc below.

Some highlights:

- We obsess over testing and security
- We value code consistency and strive to adhere to best practices
- We document everything with comprehensive NatSpec comments

https://sablier.notion.site/Sablier-Coding-Practices-Contracts-2f5920cf497646b4a2ea982c1bacb5a8?pvs=4

3/

Our Foundry test suite includes hundreds of files with unit, integration, invariant, and fork tests.

Unit and integration tests are further split into concrete and fuzz.

Each category gives us additional confidence that the protocol works correctly.

https://github.com/sablier-labs/v2-core/wiki/Tests

4/

Our secret sauce for testing is the Branching Tree Technique:

1. Target a function
2. Create a ".tree" file
3. Consider all possible execution paths
4. Consider what state leads to what paths
5. Define "when state is x" nodes
6. Define child "it should" tests

Example:

5/

Note that BTT is agnostic about test-driven development (TDD).

The function you are writing the Branching Tree for may or may not be already implemented.

What matters is that you don't jump head-first into Solidity (either production logic or tests).

6/

Now, let's look at the tests we have written for "statusOf", the function which returns the current status of a Sablier V2 stream.

Source code here: https://github.com/sablier-labs/v2-core/tree/v1.0.1/test/integration/concrete/lockup/status-of

On the left, it's the tree file. We wrote this first.

On the right, it's the Forge tests.

7/

Notice that we used empty modifiers to "mirror" the Branching Tree in Solidity.

These modifiers need not be empty - you could use them as a scenario-building tool by implementing shared logic:

8/

Here's a sample of two other Branching Trees from V2 Core, as well as some excerpts from their implementation files.

9/

Side notes:

- We chose to mirror the Branching Trees with modifiers, but you can skip this part if you feel like it's too much
- We used ASCII characters to draw the trees
- There's a VSCode extension to get syntax highlighting for *.tree" files

https://marketplace.visualstudio.com/items?itemName=CTC.vscode-tree-extension

10/

Moving on to source code documentation.

In Sablier V2, all contracts, interfaces, libraries, functions, and variables are annotated with explanatory comments.

Explaining your code is crucial in web3 due to immutability.

11/

Closely related to documentation is code linting and formatting.

A linter helps you adhere to best practices, while a formatter makes your code more readable.

In V2 Core, we have a setup that combines Forge, Solhint, and Prettier.

12/

That was it; I hope you liked it and derived some value from this thread.

To stay in touch with all things development at @Sablier, join the chat in the #dev channel in our Discord community server.

https://discord.com/invite/bSwRCwWRsT

13/

Shout-outs to:

- @AndreiVladBrg, @msolomon44: feedback on BTT + hundreds of interactions on GitHub
- @zachobront, @_RustyRabbit, @IaroslavMazur: outstanding audits
- @Uniswap: we inspired from Uniswap V3's contract architecture
- Foundry crew for their support along the way

Sablier V2: Building a Robust Codebase in Web3

Here's a thread with all the Solidity tips I shared on Twitter over the years.

Some of you will find these obvious, but I think that a greater majority will find them useful.

1/12

You can call Solidity functions with explicit arguments, e.g. "foo({ x: 1, y: 2})".

2/12

https://twitter.com/PaulRBerg/status/1574071928544976896

ASCII box-drawing characters for struct members.

3/12

https://twitter.com/PaulRBerg/status/1586106649550671872

Scientific notation.

4/12

https://twitter.com/PaulRBerg/status/1566786525379043328

"bytes.concat" is a stricter version of "abi.encodePacked".

5/12

https://twitter.com/PaulRBerg/status/1561317691675353088

Time units.

6/12

https://twitter.com/PaulRBerg/status/1511977904170803203

Free functions.

7/12

https://twitter.com/PaulRBerg/status/1450444297925431301

Underscore in numerical literals.

8/12

https://twitter.com/PaulRBerg/status/1447201033764093953

Gas golfing divisions in Solidity v0.8.

9/12

https://twitter.com/PaulRBerg/status/1378313956293500931

Miscellaneous

10/12

https://twitter.com/PaulRBerg/status/1352403834430255109

Miscellaneous

11/12

https://twitter.com/PaulRBerg/status/1266504674569568258

Finally - don't forget to be paranoid!

12/12

https://twitter.com/PaulRBerg/status/1539238349923295235

You can read the unrolled version of this thread here:

https://typefully.com/PaulRBerg/nkgrFkU

Paul Berg's Solidity Tips

1/ I'm excited to announce PRBTest!

PRBTest is a modern collection of testing assertions for Solidity, meant to be a drop-in replacement for DSTest.

Feature-packed, type-rich, with versioned releases, and designed to be used with Foundry.

https://github.com/paulrberg/prb-test

2/ Feature-packed means lots of assertions. Booleans, equalities, inequalities, approximate equalities, numerical comparisons, and even array inclusions.

Type-rich means overloads for `address`, `bytes`, `bytes32`, `int256`, `string` and `uint256`, and their array equivalents.

3/ So why choose PRBTest over DSTest?

I wrote about this at length in the README.

TL;DR

1. Missing features
2. No release versioning
3. Path dependence led to balkanization of DSTest forks
4. Lack of backwards compatibility with Node.js

https://github.com/paulrberg/prb-test/tree/ce5d128391feb6f64dff05d8d4431c799646b2c5#why-choose-prbtest-over-dstest

4/ Refer to the GitHub repo for instructions on how to install PRBTest.

It's meant to be used with Forge, but you can also use it in a Node.js environment like Hardhat.

https://github.com/paulrberg/prb-test#install

After you install it, here's how to use PRBTest:

5/ PRBTest remains compatible with all testing utilities from Forge Std, except for their "Test" contract.

Though even that might change in the future - I have created a few PRs to make Forge Std more modular and more compatible with PRBTest.

6/ Just like my other projects PRBMath and PRBProxy, PRBTest is unapologetically available only in Solidity v0.8

It's time for the industry to move on.

There's a long list of awesome features available exclusively in v0.8.

https://docs.soliditylang.org/en/v0.8.0/080-breaking-changes.html

7/ PRBTest is released under the MIT license.

That's it for now. Hope you like it!

You can read an unrolled version of this thread here: https://typefully.com/PaulRBerg/xcK8Al0
