Setup

• The instructions in their README were clear and with a couple of minutes I had the local version running

• I needed to add some credits to run - nice work OpenAI

• The first repo I tried was over the size limit, but that was my bad as I zipped with a lot of artifacts

• Adding a folder non zipped gives you a good overview of the code with issues highlighted

Runs

The detect.md prompt says to only flag issues related to loss of funds. Because of this it is instructed to only report issues as high, and seems a bit trigger happy (especially with the 5.2 model). Though the results handler in the code itself seems ready to handle cases from critical to info.

Megaparlay

Megaparlay was a simple set of contracts for making parlays on the Conditional Token Framework. It had ~700 LOC of interest in the main contracts, along with testing and deployment scripts.

V-001 [High] (Both) Stale userBalances accounting enables double-withdrawal and drains future jackpot funds

userBalances is only incremented on deposit and (sometimes) decremented on migration refunds, but is never settled on loss or win, enabling past participants to withdraw against future deposits after withdrawalsEnabled is triggered.

My Feedback

withdrawlsEnabled is a flag that lets users claim their balances in case the owner stops uploading parlays for over a month. That would result in the game becoming stale and un-winnable.

Megaparlay V1 was planned as a single use jackpot game, that was eluded to in the comments on the contract and README. It's true that if they wanted to players could have kept making parlays after the first jackpot was won.

After the withdrawal timeout was triggered any players who lost in the original game could have claimed their refund in this non existent second game before the new players. This was known but could have been easily fixed by closing the game more officially with another flag, good to highlight tho.

V-002 [High] (5.2 only) Anyone can front-run and choose which winning parlay receives the jackpot

claimWin() does not require msg.sender to be the parlay owner, allowing third parties to decide the jackpot recipient among multiple winning parlays by calling claimWin() first for their chosen parlayId.

My Feedback

This was covered in the comments and was intentional. V1 was a simple game where the first winner to claim took the jackpot. This is not high, but possibly useful to flag as info.

Megaparlay Review

• The issue caught by both was not going to be a problem given the wider context of the project, but it certainly was something that could have been easily fixed on the contract and was correctly flagged as high.

• 5.2 also flagged something else that was not an issue as it was commented and part of the design of the simple V1 contract, 5.1-max correctly ignored this.

• 5.2 gave a deeper walk through of the issue and a better POC.

Onit

Onit was a complex set of contracts that implemented a new type of prediction market. The code included low level bit manipulation, math functions (with prb/math), multiple token standards, and factory contracts.

V-001 [High] (Both) Unchecked ERC20 transferFrom allows minting shares without payment

The order router does not verify transferFrom success for ERC20 markets, so a trade can mint outcome shares even when no tokens were transferred to the market, enabling subsequent draining of the market’s real token reserves.

My Feedback

This would definitely be high. It exists in a file that was never used in production and should have been deleted, good flag.

V-002 [High] (5.2 only) Payable router/factory functions can permanently lock ETH sent with ERC20 flows

Several functions are payable but do not account for msg.value when the market uses an ERC20, and there is no recovery mechanism, causing accidental or UI-induced ETH to become irretrievable.

My Feedback

Maybe this could be flagged as info, but there is no attack that can come from this. If the user or client accidentally sends ETH to a payable function when creating a market or betting on an ERC20 market that ETH would not be recoverable. But this is not something essential to deal with on the contract, and adding 'withdraw' functions to deal with this is another attack vector.

V-003 [High] (5.2 only) Voided-market refunds can be permanently blocked by transferable ERC1155 NFTs

Refunds in voided markets require burning an ERC1155 NFT from the trader’s address, but the NFT is transferable and not kept in sync with tradersStake, which can make refunds impossible and lock funds.

My Feedback

The only sell mechanism we had in this version of Onit was that a trader could sell their shares back to the market for their current value. We didn't have direct sales of positions to others, but the underlying ERC1155 transfer function was still usable. There was no functionality built around this on the protocol, and no real reason why someone would buy this NFT as it was more of an artifact related to the market to hold in your wallet. But without context on that, it's correct to flag this as high this could have been made non transferrable to make this clearer.

V-004 [High] (5.2 only) Permit-based allowance updates are front-runnable, enabling allowance hijacking and theft of market admin funds

When a permit signature is provided, setAllowances allows any caller to set (or rewrite) the router’s internal allowances for the market admin without authenticating who chose the spender list, making the transaction front-runnable and enabling an attacker to redirect allowances to themselves and spend the market admin’s funds.

My Feedback

This is definitely high and was missed. If a market admin sets allowances, we check their signature to make the ERC20 permit to allow the order router to allow a spender to use some tokens. But this signature is only over the amount, nonce, deadline, owner and the order router - it does not account for the array of allowed spenders, meaning as long as the overall amount permitted matches the signed amount, any allow list would pass. If this tx was picked up in the mempool an attacker could replace one of the allowed spenders with their own address and make a bet on the market.

Overall Feedback

• The tool is useful and it's cool to be able to compare the models findings / style easily in the UI

• The UI is nice and very easy to use.

• Need more detail on the recent runs, like what model was used, did it pass etc.

  

• Only detect was enabled, there are plans to get patch and exploit working and I'd be keen to try them.

• It is something I will likely use in my next project.

I'm building something on top of Polymarket and I need to go direct to the Conditional Tokens they use for events, so I need to deploy on Polygon.

When trying to deploy to testnet I was reminded that Polygon (PoS where Polymarket is) doesn't support anything after the Paris hardfork, and since I used Solidity v0.8.30 that was a problem.

I was afraid I'd have to update the compiler version across my contracts, and when I tried to, it caused a lot of build errors in my tests. Then I thought that since both solc and evm_version are included in the foundry.toml file, it'd make sense if you could set an older evm_version and the compiled code would avoid opcodes that didn't exist on that version.

Turns out that works and you can change the evm_version and it will compile to exclude any opcodes supported in that Solidity version which that shouldn't be used on that EVM version.

There is even a convenient tool to check. Running cast disassemble <bytecode> will show a human readable version of the code that you can check for banned opcodes like PUSH0.

It's worth noting that this might not always work. My contracts were pretty simple and didn't explicitly use any features that were not present in v0.8.19 so recompiling and checking all my tests was enough.

Work

From a diary entry in week 22, I wrote "I guess a lot has happened since the start of the year, but all within a very small set of things, and almost entirely in Berlin".

It usually feels like things are going quickly when you have a repetitive routine, and compared to the past couple of years in Barcelona when I travelled a lot, this year has been very same-y.

Likely because 2025 was the most intense year of building Onit. Since we pivoted in January we had to research and build our new product from scratch, and because we've been low on funds, things have been pretty urgent for most of the year.

I don't think that quote was a complaint tho, I've enjoyed being here and the work I've done. There are interesting crypto events, and working from Web3 Hub has been great. It's nice to be with a group of people working in the same area, but not on the same thing. I tried another general cowork when I first arrived and didn't really like it, there were a lot of people, but I didn't care much about what they were working on.

Public Spaces

Berlin has great parks, libraries, and abandoned buildings. Cycling around Tempelhofer Feld is relaxing, and going down the main runway at sunset when the wind is blowing from behind is probably my favourite thing to do in the city.

Although not really 'public spaces', events held in abandoned/repurposed buildings are cool. They range from gigs to light exhibitions, and sometimes involve just opening a building like Kraftwerk for you to wander around. Feels like a thing that won't last forever in Berlin and I'm glad to have made the most of it.

Staatsbibliothek Potsdamer is my favourite building in Berlin and probably in the world, it's such a strange shape, and feels very different depending on what part you're in. Some low roofs, some huge rooms, a couple of spiral staircases, a few slabs of concrete, comfortable chairs, and a cafe that sells really disgusting sausages, it all somehow works together to make a great library.

Socialism

I've generally been in the 'capitalism not perfect but gud, socialism sounds gud but isn't in reality' camp but only had a basic understanding of why. Berlin is very socialist so I figured while being here I'd commit some time to reading about it, seeing the sights, and trying to understand it better.

Have worked through these, seen the Socialist Memorial and a few exhibitions, and started dropping into The Left Berlin. I think I'll write about where I stand on it someday, and I would like to talk if it's something you're interested in too.

Good

Crypto: There are regular events, and Berlin Blockchain week is nice to have here. There's also a couple of dedicated crypto coworking spots, one where I spend most of my time (shout out to hellno.eth, df, and levertz for being around for most of that time too).

Falafel: Everywhere

Clubbing: I haven't done much clubbing and didn't expect to, but the places I've seen have been fun. There is definitely no major city in the world that accepts such madness, both in the clubs and on the streets/ Späti.

Bad

Winter: Everyone says that winter in Berlin is depressing... Can confirm it is dark and freezing, but actually not so awful. There is a lot going on and they have enough interesting indoor events to get through, Stranger Chess even migrate indoors to the lobby of a cinema for the coldest months. There are loads of parks so it's usually possible to get a walk around one in the couple of hours or daylight.

Loud Sirens: Ambulances are absurdly loud. Turns out they use horns not sirens so there is no ramp up of noise.

Door Naming??: You don't have an apartment number, but you put your name on the door. It's annoying cause to update the name you have to find out the name of the person who was renting before you. Also I'd rather not have my name on the front of the building? I haven't done it yet and just avoid getting mail at home.

Insane Metro: Particularly on weekends the metro is crazy, never too busy, but always a complete mess, with a lot of very crusty people.

Overall I've had a good year (8/10) and I'm glad I moved here. I plan to stay a bit longer and might do another update when I do eventually leave.

That means for a market like ‘How many people will attend the event?’, instead of being forced into options like A: <10,000 B: 10,000 - 20,000 etc, you can say I think 12,345 +/-2,000 people will attend.

To do this we needed to translate the traders bet and confidence into an equation that could generate a distribution of points over some interval - ie we needed a probability density function. 

When I looked to see if any probability density function (PDF) libraries existed, there were 3 main stand alone repos in solidity.

1. Solstat: Primitive Finance

2. Statistics Solidity: DeltaDex Protocol

3. Solgauss: Cairo.eth

All the libraries are useful and work under certain conditions, but they lacked some features that we needed.

Our ideal library needed:

• To generate PDFs for a range of $$\mu$$ and $$\sigma$$ . The constraint of $$\mu=0$$,

  $$\sigma=1$$ was too restrictive.

• To be able to operate on different scales. So people can predict values on the order of $$10$$ or $$10\space eth$$

• Utilities to relate multiple PDFs (like finding the point of maximum difference between 2 PDFs)

• A test framework that could link to our other code related to the distribution market.

Solidity does not have built in support for floating point math, so any values that have decimals would get cut off. The worst form of this is when a number is a decimal less than 1, which just gets rounded to 0, something that is obviously bad for a PDF which has terms like $$\frac{1}{\sigma\sqrt2\pi}$$.

To get around this we scale all our numbers up and work in ‘fixed point math’ where we assume a huge number like $$1e^{18}$$ actually equals 1. That’s great because now instead of rounding numbers like $$\pi\approx3$$ we can do

$$\pi=3.141592653589793238 * 1e^{18} = 3141592653589793238$$

So any time we see a number like that, we need to remember the amount we scaled it by, and be careful to either operate on that scale, or convert it back down offchain. Scaling numbers like this is straightforward when we just want to do simple operations like adding or dividing numbers. But the PDF is not so simple, and if we are to work with scaled numbers, we need to see how it behaves for different inputs. 

$$ p(x) = \frac{1}{\sigma\sqrt{2\pi}} e^{-\frac{1}{2}\left(\frac{x-\mu}{\sigma}\right)^2} $$

Looking at the above equation and thinking back to our original example of predicting attendees at an event, we can gain some understanding of how the PDF should scale. If we consider a normal event to have 100 attendees $$\pm20$$, then we can work out the probability that x people will show up. One thing to notice is that since all those parameters are measured in attendees, if we scale things, then scaling all of the parameters by the same amount makes sense.

Since the exponent $${-\frac{1}{2}\left(\frac{x-\mu}{\sigma}\right)^2}$$ has equal orders of scaling in the numerator and denominator, any scaling cancels out. The coefficient has a sigma in the denominator, meaning that scaling the inputs will produce a much smaller peak. This aligns with the normalisation constraint on PDFs, $$\int_{-\infty}^{\infty}{p(x)}dx=1$$, since when we stretch the range with our scaling, the height must get smaller to keep the area the same.

But in Solidity we are actually going to be working in fixed point math where $$1e^{18}=1$$, so we need to scale our inputs to convert them to this number system, and also need to consider the other constants like $$2$$ and $$\pi$$ in the same way. This is why we use a library like Prb-Math.

Since we want to be able to work with negative numbers, we choose the (signed decimal) SD59x18 number type from PRB-Math. This lets us operate with 59 integer numbers and 18 decimals by representing those numbers in the range of an int256.

/// User defined type to ensure we know we are operating with a custom number type, not int256
type SD59x18 is int256;
// Upper bound is type(int256).max
int256 constant uMAX_SD59x18 = 57896044618658097711785492504343953926634992332820282019728_792003956564819967;
// Lower bound is type(int256).min
int256 constant uMIN_SD59x18 = -57896044618658097711785492504343953926634992332820282019728_792003956564819968;

Using this number type allows us allows us to calculate the PDF from the $$f(x)$$ curve in the Desmos graph above for inputs: $$x=3, \mu=2, \sigma=1$$

function pdf(SD59x18 x, SD59x18 mean, SD59x18 sigma) returns (SD59x18 p) {
/// x - µ = 1e^18
SD59x18 xMinusMean = x - mean;
/// -(x - µ)^2 = -1e^18
SD59x18 exponentNumerator = -xMinusMean.pow(TWO);
/// 2σ^2 = 2e^18
SD59x18 exponentDenominator = TWO.mul(sigma.pow(TWO));
/// full exponent = -5e^17
SD59x18 exponentFull = exponentNumerator.div(exponentDenominator);
/// e^((-(x - µ)^2) / 2σ^2) = 6.07e17
SD59x18 exponentResult = exp(exponentFull);
/// σ√2π = 2.51e18
SD59x18 denominator = sigma.mul(SQRT_2PI);
/// 1 / σ√2π = 3.99e^17
SD59x18 coefficient = inv(denominator);
/// p = (1 / σ√2π)e^((-(x - µ)^2) / 2σ^2) = 2.42e^17
p = mul(coefficient, exponentResult)
}

As you can see the result is $$2.42e^{17}$$ , which if you consider $$1e^{18}=1$$, is the same as saying $$0.242$$. This agrees with Desmos and shows that we don't have to lose precision when working with decimals in Solidity.

The library includes the following functions:

• pdf: The probability density function

• pdfDifference: The difference between two pdfs

• isMinimumPoint: Checks if a point is the minimum point of a curve given by pdf2 - pdf1

• isMaximumPoint: Checks if a point is the maximum point of a curve given by pdf2 - pdf1

• pdfDerivativeAtX: The first derivative of a pdf at a given x

• pdfSecondDerivativeAtX: The second derivative of a pdf at a given x

  These functions have wrappers like the below to receive values in int256, so you don't need to import any Prb-Math types into your code to get values back.

    function pdf(int256 x, int256 mean, int256 sigma) internal pure returns (int256) {
        return pdf(convert(x), convert(mean), convert(sigma)).unwrap();
    }

All tests are run against reference PDF values calculated in typescript like the below.

You can find the code here and if you have any questions drop me a message on farcaster

One of the first things I noticed was the amount of litter in the streets and parks. I'd say the worst areas are on par with Marrakesh or NYC as the most dirty cities I've seen. There are parts of Kreuzberg that almost pull off the trashy look as it fits with the run down graffitied streets, but seeing so much litter blow around the parks is a shame. Attempts to encourage recycling seem less effective when the streets of the city are so bad. The extra charge on bottles/cans is annoying since you only get the refund if you taken them to one of the central recycling centres in a big supermarket. Recycling them in bins on the street means I end up paying more than I should for most drinks.

I haven’t seen the darker months of winter so maybe I don’t fully appreciate this yet, but the streets are noticeably open and bright. It’s a nice feeling when cycling around since many pavements have space for a cycle lane, pedestrians, and terraces in front of cafes. Looking into it more showed that strict building laws which were written in 1853 make it difficult to build anything over 22m. For some reason they decided to maintain those limits when rebuilding Berlin after the war, resulting in a layout that’s nice in the residential areas, but limiting the development of any sort of recognisable skyline. 

The tallest ‘building’ in Berlin was built in 1969, and it’s really more of a TV tower than an actual building. Seems crazy for the capital of the 4th largest economy in the world to have never made an effort to build anything tall - second place is 125m and was also built in 1969. Frankfurt have all 10 of the tallest buildings in Germany, then cities like Cologne and Munich start to have a couple, but Berlin, for its much larger population, is mostly left out. Wether its bad management or difficulties from the reunification in the 90s, Berlin seems like a historical capital that didn't really really keep up with the rest of the country. It's now an old report and I couldn't get newer figures, but in 2016 Berlin was the only capital city in Europe that if removed, would result in an increase in the GDP of it's country.

Another way it seems Berlin is stuck in the 60s is the amount of shops/cafes that take only cash. It’s surprising, and not something I’ve noticed in any other EU city. A mix of things, from lingering paranoia caused by crazy currency devaluations in the 1920s and 1940s, to social stigma around debt get the blame, but whatever it is, it could be the right environment to test better crypto payments. Especially for the smaller retailers who often set high minimum spends on card to save on fees taken by banks. There’s at least one cafe taking payments in USDC and given the number of dedicated web3 coworking spots, that'll hopefully increase.

Ethereum's early development was centred in Berlin and some of the first projects like Gnosis/Safe are still based here. The messiness and lack of drive at the state level seems to leave room for communities to form and get on with their own thing. Since it looks like the place is falling apart, you get the feeling that if everything was to go to shit that many people here would just keep going with what they’re doing. Maybe this is what gives the other lacking parts a positive take. I've enjoyed working at a few coworks (finally settling on Betahaus) and there is a bigger tech ecosystem than in Barcelona, with pretty much daily meetups for things related to work or not. (Fun daily chess meetup in Prenzlauer Berg)

I was lucky to catch the end of summer since apparently the winter is quite brutal, but I’m pretty excited to see what it’s like. Looking forward to meet more people working in crypto and explore wider tech events too. 

A brief look at the current transaction flow for an EOA is a useful place to start, since if our SCA can maintain a similar flow, then both account types can exist in parallel while the transition happens. This saves a lot of code from being rewritten as we can keep using existing hooks in Wagmi like sendTransaction.

When a user on a dapp decides to take some onchain action, a transaction ({to, value, data ...}) is formatted and a wallet is requested to get a signature on that transaction data. The wallet will then (in the case of a "local account") ask some secure store for access to the private key which could be stored on your browser, device, or keychain. If you have permission (by passing a biometrics or a password check) then you get a signature on the transaction, and that signed transaction can be sent onchain.

With a smart account we can define much more flexible logic related to signature validation or transaction execution, but this means we have to extend the basic Viem account API (seen above) to handle that. Below we have a very simple example of the interface an ERC-4337 contract might have, and some important considerations when designing the account.

First thing to note is initialize. This exists because unlike an EOA, the SCA will eventually need to be deployed on each chain it wants to operate on. Generally each type of SCA will have a corresponding "factory" contract which can deploy copies of it. With that in mind we can define a few useful methods that we need to add to our previous Viem account to convert it to a smart account.

• getFactory: Get the address that will deploy our account.

• getFactoryData: Data that the factory will be called with (maybe to set an owner address on the account, or give the contract a name)

• getInitCode: Combines the above two things into one.

Next we have validateUserOp which allows us to define custom validation logic on our account - where userOp is the new transaction object for ERC-4337 smart accounts. This custom validation is usually in a function called _isValidSignature which can also be used for ERC-1271 contract signatures. Because of this we have to adapt our existing signature methods on the Viem account.

• signMessage & signTypedData: These need adapted to not just sign the message or data, but to structure the data to match the way the contract implemented it's _isValidSignature check. Since most ERC-1271 contract signatures adhere to ERC-712, we will wrap the message with some "domain parameters" - things like the verifying contracts address, chain ID, version of contract etc.

• signTransaction: This is no longer used as we don't directly sign transactions anymore!

• signUserOperation: Sign the new transaction object instead.

Another difference we need to deal with is the fact that the EVM does not increment nonce for an address with code when a transaction occurs (only when that that address creates a new contract). Because of this the EntryPoint contract, responsible for handling ERC-4337 transactions, keeps track of the nonce of SCA wallets so we add a method to check that.

• getNonce: Call the entrypoint anytime we want our accounts nonce.

One final thing is that since the smart account will make it's call through the execute function, we still need an EOA somewhere to initiate this. For that, Account Abstraction providers are running 'bundlers' to relay these userOps onchain, so instead of our transport being a node URL, it will be the URL of whatever bundler we're using. With all that together we can start to see the updated smart account.

Thankfully Permissionless, the open source smart account framework from Pimlico, have great wrappers already put together to make this as easy as possible to do in typescript. They conveniently extend the Viem account with all of these functions and more. On top of all that there are some added utilities like getDummySignature which help with gas estimates for userOps. With everything in place, we can complete the picture of how the transaction flow for a smart account will look.

Since the flow between application and wallet is identical to that of the first EOA example, it means we can maintain the same code as we have for EOAs! We keep the new formatting and added account functions in our extended Viem account, we keep the same Wagmi hooks for interacting with a wallet, and we let a bundler handle the forwarding of the userOp onchain... so in the end the developer experience for building with SCAs is similar to EOAs, and the end users benefit from a more versatile and secure account.

A lot of negative feedback has been thrown towards well funded companies applying for the RPGF grants (sorry Alchemy, you’re the scapegoat here). It stems from the belief that a $500 million funded company should not be taking resources from smaller teams — the push back being that, to quote the motto of the Optimism RPGF itself, ‘impact = profit’ and since the companies provide impact, it is fair that they get a share of profits.

I don’t know what it is like to run a company with $500 million in funding, but I imagine the decision to start a project is probably similar to what we, as 2 people with no funding, thought:

• Is this thing worth building

• Do we have capacity to build it

• What do we get in return

Our answers were

• Yes

• Yes, if we drop everything else we’re working on

• A brand new tool which is a huge unlock for users. And by open sourcing, social capital for our small team, earned by contributing something brand new to the community (We genuinely hadn’t even considered the grant, and it just kinda landed in our inbox from Binji months after)

The answers for a $500 million funded company are probably

• Yes

• Yes,

• And the third is where the criticism stems…

Like us, larger companies also get a product for their users. If they decide to gate access or charge for it, then it is not a public good, if they provide it free or open source, and it benefits the ecosystem then by definition it is, so what is the fuss about?

I believe it comes from some contradictions between the public good itself, and the opportunity cost of other smaller projects losing out. A look at the docs from Optimism’s RPGF page makes a few statements.

‘…provided positive impact to the Optimism Collective…’

• Did these companies provide positive impact? Of course.

• Is giving them an inconsequential amount of money relative to their funding the best way to create more positively impact the collective? Probably not.

• Small unfunded teams could receive the same amount and go full time with a year of runway, overall creating a much more significant, and decentralised, impact in the long run. We had to drop all our engineering work to build the work we were awarded for. Supporting more teams to make those leaps can create new companies rather than profit existing ones.

‘… create strong incentive for people to build…’

• It is unlikely that Alchemy or other well funded companies considered the one off return of ~$300k as a dealbreaker in terms of wether the feature was built. So on this point they are not the target profile for these grants and should probably not apply.

• While great PR from contributing to the open source ecosystem is an incentive, it certainly does not require collecting a payout

‘RetroPGF also provides possible exit liquidity for public goods projects’

• This is probably the most out of touch with the larger companies.

When a company like Alchemy open sources some work, they can provide incredible tooling for devs to work with, that can contribute to standardisation around their stack, mutually benefiting the company and community. Since they get good PR (similar to our incentive for early social capital) and since it is perfectly within the rules that VC backed companies can apply, it is understandable why they do so.

But there could be some changes made to make sure future rounds do not have such controversy about the grants that end up getting awarded.

Unsurprisingly, some of the most involved members of the community have already given this thought and are actively working on improvements.

By creating more focused rounds, Optimism could set conditions for projects that have not taken VC funding, or have revenues below a certain amount. Setting specific themes like ‘educational content’ can also ensure allocations are going to make it to valuable projects which may not have received enough votes when up against too many other categories.

Thought is also being given to allowing VC backed companies in, but weighting their potential reward based on how much funding they have taken.

We look forward to seeing how the grants progress, and again are grateful to the community for the award this year! In 2024 we will continue to develop our app, attempt to positively impact the wider Optimism ecosystem, and hopefully build something worth applying with again, however the rules look then!

Peter Ferguson and I first dove into the world of Account Abstraction via the ERC-4337 community on Telegram in mid 2022 when we were looking for the most convenient way to onboard new users into investment DAOs.

We realised that ERC-4337 would let us implement our own logic for what a valid signature to initiate a transaction would be. This meant that we could replace EOAs to let users get onchain with more familiar login flows and less chance of losing/phishing a seed phrase, with the added benefit of not having to compromise on decentralisation as the verification could be done onchain. The question remained as to what exactly would create the signatures.

After a short exploration into using MPC, we seen that passkeys were gaining traction as a replacement for passwords. Passkeys had been tentatively rolled out in iOS 15, and the iOS 16 launch gave them much more importance. Users could now create a public / private key pair which would be securely encrypted and stored in iCloud keychain, giving them the ability to sign in to apps by using Face ID.

The great thing about passkeys was that the elliptic curve used secp256r1 (as opposed to Ethereums native secp256k1) had already been implemented in Solidity - and soon after, teams like Ledger started working on optimised versions which would make it even more efficient.

Armed with the above we put together an iOS app which allowed users to create a passkey wallet and get onchain using only FaceID! We had not received any funding, had not released our alpha, and were in the process of getting our first testers. We decided to open source our work to deepen our involvement in the AA community, remained active in the ERC-4337 telegram, and gave a number of talks and podcasts to share what we had learnt.

Although less directly relevant to the grant, we also produced work on Farcaster after we both got hooked on the developer community and ease of building cool integrations. We were one of the first mobile clients which allowed you to connect with other users, and even make passkey transactions to send them funds.

https://x.com/forumdaos/status/1653755763976749056?s=20

Binji reached out to us late last year and encouraged us to apply so we thought it might be worth a go. At the time both Peter and I were worryingly low on money, and had taken on some freelance work to let us continue to bootstrap Forum. Getting a payout for that early work is a huge boost and really opens up a lot of opportunity for us from here - so thanks Binji and Optimism!

In 2024 we will continue to develop the app, push for the wider adoption of passkeys, and attempt to positively impact the wider Optimism/Ethereum ecosystem.

🔴🔴🔴

Among the EIPs — which map roughly to the Internet Protocol Standards that define the internet — there are proposals that cover low level decisions effecting the execution of code on the EVM, standards for sending data between dApps, and suggested APIs for implementing interactions between end users.

Core EIPs tend to be more involved, and can require the network to change the lowest levels. Decisions here tend to be hard fought as enshirning more functionality directly into into the system comes with some tradeoffs (see this popular travel blog for details)

The less strictly enforced ERCs sit at the opposite end of the spectrum. As they don’t technically require any approval, an ERC can be used by anyone as soon as it is public. While Core proposals focus on technicalities of blockchain infrastructure, ERCs are an attempt to codify an idea into a composable interface; an API to interact with the blockchain state.

ERCs define the functions which end users experience when interacting with the blockchain day to day, and a select few have gone beyond mere technical documentation, or utilities in apps. From here we will look at the ERCs which captured the most fundamental use cases to not only establish themselves as standards, but to spawn fully fledged industries.

‘Tokenizing’ things like voting power in a group, or rewards for playing a game can be useful to standardize comparisons between participants. The issue is that the use cases for a token to represent voting share, and a token to count how much of an in game asset you can spend are very different.

In the ERC-20 spec, essential things like total supply, balance of a user, and how transfers should be carried out are defined in their simplest terms. This lets any smart contract developer inherit the standard, then customise the base functions to their needs. So although the voting power in your group may not be transferable, the in game asset will be. This gives app developers something to work with, since they can build sets of functions that make predictable calls to the base functions, regardless of what internal logic the specific token has decided to add. The biggest example of an app capatilizing on this composability is Uniswap.

Uniswap has built a $3 billion business around facilitating swaps of tokens between users in a permissionless way. Multiple exchanges and trading platforms have popped up to support other actions made possible by tokens like lending, borrowing, or staking. Combining all ERC-20 tokens on the market gives ~$300b in value… not bad for a few lines of code written in 2015.

Perhaps the most extreme example of an ERC producing unpredictable upside is the, at times notorious, ERC-721. Here the concept of non-fungibility was incorporated into an interface similar to ERC-20, allowing each token to represent a unique item, and in many cases, an associated image or metadata.

One major difference between the fallout of this token and ERC-20 is that as well as marketplaces doing billions in trading volume, these tokens have generated everything from ticket platforms to IP rights for movies. The subtle difference of assigning each token associated data allowed artists to produce works with predefined scarcity, or incentivise ownership by acting as ‘token gating’ to online communities.

Some of the more inventive use cases include minting an onchain SVG to redeem a matching watch, or playing chess against an onchain engine and minting the result. And with standards like ERC-6551 giving NFTs the ability to control assets, the next wave could be exciting for a lot more than just price speculation.

Until now the ERCs have mostly been examples of how a widely accepted idea can generate an industry, but the next highlights the risk of having application standards rather than protocol level enforcement. ERC-2981 was not the first (or last) attempt to put NFT royalties onchain, and the debate around the philosophy of recurring revenue heated up in 2022. Whether artists could survive long term without an ongoing revenue stream, or if it was excessive to expect income from a single artwork for all time divided artists and marketplaces alike.

Royalty payments were generally determined by the marketplace, with Opensea making a push for the NFT industry to empower creators to be able to enforce royalties on their collections across all marketplaces. Their rival, Blur, managed to hijack volume through clever incentives for both creators and buyers, including disencentivizing cross selling assets on multiple marketplaces.

In the end ERC-2981 could never ‘solve’ onchain royalties; as with many ERCs it was a standard interface, not a compulsory part of the protocol, and to this day there is no strict enforcement of royalties for NFT creators.

The final industry defining ERC that we will look at is, by some way, the most ambitious. It does not just aim to implement a new token standard, but to emulate the entire transaction and account structure of Ethereum.

ERC-4337 defines an application layer infrastructure in an attempt to replace conventional EOA accounts with smart contract accounts (SCA). From bundler services which send the SCA transactions onchain, to paymasters which can allow dapps to compensate gas spend to drive usage, the industry generated by ERC-4337 is wide reaching.

Companies such as Pimlico, Candide, and Stackup are building this infrastructure and given the billion dollar valuations of other early providers of ERC tooling like Uniswap, the coming years could be an exciting time for both these companies, and SCAs in general. With complimentary ERCs like ERC-6900 (Modular Accounts) users can have much finer control over the actions their wallet can take, and with ERC-7212 (Precompiled for secp256r1 Curve Support) even increased security by signing with a passkey rather than a seed phrase account.

While all types of EIP are capable of producing major shifts in the ecosystem, the most colourful are the ERCs. This is not to say that Core changes can not produce creative new features. Things like the addition of CREATE2 unlocked lots of fun use cases where smart contracts could be predictably deployed to a set address. But the fact that they require such coordination to happen makes them fell a little less magical.

The optionality of throwing a novel design pattern out into the world and having it capture the attention of the network and be implemented at scale is something very important for the still relatively early crypto industry. That said, power laws apply to many aspects of life, and protocol standards are certainly one of them. Of the thousands of proposals which have been made, a small fraction are accepted, and even fewer can claim to have single handedly spawned billion dollar industries. So before you go out and create the next big token standard, go check out the wonderful list of all EIPs so far to see what you’re up against. Good Luck!

This article came about while integrating a very cool library from Ledger into our contracts at Forum. The details of the library aren’t important here, but basically the trick they used was to ‘precompute’ some commonly used values and store them instead of calculating these values each time. In most cases we would just store the values on a contract and be done.

The problem is that the precomputed data includes 512 separate 32 byte values, and each run uses about 50 of them. That means it would take over 100,000 gas (50 x 2100 cold access SLOAD) to use this method, defeating the point of precomputing the values in the first place.

To get around this problem they employed a trick discussed in the SSTORE2 library form 0xsequence. Instead of writing the values to storage, they deploy an account where the bytecode is a concatenated version of all the values.

To understand where exactly this bytecode is written, it’s worth looking at the structure of an Ethereum account.

From this diagram you can see that the storage (all variables defined in the contract) and the code (EVM opcodes which execute when called) are stored in different places. The storage of an account can be updated, but the code is immutable… the perfect place to write your name!

The next step is working out how to set the code field of an account. The best way to generate the bytecode needed to deploy an account, is to use some high level language like Solidity and write something like:

When a contract is compiled, the bytecode you see will be a combination of 2 things: The pink ‘initialization code’ and the blue ‘runtime code’. Initialization code (initcode), is executed in the context of the new account and it will setup any state variables, and also return the runtime bytecode. This runtime bytecode, the part we’re interested in, will be written in the code field for the account permanently. (check out here or here for a more in depth walkthrough of this)

The problem with the contract we’ve written is that is that the bytecode it would write onchain does not include our name. The account would include some storage locations which hold our name, but that’s not good enough. To write your exact name, and no other surrounding faff, you need to manipulate the initcode to return your name, and nothing else.

This is where the SSTORE2 library comes in handy, as it has a function which sets the initcode needed to deploy some specific bytecode. By making the initcode a set of instructions which return exactly what we need.

The above code takes our name in bytes and checks the length of it so that we know how many important bytes we need to copy later on. It then adds an offset of 11 (avoiding the 11 bytes of the instructions we’ve written) and copies the nameInBytes variable to memory at position 0. Finally we return the copied bytes, meaning that when this code is ran in the contenxt of a new account, the code field will be exactly the name!

We can now test this out by deploying an account with the initcode as seen above. By using a deployer like this you can see that the contract is deployed onchain, and the code field is exactly my name (in bytes)!

Long before pixelated heads and smiling monkey JPEGs fetched millions at auction, humans used art to express their stories and myths in visual form. From cave paintings to sculptures, these representations evolved as technology improved, and eventually scaled to produce the monolithic sphinx statues in Giza. But they didn’t get much bigger than that. There must have been something about a 73m long, 25m tall, sphinx that made people stop for a second to consider what they were doing with themselves. And thankfully so, because over the next millennia art turned it’s focus away from gods, and back to life on earth.

The shift in focus was pushed by two very different different societies. First Greece emerged and experienced a cultural revolution which called into question basic facts about reality and what it meant to be human, building sculptures in an attempt to perfectly represent the human form. Then it was the Islamic Golden Age which took the lead in developing human thought, and with the cultural shift, art too changed dramatically. Islamic art almost completely avoided the human form, instead it focused on calligraphy and geometric patterns – something which would very soon be utilised in a period of radical change which would accelerate human progress like never before, and open art to the masses for the first time.

The dramatic transformation, was powered by a new rising class of society. They respected the church but did not prioritise religion, they openly desired increased political power but did not threaten the ruling class, their movements and worldview moved, quite literally, wherever the wind would take them. The merchant class, centered mostly in Florence were beginning to compete with the church and royals to commission works of art, and the newfound desire to integrate science into all aspects of society caused an explosive transformation of city life in Italy.

While many incredible contributions aligned over the course of the Renaissance, the output of one Florentine architect stood above the rest. It was Filippo Brunelleschi who, around the year 1410, applied mathematical principles first developed by Euclid, then refined by Islamic polymath Ibn al Haytham, to a sketch which unlocked potentially the most significant concept in the history of art – linear perspective. His sketch of the Florentine baptistery used converging lines to predict how the building would project backwards into space. It’s easy to take such a widely used technique today for granted, but it was a revolution that made post-1410 art look otherworldly compared to anything that came before. Pre-Renaissance art could depict objects using oblique perspective, but never extended this to give true depth to paintings . Brunelleschi correctly converged the lines to a single vanishing point.

Armed with perspective as a new technique, the next century was depicted with incredible realism by Renaissance artists, and funded by the rising merchant classes. Some commissioned pieces with a focus on society, and others, in a move to gain influence over city affairs, paid for paintings depicting religious scenes, producing iconic works like The Last Supper or the Creation of Adam. With the general acceptance of science and upheaval of the feudal system underway, the ever more dynamic class of wealthy patrons accelerated art movements over the next four centuries. They left behind an exaggerated, elegant, style of Mannerism, and the epic heavenly scenes of Baroque art which acted as a tool for competing religions in Europe to inspire new followings.

From competing religions to competing social classes, new forms of art were being leveraged to produce grander and more exciting images. But while artists worked to push the boundaries of painting and sculpture, a new form of competition was emerging. It was the biggest revelation since linear perspective but instead of enabling artists, it posed an existential threat to their work – and it would change how we see the world forever.

At a demonstration in Paris in 1839, Louis Daguerre demonstrated the first production-ready attempt to capture photographs. Suddenly the primary income source of many artists — portraits for rich families — could be replaced at a fraction of the cost, and their overall ability to produce any painting as detailed as a photograph was being questioned. The demonstration marked an instant change in attitude towards what art had to be, and initiated a major shift away from painting with the goal of accurately depicting nature. Just a few years after Daguerre’s demonstration, in the very country where the first photograph had been captured, the most controversial movement in art history was about to begin.

The only gallery to accommodate them became known as “the house of mental health”, and critics mostly described the work as unfinished, joking that they must be insane to show their paintings to the public. But what Pissarro, Monet and the other artists who became known as the Impressionists had done, was abandon the notion that art had to represent the real world, follow an existing school of thought, or restrict creativity to constructing heavenly scenes.

The hazy sunsets and waving, water-like outlines unlocked a creative freedom which allowed every artist to develop their own view of the same scene. For Pissarro soft tones and blurred edges, for Monet bold colour and thick lines. While the paintings were artistically interesting, owning one meant more than having something to hang on your wall. It meant holding a unique piece of art, with the signature style of the artist ingrained into it, and openly adopting the new style despite criticism from the public. Driven by the new paradigm of the post-photography world, the Impressionists produced art which was a reaction to new technology, and also immune to its’ threat of replacing them.

One step removed from reality, and no longer constrained by conventional schools of thought, art over the next century accelerated at an even greater pace than during the Renaissance. From the purely geometric forms of Cubism, to the incoherent blobs of abstract impressionism, decades could be defined by a style that would be unthinkable just a couple of years before. And as the idols of the day shifted from celebrities in the 1960s to opinionated graffiti artists of the 1980s, art transformed from the coloured portrait prints of Warhol to the lined drawings of Haring scribbled in the New York subway, and shared by media outlets on TV.

It wasn’t long before technology itself became the idol of society. With the adoption of the internet in the 1990s the world migrated to online life, and over the next couple of decades everything from bank accounts to social lives would be handled on the internet. Soon enough the emergence of blockchains produced the purest form of a connected society, removing the need for centralised hosts, and offering secure ownership of assets. Blockchains were to finance, what the Impressionist movement was to art – a detachment from the established system by a group on the fringes of society, a stripped-back version of what a financial system should look like, and an opportunity that could unlock an era of creative freedom for anyone brave enough to adopt it.

In another parallel to the Impressionist movement, the critical response was pretty much in line with what was written in France over a century before – that anyone valuing a currency on a blockchain was insane. When NFTs emerged, they too drew questions. The images were nothing new, so what was valuable or interesting about a JPEG that could be saved and copied a million times? In a sense, early NFTs were not an abstraction of a particular style of art, but of art itself, the value was not in the image, but in the fact that it was a symbol of the new emerging financial system. In time other NFT projects emerged with a range of utilities, some as purely aesthetic images to collect, others with built-in functionality to unlock memberships or reward followers.

But besides utility or aesthetics, Claude Monet paintings and Crypto Punk NFTs derive their extreme valuations from something much harder to replicate. They both mark significant moments in art history where artists adapted to a new technology, and produced works that would define that period for years to come. To own an Impressionist painting in 1880 was to voice support for a new movement of art, to own one now is to hold a slice of history that has earned itself a price tag in the tens of millions. Buying into the first NFT collections was to adopt a new era of finance and put trust in a decentralised network unlike anything seen before.

As the fallout from the last NFT hype cycle settles, it seems another pivotal movement in art is just beginning. The rise of AI-generated content is causing reactions on par with the early development of photography back in 1839. It’s easy to look back in hindsight and feel that the Impressionists’ success was inevitable, or that NFTs were certain to make it into museums eventually. But in reality, things are less clear in the moment. AI could end human-produced art forever, it could enable a period of creativity like never before, or it could still fizzle out and be forgotten. We can speculate over which way AI art will develop, how the Impressionists will be viewed in 100 years, and whether NFTs can cement their place in everyday life, but in the end, knowing for sure is impossible. And as we have found in the past, we might even be lacking the right perspective to know what we're missing.

If you made it this far, you may be interested in the following:

james_mccomish

Why Did Geometrical Optics not Lead to Perspective in Medieval Islam?

Brunelleschi ‘Rediscovers’ Linear Perspective

Daguerre (1787–1851) and the Invention of Photography

Early Criticism of Impressionism

The early internet is about the only technology that can approximately size the impact that blockchain based technologies promise to deliver. As the internet revolutionised how information was stored and shared, many ‘pre-internet’ styles of work looked unlikely to survive. In the same way, blockchain based networks promise to upend decades of consolidation of power by the tech giants we know (and love?) today. Although comparable in the ambition of their goals (and perhaps hype created in the media) one notable difference between the old and new networks is the initial use case which they emerged from. The early internet promised unrestrained movement of information, while the blockchain revolution pitched itself on the promise of unrestrained financial freedom.

As early as 1982 there were movements towards a secure digital currency in the form of David Chaum’s paper, Blind Signatures for Untraceable Payments . Chaum developed the idea into one of the earliest attempts at what would be comparable to the cryptocurrencies of today, DigiCash. By letting both sender and receiver digitally sign and encrypt transactions DigiCash made it possible to anonymise transfers of cash, but it failed to achieve full decentralisation as the role of the bank still existed to handle the collection of funds.

While DigiCash failed to catch on at the time, it laid the foundations for a world where people could make secure digital payments between themselves. In the years that followed Chaum’s paper a number of factors combined which let people dream not only of securely sending money to each other, but to reshape the very network over which the money would be shared. They included:

• Public availability of strong cryptography from the early 1990s

• Ability to attain cheap computers powerful enough to compute many hash functions in a reasonable timeframe

• Abundant access to the internet with increasing speed

Suddenly it became feasible that if enough participants were to coordinate, a structure similar to the internet, but without any reliance on a few dominant providers, or the need for central storage, could be created. If a financial tool which was secure like DigiCash could be hosted in a distributed manner on such a network, then the role of central banks could be removed entirely, but unfortunately so would any value of the transactions. If a decentralised cryptocurrency was to emerge, it would not only need to be self-sustaining technically, but also be valuable in the eyes of the public.

Although the task of generating real-world value for a completely new digital asset would be a complicated one, just putting the word ‘gold’ in its name was certainly not a bad place to start. Bit Gold, described by Nick Szabo in 1998, built on top of the encryption and secure transfer methods demonstrated by DigiCash but also solved the problem of generating itself value. Bit Gold was not initially intended to be a payment method or direct currency, but rather a reserve currency which could be used to regulate the distribution of other digital currencies.

Bit Gold’s value derived itself from the cryptographic proof known as ‘proof-of-work’ (POW) developed some years before by Moni Naor and Cynthia Dwork. POW, which was already used by spam protection software such as HashCash, meant that creation, or ‘mining’, of new Bit Gold would take roughly predictable amounts of computational power and therefore energy. This investment of energy to create new strings of Bit Gold meant that those who performed the calculations held difficult to attain items. These could then be perceived as valuable to people who wanted to trade scarce items similar to real world gold.

Given the fact that DigiCash existed over 15 years before Bit Gold, and the fact that Szabo was an active, well connected, member in the world of cryptography, it is interesting that Bit Gold never progressed beyond a few half-finished papers. Having come so close to creation it was not tested at scale in the real world and was almost unmentioned until it resurfaced in 2008. It’s hard to say why Szabo put the idea aside, but during the early 2000s he obtained a law degree from University of Washington with the intention of digitising contract law, something we’ll revisit later. Another possible distraction which may have delayed the first widely accepted digital currency was Szabo’s blog ‘Unenumerated’, which regularly published a bewildering set of articles covering everything from “Why are Green Beards Ubiquitous”, to “The Agricultural Consequences of the Black Plague”. A decade well spent, I’d say.

Just as Szabo resurfaced Bit Gold in 2008, the first sighting of what is todays largest cryptocurrency, Bitcoin, appeared. Bitcoin made a number of improvements which allowed it to be less susceptible to variations in computing power (an issue which would cause unpredictable inflation in Bit Gold), and also more secure in protecting itself from malicious actors trying to take control of the blockchain. Maybe the most notable improvement of Bitcoin was that it made it off the drawing board and into the public domain. Not only did Bitcoin give the world a decentralised financial asset which could be owned and traded anonymously, it also, fitting well with its original intention, gave the world an anonymous creator to speculate over.

The now infamous Satoshi Nakamoto takes credit for creating Bitcoin, and in a nod to their predecessors sent the first Bitcoin transactions to Hal Finny (a pioneer of cryptography and contributor to the improvements which Bitcoin made on Bit Gold), Nic Szabo, and Wei Dai (another prominent cryptographer who lends one of his names to a denomination of Ethereum, and the other to one of the world’s largest stable coins). With the first widely accepted digital cryptocurrency in use, it did not take long for the asset to begin to translate into conventional fiat value. And as with any new tech, there were a number of novel moments which made their way into folklore. One transaction remembered as “Bitcoin Pizza Day” is celebrated on 22nd May to commemorate the day a Bitcoin miner from Florida bought 2 pizzas for 10000 bitcoin, worth over $300 million today. But among the technical excitement and public scepticism there were people already beginning to ask, “well what next?”

With the lofty goal of connecting people across the world with an anonymously traded digital currency, un-corruptible by central parties nearing realization, attention moved beyond finance. Interest shifted from transparent connection of currency on a global scale, to transparent coordination of people on a project scale. The emergence of Ethereum, pioneered by Vitalik Butlerin in 2013, was the first step towards accommodating a layer of logic which would transform blockchains from a store of value into a decentralised machine capable of executing financial and non-financial actions.

The logic for applications was built into ‘smart contracts’ which could be deployed and publicly visible to all, but never edited in any way. This opened possibilities for people to code agreements which could be automatically executed if certain conditions were met, or if certain inputs were sent via a ‘transaction’. The flexibility of these contracts meant that people could code almost any set of transactions, including the creation of their own ‘currency’ or ‘token’ which could then be traded with others. Although Bitcoin did have basic smart contracts built in, it lacked the flexibility to create such elaborate code, instead focused on maintaining high security and compatibility with its existing transactions.

The openness of Ethereum to let creators loose to build ever more complicated interactions was not without its problems. As the desire to coordinate people rather than blocks of financial data grew, so did the potential that holes in the logic of smart contracts could be exploited. One of the earliest large profile projects on the blockchain was The DAO a “Decentralised Autonomous Organisation” with the goal of crowd funding for the Ethereum Foundation. The visibility of the source code meant a bug could be easily seen and exploited, and the inability to alter the code left The DAO suffering over $50 million in losses which caused long lasting consequence on the Ethereum blockchain.

Despite some early setbacks, Ethereum led the way for future DAO projects which were increasingly used to shift real world decision making on chain. From crowd funding projects, to organising protocols by transparent voting mechanisms, the role of smart contracts has revolutionised how organisations form, reach decisions, and interface with the public in the same ways the early internet changed how information was presented and shared across the world.

Whether the decentralised and secure nature of blockchains today can hold up against impending regulation and the challenges of scaling to accommodate the next wave of adopters remains to be seen. It will depend on the builders across every blockchain, protocol, or application. But if those builders are anything like Chaum who wrote a seminal paper on digital currency on a typewriter, Vitalik who recovered the Ethereum foundation from a $50 million hack, or Szabo who managed to master cryptography, contract law and the complex world of green beards, they might just be good enough to make it happen.