Oracle issues - Existing OSM structure allows for price manipulation attacks for certain collections due to NFT collections’ sizes and volatility. NFT pricing oracles have not been sufficiently proven yet (JPEG’d oracles seem to be the best at present).

Liquidation counterparty issues - NFT transactions cannot be settled atomically in a proven and tested way (SudoSwap is still new but looks promising)

ERC721 incompatibility issues - Metadata not being frozen and contracts being either ownable, infinitely mintable or easily rugged are common issues for PFP NFTs. Infrastructure is not in place for use of oracles with financial instrument NFTs yet. Maturity of the sector will lead to eventual solutions within this space.

Brief

Non-Fungible Token collateral as part of multi-collateral DAI is a popular idea and has been explored by MonetSupply in a post from earlier this year. Building on this idea, this post explores a hypothetical implementation of ERC721 NFT collateral within MCD, outlining challenges and potential solutions which are likely to arise.

Motivation

As a recap of MonetSupply's post, motivations for MakerDAO implementing some form of NFT collateral largely revolved around strong demand, low competition and a large addressable market size. In the time since the original post, competitors have emerged, the market has decreased in size significantly and (importantly) distinctions between types of demand have been made apparent (more on this later).

As the implementation of ERC721 as a token specification becomes increasingly popular outside of the realm of "JPEG tokens", it is instrumental that MakerDAO develops the ability to interact with these new collateral types in order to remain relevant and maintain an expanding addressable market outside of ERC20 tokens and RWA vaults.

Types of ERC721 tokens

The two main types of ERC721 tokens as I have defined them are financial instrument tokens and digital collectible tokens. An example of a financial instrument token is a Uniswap v3 LP NFT while an example of a digital collectible token is a CryptoPunk or an XCOPY artwork. These two types of tokens carry different risk profiles and represent different implementation structures with different challenges.

Previous work - NFT lending frameworks

MonetSupply explains that there are four main types of loans with NFT collateral exposure which Maker can serve, namely:

• Fractional token loans - this does not involve ERC721 token interaction

• Floor asset loans - lend against the token based on floor price

• Repurchase agreements - acquire the tokens for DAI with a repurchase option

• Loans to other NFT lending projects - this is just "lending to CeFi"

There are two viable strategies explored here:

Floor asset loans, where ERC721 tokens are locked into a vault and DAI is drawn according to the floor price of the token's collection, and;

Repurchase agreements, where Maker takes on the ERC721 tokens as collateral based on a significantly lower valuation than market price at time of loan issuance.

Both of these frameworks involve direct interaction with the ERC721 tokens and will be explored in this analysis.

ERC721 Token exposure

ERC721 token standard risk profile

As a token standard, ERC721 tokens (sans metadata and other attributes) are significantly different to ERC20 tokens and therefore pose a threat to DSS contract security. In short:

ERC721 tokens use onERC721Received to allow for safe transfers, which could allow for reentrancy-style attacks on DSS contracts

Currently, DSS contracts exclusively use ERC20 tokens as collateral, meaning that any potential interactions which could be caused by implementation of ERC721 collateral must be explored. Even under the assumption that previous audits and security analysis provides sufficient evidence that the existing system is safe, this will mean a lot of developers' time spent combing through code to double-check.

This is a low severity risk

ERC721 collectibles risk profile

Most digital collectible NFT collections ("PFP" sets) operate using an ownable minting contract and an API for metadata hosting. These two factors carry risks;

1. The contract owner can mint additional NFTs beyond the supply cap through a reserveTokens function or similar. This would devalue all tokens in a collection and cause Maker's assessment of token value to be vastly inaccurate, leading to undercollateralised loans.

2. Upgradable ERC721 contracts have the same vulnerabilities as outlined in (1) if the dev is malicious. This is probably going to be very rare, since a majority of ERC721 tokens are basically templates.

3. The contract owner of an established collection can change the baseURI value and rug token holders (which is very unlikely) or (far more likely) change the metadata values for certain tokens in a collection (if they are deemed to be stolen, for example) - causing them to drop to floor value - or censor a token outright (not serve metadata at all) causing near complete devaluation of the token.

   While this is relatively rarely seen (usually this method is used to 'reroll' tokens if a mint has been gamed), the potential for collections to do this is present in almost all tokens.

Collections like Bored Ape Yacht Club, which previously faced controversy relating to contract ownership have renounced ownership and now host their metadata directly on IPFS rather than serving it via an API. These collections represent a minority of ERC721 digital collectibles but present the least risk.

While this risk seems low at a first glance, given Maker's permissionless nature, it stands to reason that depositing stolen ERC721 tokens (either directly stolen or "blacklisted" assets) exacerbate this risk significantly and are an eventuality. Implementations of the floor asset loans such as BendDAO have already had "questionably obtained" NFTs used as collateral (which may be valued as less than floor price due to large marketplace exclusion).

Contracts being owned

This is a medium severity risk

Stolen ERC721 token risk profile

Given the absurd number of stolen Bored Apes amongst other tokens, the non-technical risk element of offering permissionless collateralisation of stolen assets (and therefore attracting attention from law enforcement) poses risks for Maker as an entity rather than for the collateralisation of DAI itself. Using an NFT AMM such as SudoSwap for liquidations lessens this risk significantly.

This is a high severity risk

Floor asset loan challenges

Pricing of NFTs based on floor prices leads to a plethora of issues, based on a few fundamental truths:

1. Floor prices do not represent open offers for "any element of this collection" but rather represent a value above what the market prices the collection's currently purchasable tokens at (i.e. slightly above "market rate")

By virtue of this, floor prices can actually be manipulated at scale - for example, in small collections, "common" tokens could remain unlisted if there was collusion by the token holders, leading to the floor price actually representing the value of tokens of "uncommon" rarity or higher. While in reality this collusion is nearly possible to execute when there are typically over 5000 common tokens in a PFP-style collection, if the collection was smaller (for example 1000 tokens) then this is possible and would allow for collateral depositors to borrow against their tokens at an inflated valuation.

In terms of selling assets instantly for floor price, SudoSwap NFT AMM pools offer a relatively new solution for disposal of assets.

1. Floor prices can be manipulated easily in some cases.

An example of this being easily possible is XCOPY's Mortal series which is comprised of 10 tokens. At date of writing, one token is for sale for 350 ETH, with two others having last sale prices of 12 and 32 ETH. Here, one of the owners of another Mortal piece could purchase the token for 350 ETH and instantly relist it at 3,500 ETH. Assuming that Maker vaults allowed collateralisation of any of XCOPY's selected works (which all use the same contract) with floor prices taken from the Mortal sub-collection, this would allow for potentially infinite borrowing against a single token up to the debt ceiling. This is a high likelihood for tokens such as XCOPY artworks (which are considered to be blue chip by NFT collectors).

1. Floor prices vary depending on market

The floor prices on OpenSea and LooksRare are different since OpenSea delists / censors stolen or controversial assets. At the time of writing, the difference in floor prices for BAYC on LooksRare and OpenSea is 3.83%. Existing NFT collateral lending platforms such as BendDAO use floor prices from OpenSea and LooksRare with a TWAP mechanism.

While this appears to be a reasonably safe mechanism for their purposes, it is nowhere near what the MCD system currently implements in regards to ERC20 collateral. High volatility periods or downtime of OpenSea and/or LooksRare (or their hosting dependencies) could mean rapid liquidiation of NFT collateral backed loans without an OSM-like module. However an OSM module would face issues with regards to attacks presented in (1) and (2) and allow coordinated attacks if it is not designed with such attacks in mind (ERC20 OSM does not consider this a risk since it is a manifestation of non-fungibility and low supply or collusion).

1. Oracle infrastructure is not yet available for these usecases

Existing infrastructure used by BendDAO (which they call an "Oracle Mechanism") is far from sufficient to replace the OSM and timelocks expose Maker to attacks (1) and (2) as outlined above.

MonetSupply's proposed solution to the issue of pricing was as follows:

*"A team or set of teams within MakerDAO will carry out periodic appraisals of supported NFT collateral assets."

While this can work, it would require a lot of additional work compared to the existing ERC20 OSM setup that exists. Additionally, a 'lagging price' implemented through a timelock (as the OSM operates) allows for potential abuse (that, on paper, appears just as severe as for the existing ERC20 OSM) which due to NFT volatility may become more severe or frequent.

Current Oracle solutions by JPEG'd offer the most appealing solution presented to date, however their documentation does not offer much by way of a technical description of how it operates. Incorporating recent purchases in valuations would prevent attacks of type (2), however a more complex solution would be needed to mitigate attacks as described in (1).

The hypothetical ideal oracle would also uses a "rarity score" based model to prevent attacks as described in (1) above to prevent large scale collusion amongst token holders to only have purchasable tokens comprising floor be of intrinsically higher rarity or value than their own assets. This particularly applies to PFP-style collections where the collection size is small enough to allow such collusion. Ideally, team ownership stakes could be used to mitigate such attacks, however if there was enough buy pressure, even this could be overcome.

While this attack appears to be incredibly difficult to execute and not very economically viable, it represents a risk if PFP-style token adoption were to scale.

1. Stolen NFTs

Stolen NFTs can be used as collateral - this has been explored from the perspective of an existential risk to MakerDAO above. However, these tokens are also generally traded for prices under floor price. This means that lower collateralisation ratios would need to be used to ensure that liquidation auction purchasers are still incentivised to purchase the token (this is not a problem if the NFT is sold to a SudoSwap pool as it is also permissionless). Additionally, the collateral could be discounted to ensure a safety margin, however this would make Maker's offering less competitive (market lending rate is 30-40% of floor price).

1. DAI peg changes

Competitors issue USD-pegged stablecoins such as PUSd or issue ETH loans. Both USD and ETH are common denomination units for NFTs - while the counterparty bears the depeg risk for PUSd and other stablecoins, at date of writing, the average NFT owner is likely to assume that DAI is pegged to 1 USD. This is more of a par/TRFM issue than one specific to ERC721 lending, however it may affect competitiveness of the proposed Maker implementation. NFT holders are considered to be less knowledgable regarding DeFi, hence the use of USD-pegged stables and ETH for loan issuance on existing platforms.

Repurchase agreement challenges

1. Maker acts as a middleman for NFT transactions via collateral locking and loan issuance

The primary risk associated here is that Maker is custodying the assets and since NFT theft is often more publicised than ERC20 token theft, it may draw unnecessary risk to Maker (outweighing the benefits in terms of accrued fees and collateral diversification).

1. Maker may not be efficient in terms of rates

The fees earned by Maker for repurchase would likely not outweigh the volatility risk given that the entire NFT asset class has seen wild fluctuations. MonetSupply suggests that the repurchase agreement method be used for 1 of 1 pieces and very high rarity tokens. In my view, even this is too high a risk for Maker to take on given the sector's volatile history; Maker would be better off investing in NFT investors.

1. DAI peg changes

DAI peg changes may disincentivise repurchases of tokens by the counterparty. This can be solved however is a problem worth mentioning.

Financial instrument token challenges

Financial instrument tokens such as Uni v3 LP NFTs can be priced in one of two ways:

1. Reverse engineer the price calculation by replicating the protocol's NFT minting process, or;

2. Use an oracle of some kind to price the tokens

Option (1) is dangerous given that an exploit in either Maker's pricing contract or the original contract (for example, allowing minting positions 10x the size they should be) would allow for attacks which can mint DAI up to the debt ceiling.

Option (2) has shortfalls in that Oracles may face difficulty pricing so many tokens. Considering that these tokens may be minted and burnt constantly, this is a difficult problem for oracles to solve.

Overall, the technology to safely price these tokens is yet to exist. A hypothetical solution would be an oracle which compares contract input and output estimate values during minting and burning of the financial instrument NFTs. No such solution exists at present and this sector is still maturing.

Overcoming shortcomings

Oracles

Currently, no oracle exists which is safe enough to prevent all attack types with certainty. The JPEG'd oracle appears to offer the best solution available at present and therefore should be explored.

Liquidation counterparties

Previously, there was no atomic way of selling NFT collateral in the event of a liquidation. SudoSwap presents a novel technology which should be explored as an element of auction liquidations.

Fundamental incompatibilities

Assuming for some reason that ERC721 tokens are fundamentally incompatible with MCD as an extension of the existing system (either temporarily until the technology becomes available or permanently), it is still possible to obtain collateral diversity through Fractional ERC20 token representations of NFTs.

Conclusion

The risks presented when considering inclusion of ERC721 collateral as part of MCD are broad and can be severe. Three main technologies present potentially viable options for facilitating ERC721 collateral within MCD and should be explored further:

• JPEG'd price oracles for use in DAI drawdown and initiating liquidations

• SudoSwap NFT AMM pools for use in facilitating NFT liquidations

• Fractional NFTs as ERC20 tokens for gaining ERC721 token exposure without ERC721 token use

However, while it's easy to find information about Foundry, there doesn't seem to be any branding for it at all. In my view, visual branding is super important for growing a product's userbase, even when it is a technical product. Products like Rust grow not only because of technical prowess, but also because of branding and a sense of identity and community.

As an aside, there is evidence that products using emojis increases engagement on Twitter but you already knew that since you're probably a 🦀 rustacean 🦀 if you're reading this. I could also propose that the hammer and pick emoji ( ⚒️) is used to represent Foundry developers - but that is for another time.

Disclaimer: I am not a graphic designer.

Let me show you what I came up with:

Now, let's dive into what the existing branding was and how I came to this result.

What is the existing branding?

This is the existing Foundry logo:

I personally think that it looks like a mashup of images from free creative commons clip art images dot com but that's just my opinion. The product is amazing and this doesn’t do it justice. I mean, they had to design a way to throttle chain queries since it was too fast and getting rate limited.

There is this cool graphic:

I like this since:

1. It is a cool graphic depicting the typical Foundry chad

2. It shows that the Foundry team likes the tongs as an image. I can work with that.

This is the existing Paradigm logo:

I like the simplicity of the logo but also how it represents complexity arising from simplicity (the four triangles with truncated corners) which might be a fancy metaphor for web3 itself. I’m a big fan of this.

Let's make some new branding!

Obviously the team had some ideas in mind when designing the original logo. Let's stick to things like dimensions and layout.

Firstly, let's make a hammer which roughly matches the dimensions of the hammer used in the old logo:

Next, let's make an anvil:

Here I chose to keep the motif of the 'truncated triangle' that Paradigm uses to denote that it is a Paradigm product (and I think it fits the anvil look pretty well!).

Lastly, let's make a set of tongs:

Nice, let’s combine them and see how they look!

Let's make some logos!

Let's put them all together now to create a new logos!

Here are a few I created:

And finally, my proposed logo:

Let's see what this looks like as logotype:

Yeah, I think it looks pretty cool!

Let me know what you guys think! I really think that it embodies the Paradigm look and feel! Paradigm is free to do whatever they want with this :)

Keep up the good work guys!

- Ulquiorra

This is a writeup on a theoretical site I propose for Lens Protocol to eventually introduce as part of their wider initiatives to create a distributed and varied social network. This product would provide a link between Tor (.onion) services and the social graph (the Lens plant). Both of these plants share roots as a component and the word root has been assigned meaning in technical fields over the years. I like the name roots.

Nothing like this exists for Web2 technology at present. There is no 'bridge' between darknet posters and clearnet readers. Perhaps this is for the best, however if we analyse this situtation from the perspective of journalism and censorship, this is a pretty big issue. Pastebin text dumps can only gain so much traction - hooking content into the wider social network machine is needed and there is no solution so far.

What is Roots.onion?

Roots is a theoretical interaction layer between darknet-only and clearnet-only users with the goal of facilitating censorship-resistant journalism and media. Roots consists of a frontend (website) which is hosted on a server (for example, a VPS) which will allow access via a .onion address. Roots would allow for individuals who fear censorship to publish posts in a truly anonymous manner (via Tor) with minimal risk to their privacy. Obviously the final URI would look much longer than roots.onion but it might look something like rootslensbd7szmgncyruucpgfkqahzddi37ktceo3ah7ngmcopnpyyd.onion (a Tor v3 onion address).

The Roots frontend

The roots frontend could look somewhat similar to existing platforms like Mirror, Medium or even Pastebin- all of which have seen adoption as methods of disseminating ideas via long-text-format.

The roots frontend be HTML based, with minimal JS interaction (as Tor is considered more secure with JS disabled) and no JS necessary for interaction with the backend.

As many tools (such as Ethers and Web3JS, which are commonly used to communicate with blockchains) are heavily JS reliant and bloated, the burden of operating JS can be shifted to the backend. This would allow for a simplistic yet functional frontend (ideally with a basic markdown edited like Mirror has implemented) which allows for long-form text-based content creation.

Couldn't Mirror.xyz just do this?

Maybe, but their site is so JS reliant right now that it won't even run properly on hardened Firefox, let alone Tor. Tor with JS is still private but not all privacy-conscious users will enable JS.

The Roots backend

The roots backend would be a basic VPS-hosted server which accepts requests from the frontend as well as a signed message (or perhaps the content itself could be signed?) verifying the authenticity of the author. The backend would check this and then post the information to the Lens Protocol social graph via the publication function. Some sybil-attack resistance mechanisms may have to be implemented here to prevent network spam. A time delay for publication may also be implemented (customised by the user) to prevent time-analysis correlation attacks.

Privacy considerations of Lens

Of course, there are privacy considerations which users would need to consider when creating their lens profile NFT.

• EVM-compatible chains (such as Polygon, which Lens Protocol runs on) are not private by design, and no truly decentralised Monero-Polygon bridge exists. Options like Changelly exist but they have had issues in the past. This poses some user-adoption issues but if the users are already using Tor this shouldn't be too much of an issue.

Bad actors

Illegal or undesirable content can mostly be mitigated by only allowing image embeds and markdown (Mirror's approach). Responsibility for removing infringing content lies with IPFS or Arweave (the hosting service). Ideally this traffic would not go to AWS S3 given it is supposed to be as censorship-proof as possible.

Sybil attack mitigation can be achieved through basic mechanisms such as Captchas (employed by many onion sites) when submitting content.

Why don't you go and make it?

I have no experience working with VPS solutions, .onion hosting and to be honest I'm more of a JS frontend dev and this requires HTML. The reason why I am a big fan of Lens is because this is possible - Twitter has launched their own .onion site but it doesn't prevent identification through the email and mobile number they collect. I don't want to build it right now and go after a grant so consider this idea open sourced.

I do want to work at Lens though. Hit me up :)

WTF is a reentrancy attack?

I agree that the name sounds kind of dumb, I would call it recursive call attacks if I could choose a name for it. Maybe recursive withdrawal attack? How about nested function call attack?

Anyway, the name doesn't matter - let's talk about single function reentrancy and cross function reentrancy. I will not cover cross contract reentrancy yet as I lack the knowledge to cover it in depth yet.

Simple / single function reentrancy attacks

Let's look at simple reentrancy:

//This will pay the zero address.
address payable user = address(0);
uint256 balance = 100;
function withdraw(uint256 amt_){
    require(balance>0);
    user.transfer(amt_); //Send the user 1
    balance-=amt_;
}

Ignore syntax mistakes here, this is just to show you what something like this looks like.

Let's call this function 100 times.

In some cases, user.transfer() can occur multiple times before the balance is decreased (withdrawing twice from the contract). This example might be a bit poor because transfer has a fixed gas limit of 2300 which generally can't be abused by a contract which receives Eth, but user.send() could definitely have this effect. The receiving contract just needs to implement a fallback function which calls withdraw() again to abuse this. This is called a simple reentrancy attack.

Preventing this

We can work towards preventing this in a variety of ways:

1. Decrease the balance before we do the transfer. This is called the checks-effects-interactions design pattern

//This will pay the zero address.
address payable user = address(0);
uint256 balance = 100;
function withdraw(uint256 amt_){
    require(balance>0);
    balance-=amt_;
    user.transfer(amt_); //Send the user 1
}

1. Add a lock (or mutex as the solidity docs refer to it) variable so that the function literally cannot be called concurrently during the same call. Let's implement the noReentrancy modifier that the Solidity docs uses.

//This will prevent simple reentrancy attacks
bool locked;  
modifier noReentrancy() {  
    require(  
        !locked,  
        "Reentrant call."  
    );  
    locked = true;  
    _;  
    locked = false;  
}

//This will pay the zero address.
address payable user = address(0);
uint256 balance = 100;
function withdraw(uint256 amt_) noReentrancy {
    require(balance>0);
    balance-=amt_;
    user.transfer(amt_); //Send the user 1
}

OpenZeppelin has an implementation of this called ReentrancyGuard which I would recommend using over trying to build your own implementation. NoReentrant functions using this should be external.

Aside: WTF does _; do?

Good question. Solidity docs 0.8.13 doesn't really cover this in enough depth for my liking. Let me give you a tldr so you don't have to google it.

Modifier X calls function Y. _; is where function Y runs within the modifier X. Think of it like calling Y(); but in a generic (non-name-specific) fashion.

1. For extreme protection we can implement a solution proposed by @ThomasBertani's which disallow calling the function twice in the same call by comparing values of gasleft() (when the slot is warm, it cannot be called again). This is extreme since it means no implementation of your contract will be able to have anything with that modifier called twice. @transmissions11 does not recommend this for most cases but it seems to be the most comprehensive method to prevent simple reentrancy.

Cross-function reentrancy attacks

NOTE: "Cross reentrancy attack" could refer to this or cross-contract

If stopping reentrancy is that simple, then why are attacks still working?

Let me introduce you to the cross reentrancy attack. When two functions share the same state (a variable usually), this is possible. Let's imagine a withdrawEth() function for one type of user (as is being implemented in my escrow contract) and a withdrawEthWithDecision() function (which is called under a different set of circumstances).

Hypothetically (and in reality) an attacking contract can invoke a change in state by calling one function (which is not reentrancy protected) which does not update the state in time for the other (concurrent) call to drain funds. All it takes is one function which shares state and isn't reentrancy protected properly.

Making sure that functions which affect state have proper protections against reentrancy is necessary to prevent this. Using a bunch of single-function reentrancy protections to make sure that nested / recursive calls to a function which changes state can't be made is usually enough - the crux of these attacks is always the state not updating at the time the effects take place.

Where there are multiple functions, setting up a system for untrusted functions (which call unknown contracts) is good practise (this is by Consensys, however note that Consensys have their own guidelines which suggest only using call() rather than transfer() or send(), however this is not for reentrancy prevention reasons and has more to do with the 2300 gas stipend not being enough for some fallback functions to execute fully after EIP-1884 which is a separate issue altogether).

Cross-contract reentrancy

This is like the cross-function reentrancy attack, but when state is shared across contracts. I am not informed enough yet to comment on ways to prevent this type of attack, so I will refer you to better resources.

More complexity in a system leads to more surface area for attacks. Keeping things simple is often better than a complex setup for the sake of it (which can get attacked in many ways).

Transfer vs Send

Solidity Docs actually recommend using transfer() over send() as a way of making sure that transfers failing does not expose your contract to abuse (or result in loss of funds).

The 2300 gas stipend is a good feature to try and prevent reentrancy attacks but it is not enough alone.

My recommendation is literally not to use call() unless transfer() or send() cannot accomplish the purpose of the action you're trying to perform. call() is super vulnerable since it forwards all remaining gas to the contract is calls but is often needed when the 2300 gas stipend isn't enough to execute fallback functions (or just for calls which needs more gas).

Conclusion

Although some will say that the check-effects-interactions design pattern alone is enough to prevent damage from reentrancy attacks, I am a believer in mutex and lock modifiers in addition to this.

Keep your code simple and easy to mentally follow and things should generally be fine - thinking as if you are an attacker while you develop is also a good way to avoid (human-error caused) design pitfalls which could be exploited later.

Aside: do audits mean nothing?

In my opinion, pretty much - when you dangle $10m in front of math and computer nerds, they're going to outperform a $25k audit given enough effort. If an auditor had code with reentrancy vulnerabilities in there at the time when they audited it and didn't catch it, they screwed up. Everyone has screwed up - Certik, Quantstamp, Peckshield and OpenZeppelin have all had contracts they audited be exploited. Saddle Finance (who just got hit) had three of those companies audits completed.

The security industry doesn't expect pen testing to be secure over time as network and physical attacks evolve over time, though here we are talking about people's money. I am not a believer of audits being any better or worse than having your code reviewed by a developer. I am not a believer of anything certified being hack-proof whatsoever. My heart goes out to Saddle and others who have been hit by these attacks - the fact that they paid for multiple audits by big name firms shows that their intentions are good and I hope that they recover. I am personally a fan of crowdsourced-style audits which I feel give the same pool of attackers a chance to make some money (whereas giving a firm an audit contract limits who can earn money off it) but again nothing is perfect.

We can only try our best, there are no guarantees.

Software Requirements

Let's go through what tools I'm using for this:

• Solidity v0.8.13

  The latest version of Solidity which will work with the tools I have installed.

• Foundry v0.2.0

  Foundry (Forge) is an Ethereum development tool released by Paradigm. It is faster, more flexible and (in my view) superior to Hardhat, which I have used previously. Notable benefits of Foundry are that tests are written in Solidity rather than JavaScript, tests can be done using fuzzing to allow for more comprehensively tested code, it is faster than alternatives and is gaining a foothold within the Solidity dev community. You could probably do the same things I am doing using Hardhat (in fact, it may be better for complete beginners) but I am going to use Foundry. Read more on Paradigm's website

  I will also be using the forge standard library which you can read about here. It contains useful tools for testing and learning how things work - I would consider it essential. GitHub

  GitHub will host my code at this repositoryVersion control is good practise, but I am the only dev involved here, so this is mainly to allow for workflow tracking and to keep everything nice and open source. I have stuff under a LGPL license (I just copied Sablier's license type) for now.

• VSCodium IDE

  I like VSCode. I don't like Microsoft sending telemetry when I use it. VSCodium exists for this reason.I am using the Solidity Syntax extension by contractshark since the most popular syntax highlighter highlights errors when I use it with Foundry.

Later on I will be using ReactJS for the frontend, but for the Solidity aspects, this is all you need!

Setup

I created a repo, put it under the LGPL license and ran forge init to create a starter template.

We can run this sample template by running forge test

Which produces the following output:

Now we have this running, it's important to note that the Solidity for the smart contract is in the src folder whereas tests (Foundry also uses Solidity for tests) are in the test folder. A test file has the .t.sol file ending rather than .sol (which is for contracts).

I renamed the files and imports which used the word Contract within these files and then re-ran the demo test to make sure it all runs.

Adding forge-std was as simple as following the guide and I ended up using emit log_string() as a version of JavaScript's console.log() function. You can also use console2.log(), in fact it is recommended, but I've used emit to log before so I am more used to it.

Using the VM for writing tests is super useful, although that's for another time. At this stage you should be ready to start building out your smart contract and playing around with Solidity.

This resume was written using markdown. I am willing to reveal my identity as part of the hiring process if required.

About

I am a solidity and smart contract developer who has been working with Ethereum since 2020. Initially exposed to the world of DeFi and Ethereum through Web3JS and Ethers, I am passionate about building novel projects which I would like to use myself.

I am looking for an environment where I can contribute meaningfully as part of a team while also working independently to produce high quality code.

Three Notable Projects

• DAO-resolved escrow smart contract (Work in progress) Solidity

Extending the capabilities of a basic escrow smart contract, this project aims to add ERC20, ERC721 and ERC1155 compatibility and allow a DAO to vote on escrow resolution results.

• Selenium DeFi swap tool / NodeJS CLI DeFi swap tool Selenium, Python / Javascript

Using Web3JS and Ethers to work with Ethereum in Javascript, I created a tool which allows users to swap on certain DEXes straight from the CLI. This aspect served as an inspiration for further work which involved Metamask interaction and performing swaps directly using a headless Gecko browser and Selenium webdriver.

• IPFS mass upload tool Javascript

A NodeJS program which upload and pins a directory of 10,000 or more images to IPFS to facilitate NFT project creation.

Experience

• Frontend Software Engineer @ Consulting Firm Current employment

I have been working at a consulting firm for over a year performing the duties of a frontend web developer. As a lead developer across engagements, I improved the primary codebase to allow a low-code modification approach for future prototyping, reducing prototyping costs by as much as 80% (per management's estimates).

• Founder @ Small Business Previous employment

I founded and ran a small business in the finance sector. My role was heavily client facing and I managed all aspects of the business until it ceased operating when I joined my software engineering role.

Contact

Twitter is easiest to reach me on.

• Protonmail nofacedev@protonmail.com

• Twitter @NoFaceDeveloper

• Mirror NoFaceDev.eth

• GitHub NoFaceDev