Too often I get asked, “How do you start contributing to a DAO?“ Most people assume you need to be a dev to contribute to a DAO, but code is just one of the many things which DAOs need. Crucial to DAO operations is figuring out what needs to be done to get our functions as decentralized, as autonomous, and as organized as possible. One such task was to design the AirSwap V4 staking contract.

Introduction

The AirSwap protocols consist of DAO and DEX components. The DAO builds the DEX, which then funds the DAO. Core to the AirSwap DAO protocol is the staking contract. By staking AST, members signal their intent to participate in governance and help steer the protocol to become the standard peer-to-peer trading system. A good staking contract design needs to be intuitive and accessible (gas-wise) to enable smaller stakers to participate in the AirSwap ecosystem as well.

Designing the Contract

Simple staking

Staking in AirSwap is a linear vesting over a period of 20 weeks. This logic is pretty simple, until you consider multiple stakes being vested at the same time. For example, Alice stakes 100 AST at week 0, 200 AST at week 1 and 500 AST at week 7. How many tokens are unlocked at week 10?

To allow the contract to unlock the correct number of tokens would require looping over each stake and calculating how much tokens are vested as a function of

1. Initial staked amount

2. Initial time of stake

3. Current block time

Each loop requires additional gas each time the function is called. This means small stakers cannot slowly accumulate their positions without requiring a huge amount of gas to unstake later.

Dynamic staking

Over the course of spring 2023, I worked with smartcontrart to radically redesigned the staking contract based on a set of heuristics that the user would expect.

1. Max duration = 20 weeks.

2. Deposits should not change available staking balance.

3. Deposits should increase the time left to unstake.

4. Withdrawals should decrease the available staking balance.

5. Withdrawals should NOT change the time left to unstake.

Our final design tracked 3 variables for each staking address (vs 2 variables per staking tx): Staked balance, time of initial stake, time of full vest. Instead of creating a new stake for each tx, additional stakes simply increase the time to full vest (up to 20 weeks) based on the additional amount staked relative to its current balance.

With the changes, we no longer need to loop over every single staking tx made but can simply update 3 variables. Our new dynamic staking contract has now been implemented in AirSwap V4, resulting in significant gas savings to DAO members!

Conclusion

You don’t need to be a dev to help out in DAOs! In AirSwap we had marketers, operations, designers, and devs all working together to promote our mission of fully decentralized peer-to-peer swap protocols.

It’s fun and you get to learn loads! If anyone wants to check out what AirSwap is doing, head over to our discord and just chat with the folks there

The project explores the relationship of structure and color to create otherworldly scenes. The code generates systems of swirling particles, with relationships first being defined by an underlying data structure tying both their physical and color space together before being deconstructed during the render. The final chaotic explosions hint at their original construction, encouraging the viewer to create their own stories about the Dying of the Lights.

Underlying Structures

DOTL uses a simple data structure primitive - a recursive quadtree (there are many tutorials and guides for it). split() is called recursively, with the split axis and length randomly determined.

Parent-child hierarchy

Quadtrees have an interesting hierarchy to the nodes. These hierarchies allow traits to be inherited from parent to child. For example, in DOTL, certain sections of the quadtree are filtered out based on their aspect ratios, which (1) limits the particle sizes and (2) generates a city-like structure with clusters of objects being formed.

Traits can not just be inherited but also evolved as the tree is generated. Color is one such trait in DOTL. Evolution of the color trait is tied to their relationship in the quadtree. Every time the recursive split() is called, a new color is generated by applying a shift from the parent color. The shift itself is controlled by a perlin noise field dependent on the size of the node. Larger splits = larger shifts.

Thus, child nodes which are more closely related along the quadtree end up with more similar colors. This allows for larger sections of color to be formed and clustered in certain regions of the tree.

Final Constructions

The structure <> color relationship is further exposed by applying a set of rotations to the system as the tree is rendered. Particles closer in hierarchy form layers of colored geometric objects, with the end result a seemingly chaotic explosion of colors. The rotations are randomly determined, introducing variance in the final megalithic structure of each piece.

The final piece is held together by a central light source which (in most cases) provides the bulk of the illumination in the scene. The environmental palettes in DOTL typically play instead with levels of illumination and contrast to achieve images which pay homage to the sci-fi classics which inspired this project. In rare cases, a more rigid color palette is applied (e.g. white-on-black) to achieve the intended aesthetics.

Thanks for tuning in

Hope you enjoyed the creation process! Here are some curated renders of the various environmental palettes available in DOTL.

In the meantime, you can also generate your own Dying Lights over at my repl. Have fun exploring!

Manual Unstaking

Navigate to the deprecated staking contract in etherscan (or the V2 contract) -> contract -> read contract

Check the AST balance in the contract

Under balanceOf, input your address and click query (querying the chain does not require gas)

Check to ensure that the amount tallies with the amount of AST you have staked

Note: The amount displayed is multiplied by 10,000 to account for the decimal places

Check the balance available to unstake

Under available, input your address and under index, input 0

This number represents the amount of AST available to be unstaked currently. Make sure that this number tallies with the number of AST in balanceOf if you want to withdraw the full amount.

Note: If you have made multiple stakes into this contract, you can check the balance available for each staking event by changing index.

If the number does not tally, either, you have to wait longer to unstake the full amount (20 weeks), or you had staked in multiple batches. Check your historical interactions with this contract in etherscan to find out when you staked, and how many stakes you had made.

Unstake

Finally, to unstake, head to write contract and scroll to the unstake function.

Input the amount you wish to unstake (it has to be less than the available balance from above). If you had staked multiple times, you can batch unstake by providing the input in an array format [unstake1,unstake2,unstake3...].

Sign the transaction with your web3 wallet and pay the gas fee to unstake.

Note: Remember to multiply the AST you wish to unstake by 10,000 to account for decimals!

This idea just popped into my head, so I’m trying to get it all down before I forget. My web3 dev skills are sorely inadequate for building such a project, so I’m leaving this as an open call to any web3 developer who wants to take it up and attempt to build it before Christmas.

I will gladly be the first participant to join in.

Summary

zkSanta is a smart contract which opens 1 month before Christmas.

Anyone can deposit an NFT into the contract using depositPresent() until 25/12 @ 00:00 UTC.

After 25/12 00:00 UTC, all addresses which have deposited NFTs into the contract can call getPresent() which will transfer a random NFT from the contract into their wallet.

As per the traditional rules of Secret Santa, the random generator should not allow for the wallet to get back the same NFT which was deposited. Furthermore, the contract will need to hide the address from which this present originated (hence the zk bit).

I have no idea if this is even feasible, or if there are security exploits to watch out for.

I just want to play zkSanta.

Bonus points if you can make the contract automated every year. Also, if it could be deployed as a factory contract for communities to organize private zkSanta events.

This article is meant to be a walk through the creation process.

Starting out

ArtBlocks has some pretty useful code on their github docs. The code takes in a randomly generated hash string (e.g. "0x11ac128f8b54949c12d04102cf…") and uses that to seed the random number generator (RNG). The RNG is then used to define various parameters of the generative artwork.

Let’s make some fish

The hardest part is starting. In order to draw a fish using nothing but native shapes, I decided to go with a circle. Lots of circles. Each time it draws a new circle, it moves 1 step to the right and draws a new slightly bigger circle. I had to play around with several formulas for the radius of the circle before I could settle on something vaguely fish shaped.

After that I manually defined several fin and tail looking shapes just to make it look a bit more like a fish. I wanted the fins and tail to be able to wiggle as the fish swims, so it was important to get the rigging set up right. The connection points between the fins / tail and the body of the fish were all manually defined by trial and error.

Animating the fish

There were 2 animations I wanted the fish to be able to do. Swim and turn. Swimming was pretty straight forward, since it just meant redrawing the fish at position x+1 each frame. Turning would be a bit more tricky since the body of the fish would have to bend.

This was achieved by drawing each circle slightly bent away from the middle segment of the fish to generate the illusion of turning. Next, I added two parameters which defined the positional (x,y) coordinates of the fish and the angle of facing. With these in place, it is now possible to define the position and heading of each fish.

The animations were done in a simple draw loop to start, but there was still something lacking. I needed a way to govern why the fish would move the way they did. My first attempts used a random dice roll to determine when the fish would turn, and by how much - but it didn’t feel quite right.

for fish in fishes
  fish.display
  fish.move
  if random() > 0.5
    fish.turn(random())
end

Going back to the drawing board, the solution I came up with is to introduce points of interest which the fish would swim towards. Limiting their rate of turning would allow them to keep swimming towards their goal. In my mind, these points might relate to a feeding event, or perhaps just a raindrop hitting the surface of the pond would be enough to pique the interest of the fish.

I animated this as a ripple on the surface of the water. In addition, it allowed me to include a limited form of interactivity - where once every so often you would be able to “feed“ the fish by clicking on a location and the fish would (slowly) react to it.

point = random(x,y)

for fish in fishes
  fish.display
  fish.move
  fish.turn(angleBetween(fish, point))
end

Making each fish unique

Now that we have gotten the basic fish animation down, it’s time to put the final aesthetics into place. We need a way to make each fish uniquely generated!

I adapted some code for making generative Rorschach patterns from openprocessing in order to (a) contain the pattern within the fish itself, and (b) to break the symmetry as needed.

I also created a color palette which I think best reflected the colors of Koi fish, and placed a drop shadow beneath each one to give it a more 3-dimensional feel. If you notice carefully, there are also alternative fin patterns which I built into the program as well to increase the variance.

Putting it all together

Finally, I wanted to give the piece a bit more atmosphere - so I included some lotus leaves which could float on the top of the pond. The leaves would slowly collide and bounce off each other as they float around the pond. Here’s an easy tutorial to learn how to make something similar!

Similarly, I created several environmental palettes which would be randomly generated depending on the initial seed. There are a total of 4 environmental palettes and 4 Koi palettes which could be combined, together with the practically infinite number of body patterns on each fish.

The end piece is intended to be something you could display on your wall as a zen statement piece. The artwork is also theoretically scalable to any display size and aspect ratio, although currently it works best at 800x800 (otherwise filling the space would require rendering too many objects and slows down the animation!).

Closing thoughts

One thing I was not too satisfied with is the need to hard code in rarity tables. This stops it from being truly generative in my opinion. For example, some palettes are harder to find than others, also the number of fish generated is hard coded according to a rarity table.

I’m hoping to improve how rarities are generated in future projects. But for now, I have hard coded in an additional surprise as an “ultra-rare“ attribute. Once in a while you might spot a rare lotus flower among the leaves!

Et Voila

I hope you enjoyed the run through. While there currently does not exist any NFT for these, I have set up a web server (full codebase is open source under CC BY-SA3.0) as an additional utility for metajam METAPASS holders in order to showcase how NFTs allows anyone to build on each other in a completely open and permissionless manner.

The server generates the fish based on the tokenID of the METAPASS NFT(s) held in the connected wallet (in the same idea of synthetic loot). These are not NFTs, but you can play with them all the same.

https://nishikigoi-web.agrimony.repl.co/

Generally interested in building on the web3 space. So far, I’ve helped to build a new community-based DEX with other contributors on AirSwap. You can also find me helping out the Zapper community.

I’m also currently exploring the world of coding and generative art, and most likely going to be using this as a way to journal some tutorials and learnings from my experiments.

Will also leave some of my tests up as NFTs which people can mint if they are interested!