hellwolf (@hellwolf) • Hey
I use here to mostly write stuff about Superfluid Protocol.
mottoes:
"Tu ne cede malis, sed contra audentior ito."
"I have fought a good fight, I have fin
Publications
- Few days into Uniswap Fees, let's have a look what it is and how it has been performing.
1) "On a limited set of token pairs, Uniswap Labs charges a flat fee of 0.15% to sustainably fund our operations." See: https://lnkd.in/d7aC7AaA
2) The fee is not charged at the protocol-level. Instead, the app.uniswap.org frontend retrieves `portionAmount` and `portionRecipient` fields from api.uniswap.org/v2/quote.
3) Uniswap v3 currently has two types transaction: Classic Universal Router (https://lnkd.in/dqVGjsUc) and UniswapX (https://lnkd.in/dqVGjsUc).
Both of them can charge such interface fee. E.g fee through Universal is https://lnkd.in/djz_as-7
4) Since the launch on 16th October, the interface fee cumulatively reached more than $130,000. That's around 30-40k$/day
5) Putting this into the context, in a very rough estimation, Uniswap v3 USDC related transaction is around 20-30B$ for the past 90 days, or 200-300M/day. That earns uniswap 0.15$ per $1000 traded.
Comparing to in the Nasdaq cash equity business, it earns Nasdaq $0.10-$.13 / $1000 traded.
Coincident? Perhaps, we will wait more days and data to keep comparing the numbers.
- So I did a couple of data crunch on friend.tech, here is the dashboard: https://lnkd.in/dSxXsieB
Context, what is friendt.tech, here is the GPT Summary of https://lnkd.in/dcT353Zq, so you don't have to, though I haven't done full fact-check:
1) Friend.tech is a decentralized social app, built on the Base network, that connects creators with their audience through tokenized attention.
2) The influence of creators on Friend.tech is represented by "keys" which can be traded to access exclusive perks.
3) The application launched on August 10, 2023, and soon after it saw a surge in usage with over 200,000 users and $230 million in trading volume.
4) Friend.tech allows creators to monetize their social reach, offering new opportunities for creators to connect with their audience.
5) The value of creators' keys is dictated by supply and demand, allowing for variability in what these keys can offer (e.g., exclusive chatrooms).
6) Friend.tech has attracted cryptocurrency influencers and esports personalities since its launch.
7) The platform operates via a Progressive Web Application (PWA), allowing users to manage their accounts from a browser-enabled mobile application.
8) Aside from its social aspect, Friend.tech also has an airdrop tab, which introduces a point system with future uses in the platform.
9) Despite its growing popularity, there have been concerns about user privacy on Friend.tech, particularly with the link between users' Twitter profiles and wallet addresses.
10) Friend.tech aims to tokenize influence and attention in unique ways, opening up new possibilities in decentralized social platforms.
I have only very superfcial takeway to share for now, please read the dashboard and let me now if you can infer anything from it. The superficial takeways from me are:
1) There are still lots of on-chain capital in small accounts willing to jump into new products to try out.
2) Majority are still likely airdrop farmers.
3) Nonetheless, it has contributed ~$31M dollar worth of friend.tech protocol fees in ETH.
- https://slickgpt.vercel.app/shared/tight-weak-australia
> A cypherpunk, technocrat, speculator, and grifter sat on the edge of the digital sea. A single golden Bitcoin floated on the water, glinting in the simulated sunlight.
"Look," the cypherpunk said, delight filling his voice, "a symbol of freedom, its encryption unlocking chains of trust."
"But it is merely code," the technocrat argued, "No matter how complex, or encrypted, it falls under the templates of technology.”
"It is an investment, heralding prosperity," proclaimed the speculator, his eyes wide with dreams of wealth.
Yet the grifter, quiet until now, smiled, saying: "It's neither. Nor. And both."
And in that moment, the Bitcoin sank beneath the digital waves, gone, leaving them in silence. And yet, their arguments did not cease. For, in truth, the Bitcoin was not the source of their struggle, but merely a reflection of it.
From this, we understand that the value, like all things, is often not inherent, but perceived; Not in the object, but in the eye of the beholder.
- As a cypherpunk, one doesn't need a business case for being so.
But for ones want to make money from crypto natives, you better have a business. Here is one analysis of SAFE on ethereum, polygon and optimism: https://dune.com/miaozc/safe-business-research; and my write-up on linkedin: https://www.linkedin.com/feed/update/urn:li:activity:7115988433977667584/
www.linkedin.com/feed/update/urn:li:activity:7115988433977667584/
- What is wrong with this contract: https://polygonscan.com/address/0x805251d442690dc16e309e614a03ce9913ef1193 ?
- #Nix helped to setup a #echidna for our long running test over the weekend on a idle fresh mac mini machine. Super easy.
Last stretch before shipping GDA. #Security at #Superfluid
- Before talking about how we use Echidna, certora, and the future plan of making future Superfluid protocol correct-by-construction, let's talk about the mundane testing strategy first.
Superfluid protocol monorepo started when the tooling choices were between truffle and hardhat. Since foundry was created, we have been converting tests to foundry tests.
We merge the LCOV reports from both hardhat and foundry into one, then upload to codecov publically. You can view our code coverage of the ethereum-contracts package at https://app.codecov.io/gh/superfluid-finance/protocol-monorepo/tree/dev/packages%2Fethereum-contracts, which stood around a loudable ~97%.
In the next post, I will talk about something more more exciting: how we use Echidina (https://github.com/crytic/echidna) to further enhance our testing strategy.
- The third session of the internal review of GDA feature in #Superfluid protocol is here!
https://youtu.be/KKS1SjlF7yg
- Right, do things; do the right things; or **do things right**?
In the decentralized finance part of web3, we have exhausted the bull market for the "right, do things" phase, and now many projects are figuring out how to "do the right things."
Additionally, the commitment to a permission-less system and code-is-law immutability makes the decentralized finance vision of web3 uniquely challenging compared to traditional finance. The complexity arises from this commitment's need for privacy and security. And complexity is the enemy of "doing things right." While the principle for doing things right in programming is the pursuit of "program correctness."
For this conundrum, we have a few approaches:
1) Keep things simple.
2) Compromise on immutability through upgradability.
3) Pile in post-hoc verification, including testing, automatic theorem proving, etc.
4) Use tooling that is friendlier for **correctness-by-construction**.
The vision behind Superfluid is extensive, and taking compromising on immutability is not acceptable to many either. So it comes down to how I can **manage the complexity**.
In the following posts, I will describe how our v1 code base has used techniques for post-hoc verification, including the experiment with the Certora Verification Language v1. In time, I will also show what correctness-by-construction is and what steps I have been taking to make it a closer reality to the Ethereum ecosystem.
- We had two sessions of internal review of the upcoming GDA feature in Superfluid protocol. One more to go, check them out:
https://www.youtube.com/watch?v=8JuvByBHeNw
https://www.youtube.com/watch?v=7cjwLpsQ2OE&t=15s
- #Solidity as a language is a bastardized mix of a bit C++, Python, Javascript, etc (reference: https://docs.soliditylang.org/en/latest/language-influences.html#language-influences ).
It has finished its historical mission of bringing more developers to program on EVM, but new solid progress must be made to bring correctness-by-construction ( https://dl.acm.org/doi/abs/10.1145/3591335.3591343 ) to EVM where we need it desperately.
- First deployable binary:
- yolc the solc:
`nix-shell$ yolc yolc-examples:Basic | solc --strict-assembly - > /dev/null && echo yes`
`yes`
- This would be how I will etherscan verify the code compiled by a "mystery" compiler: a stunt contract.
A stunt contract is a solidity contract with all the real logic in inline bytecode, while leaving the actual source code inlined in comments. This way you can get the source code verified on Etherscan, while at the same time without having to begging etherscan to support your compiler yet.
- We are updating to solidity 0.8.21 for the new feature "Allow qualified access to events from other contracts."
`$ nix shell github:hellwolf/solc.nix#solc_0_8_21`
`$ solc-0.8.21 - <<EOF`
`// SPDX-License-Identifier: UNLICENSED`
`pragma solidity ^0.8.21;`
`contract A { event eerk(); }`
`contract B { function foo() internal { emit A.eerk(); } }`
`EOF`
`Compiler run successful. No output generated.`
Ref: https://github.com/superfluid-finance/protocol-monorepo/issues/1530
- https://medium.com/p/a-solidity-compilers-collection-in-nix-eea924e1fafc
A small write-up about `solc.nix` (A Solidity Compilers Collection in Nix), in case you need it.
- "American Pepe: GM USA" <-- can someone use AI to generate an episode of this?
- I am going to live fix the deficiency of documentation about the internals of Superfluild Protocol v1 over the next few weeks. For your inquisitive ones, feel free to jump in the live sessions on twitch: https://www.twitch.tv/miaozc/schedule?seriesID=f2823696-578e-4f9f-96d5-4ddd4b7afa5c
- Creation keeps you happy.
I made some solid progress and wrote a bit more description and motivation texts about the project, and having a few people signing up already.
**https://github.com/hellwolf/LoliYul**
Want alpha? Check it out.
- Mirror this post & automatically get a Superfluid stream 🌊
This is how it works 👇
1. Mirror this post 🔁
2. Follow @superfluid.lens on Lens 🌿
**3. Get a WMATIC stream to your wallet** until the campaign ends 🌊
You can check your stream here: https://app.superfluid.finance/
This is a new way how to boost content on Web3 social platforms.
The campaign is powered by @fluidsense.lens: a decentralized web3 advertising platform built with @superfluid.lens & @lensprotocol 🚀
- Optimized the outputs, improved surface syntax, still lots of room to adjust. But now move on to an end to end demo...
- https://lenster.xyz/posts/0x019da0-0x1e
Check it out builders!
- ( an follow-up of https://lenster.xyz/posts/0x019d10-0x17-DA-f8c892e2 )
I have gone pretty far today: I have compiled a simplified ERC20 Transfer function to a PlantUML representation of its wiring diagram. I believe with a few more focused days of hacking I should be able to just compile them to legal Solidity Yul code.
To recap: the technique of compiling linear functions to any Symmetrical Monoidal Category (SMC) indeed can work quite nicely.
But what does this actually mean in plainer language? It means if one can define Solidity/Yul as a SMC, one could then compile any host languages that support linear functions to Solidity/Yul and eventually deploy-able EVM code:
1) But what is linear functions? It is a type-level feature that a supported programming language can track if a variable is used once and only once. This restriction is the core that allows conversion of these functions to "wiring diagrams" or in more formal term the SMC.
2) What host languages can support linear functions? Haskell (library support already, I am using linear-smc), and maybe Rust (no library support yet AFAIK).
I have been fascinated by this tech ever since I have heard it because:
- It is a pretty general technique, using it for EVM code is just one import trick it can do that is also close to what am working on otherwise.
- "The next 700 programming languages, Peter Landin 1966" has reasoned that we should have less special purpose languages but a few strong general purpose languages.
Here is the beautiful wiring diagram of ERC20 Transfer compiled from a few liens of Haskell linear functions, soon EVM code 🙂
- Did you know that a prototype version of Super Token v2 is coming to Starknet first, thanks to Starknet proponent @godspower.lens? https://github.com/superfluid-finance/protocol-monorepo/pull/1275
It will have all the generalized payment primitives without Super App programming framework yet, but will be a show case of the applicability of specification of Super Token to any target platforms going forward!
- One thing I have been fascinated about is https://arxiv.org/abs/2103.06195
I have been playing around with its current implementation, and the more I do the more I believe that compiling a host language with linear function support (agda/haskell, or maybe even rust) to any target machine that can be modeled in SMC.
In plainer words, you may compile an Agda/Haskell program to EVM code without much fuss, which is a leap towards an entirely different route for using dependently-typed program to generate EVM code (as opposed to blackbox formal verification approach using SMTChecker/Certora)
If you understand what I mean so far, happy to chat more in details!
- "The little engine that could", coming to Superfluid Protocol soon....
- Conceptual View of Superfluid Pool, enabled by a feature called "general distribution", coming to Superfluid Protocol soon.
- Idea must live on - be an idea maxi; while tech must move on - be no tech maxi.
Like waves, tech ebbs and flows, revealing the lasting ideas beneath that are not to be washed away.
- Certora (https://docs.certora.com/en/latest/docs/whitepaper/) provides a suite of tools for auditing smart contracts. At its core, Certora Prover packages state-of-the-art open-source solvers through its CVL (Certora Verification Language), in which specifications are written for formal verification.
Just as the Aave GHO project sees the benefits of using Certora, Superfluid has also recently started to use Certora to formally verify some of its components in the current live v1 and its future versions.
Formal verification is an important step that paves the way for an upgrade of the protocol where Super Token becomes a token framework without upgradability that everyone can trust. Because through the formal verification of Super Tokens, we will gain the highest confidence in the correctness of the rich feature set that Superfluid protocol provides. Though formal verification is not a silver bullet, we will continue to use thorough testing and manual auditing to strengthen the area that F/V cannot cover.
If you want to see how I have been using it in our NextGen code, find me at EthereumZuri.ch, where I will talk about "Functional Programming in Solidity," in which I will also showcase how those new codes are verified using Certora!
- Announcing Superfluid subscriptions 🌊
We believe everyone should have full control of their own payment infrastructure.
As an open-source, self-hosted & fully customizable toolkit, Superfluid subscriptions allow you to build crypto-native checkouts & effortlessly automate recurring tx.
👉 Monetize your content or community
👉 Scale your user base & generate consistent income over time
👉 Maintain real-time cashflow & mitigate the fear of late payments
Any Lens buildooors out there who are interested in monetizing their platform/content? 👀
https://superfluid.finance/subscriptions
- This is Solidity code, and it may look different than you are used to:
function shiftFlow2b(BasicParticle memory a, PDPoolIndex memory b, FlowRate dr, Time t) internal pure
returns (BasicParticle memory m, PDPoolIndex memory n, FlowRate r1)
{
BasicParticle memory mempty;
BasicParticle memory a1;
BasicParticle memory a2;
FlowRate r = b.wrapped_particle.flow_rate.mul(b.total_units);
(a1, , ) = mempty.flow2(b, r.inv(), t);
(a2, n, r1) = mempty.flow2(b, r + dr, t);
m = a.mappend(a1).mappend(a2);
}
I will be speaking about why it is so and how it matters at https://ethereumzuri.ch/ ! I'd be more than delighted to meet you there and talk about experimenting functional programming using solidity!
- Custom Types as they are now should just be called aliases or "a.k.a" types.
- No operator overload
- No implicit wrap / unwrap when is clear what you want to do.
eg.
function add(FlowRate a, FlowRate b) internal pure returns (FlowRate) { <-- Return type defined
return FlowRate.wrap(FlowRate.unwrap(a) + FlowRate.unwrap(b));
^-- Why? ^--- operands are basic types, imply unwrap itself
}
- Without generics, this is the sort of none sense you end up in Solidity using the half-baked custom types:
```
type Time is uint32;
type Value is int256;
type FlowRate is int96;
type Unit is uint128;
library MonetaryTypes {
function add(Time a, Time b) internal pure returns (Time) {
return Time.wrap(Time.unwrap(a) + Time.unwrap(b));
}
function sub(Time a, Time b) internal pure returns (Time) {
return Time.wrap(Time.unwrap(a) - Time.unwrap(b));
}
function inv(Value x) internal pure returns (Value) {
return Value.wrap(-Value.unwrap(x));
}
// TODO: add_to
function add(Value a, Value b) internal pure returns (Value) {
return Value.wrap(Value.unwrap(a) + Value.unwrap(b));
}
function sub(Value a, Value b) internal pure returns (Value) {
return Value.wrap(Value.unwrap(a) - Value.unwrap(b));
}
function add(FlowRate a, FlowRate b) internal pure returns (FlowRate) {
return FlowRate.wrap(FlowRate.unwrap(a) + FlowRate.unwrap(b));
}
function inv(FlowRate r) internal pure returns (FlowRate) {
return FlowRate.wrap(-FlowRate.unwrap(r));
}
function mul(FlowRate r, Time t) internal pure returns (Value) {
return Value.wrap(FlowRate.unwrap(r) * int(uint(Time.unwrap(t))));
}
function add(Unit a, Unit b) internal pure returns (Unit) {
return Unit.wrap(Unit.unwrap(a) + Unit.unwrap(b));
}
function sub(Unit a, Unit b) internal pure returns (Unit) {
return Unit.wrap(Unit.unwrap(a) - Unit.unwrap(b));
}
function mul(Value a, Unit b) internal pure returns (Value) {
return Value.wrap(Value.unwrap(a) * int256(uint256(Unit.unwrap(b))));
}
function div(Value a, Unit b) internal pure returns (Value) {
return Value.wrap(Value.unwrap(a) / int256(uint256(Unit.unwrap(b))));
}
}
```
In last year's soliditycon, it was said that the generics is coming to solidity. And I also found this reference: https://github.com/ethereum/solidity/issues/13776. Let's hope it is not half-ass baked again like custom errors.
- I am live coding: https://www.twitch.tv/miaozc/videos
- Can we make uniswap v1/v2 style exchanges continuous in time? Or can we have zero intermediate liquidity market maker using Superfluid flows of money?
Yes!
Superfluid protocol applies FRP (Functional Reactive Programming) to money, the result is the various designs of Reactive Exchange that can SLAMM (Streaming Liquidity Automatic Market Makers), especially:
I just published this article to explain it all! Check it out:
https://medium.com/@miaozc/reactive-exchanges-88c77eaba4ed
- Question of the day: does DeFi belong to the "**correctness realm,**" and if so, then has exploratory programming using smart contracts for DeFi run its course; if not, why?
This rather loaded question summarizes the thoughts I had after reading a wonderful paper. This paper discusses the myths and "mythconceptions" in software and software development.
Two myths that I found the most relevant to what I am doing right now are:
- **correctness** favors functional correctness over **fitness for purpose**,
- **specification** favors early specification over **exploratory programming**.
The "**good-enough realm**" vs. "**correctness realm**" mental model is very instructive in assessing the problem in front of you, and the "**exploratory programming**" is both a placebo and a reminder of not knowing what exactly the problem is yet.
*Being stuck in exploratory programming for a problem belonging to the correctness realm is hubris, and refusing exploratory programming for a problem in the good-enough realm is pedantry.*
Hence the original question of this post.
References:
- original paper: https://lnkd.in/dyw7pkZx,
- and its SPLASH'22 video: https://lnkd.in/dS2meZY3
- Did you know that Superfluid protocol monorepo provides Nix development shells? Checkout https://github.com/superfluid-finance/protocol-monorepo/blob/dev/CONTRIBUTING.md#setup-tooling, with nix you can be a whitehacker and having slither, echidna, etc. setup without hassles!
- What is [ERC20x](https://erc20x.xyz/)?
ERC20x is set of ERC20 extensions amalgamating the idea of *Superfluid Money* with the principle of *tokenize all data* using ERC721.
You get:
*** Superfluid Money Inspired** precice payment primitives.
*** Token-centric APIs** for full feature set.
*** Existential NFTs** for accessing features via wallets.
*** Accounting Information Recoverability** by design.
Still a work in progress work, but join the early discussion at: https://github.com/superfluid-finance/protocol-monorepo/discussions/1188
- As a Linux/Unix geek since kernel 1.x, I am in favor of the idea of having KISS-principled, reusable, deploy-and-done smart contract utilities which are good at what they are doing.
E.g. 300 LoC of Sablier.sol is**** really**** cute, but it would be like comparing `ed` with `emacs/vim/vscode`, when it comes to what Superfluid would like to achieve.
Managing [essential complexity](https://en.wikipedia.org/wiki/No_Silver_Bullet) is the foremost important task for Superfluid V2, because we believe in the power of programmable, composable and semantically-rich money and we want to bring it to the world by tackling the challenges one by one.
Let's face it, comparing to the nuclear fusion project Helion (https://www.youtube.com/watch?v=_bDXXWQxK38), we are like doing kids playing house here. The spirit of human voyager lives on: we see where the new world is, and we will not stop until we get there!
- What is Superfluid Money?
Superfluid Money is internet money that is programmable, composable and semantically rich:
- It is **semantically rich**, because it supports novel primitives such as flows (constant flow value transfer from one address to another address), and distribution index (value transfer between one to many addresses, instantly or as flows), etc.
- It is **composable**, because the value is usable the moment its transferred.
- It is **programmable**, because automation can be done by code using framework such as "Super Apps" (https://lnkd.in/djeaE7ab.)
- Lastly, it is **internet money**, since its first implementation came to life thanks to Ethereum's open spirit and innovation on globally scaled trust without corruptible central entities.
Something even bigger at Superfluid is coming next year, happy holidays!
#reactive #superfluid #money #fintech