Gold is a fundraising tool with continuous auctions.

A technical overview of developing gold.xyz

This is about `gold.xyz`, our latest product on [Solana](https://solana.com/), and the things we learned along its development. I'll specifically delve into our biggest pain point, namely porting Rust code to JavaScript/TypeScript (JS/TS) for the front-end and how we solved it eventually via Wasm. This article is a bit technical, subjective and opinionated, written by me: a Rust dev with minimal JS experience who wants to write as much Rust and as little JS as possible.

### Fundraising with NFTs

We came up with the idea of `gold.xyz` 2 weeks before the 2021 autumn Solana Hackathon. Our Rust team was super confident that we can deliver the MVP—enabling anyone to start a fundraiser where users can bid to NFTs in consecutive auction cycles—in this short amount of time. Oh boy, how wrong we were... Anyway, we decided to give it a go and jumped into action.

We were off to a good start and the Rust contract was 90% finished in about 10 days. We were using the [Metaplex](https://www.metaplex.com/) standard for the NFTs. The goal was to have a `MasterEdition` NFT minted for each fundraiser and a `ChildEdition` NFT minted to the highest bidder at every auction cycle within a fundraiser. By `ChildEdition` I mean a unique edition (snapshot) of a `MasterEdtition` NFT, similar to the ERC721 standard on Ethereum.

Since you can set the maximum number of edition NFTs to be minted for a `MasterEdition`, the owner of the auction could set how many auction cycles they'd like to have during the fundraiser. Thus, upon initialization, a `MasterEdition` is minted with a total supply equal to the number of auction cycles. Furthermore, if you know [how PDAs work](https://docs.solana.com/developing/programming-model/calling-between-programs#program-derived-addresses) you can imagine how easy it is to find an edition NFT if you know the public key of the`MasterEdition` NFT's account. So we thought it would add a nice structure to our system if we don't auction separate `MasterEdition` NFTs within a fundraiser, but have a single `MasterEdition` that encompasses the NFT family of its editions. This would also facilitate token-gated access management once the NFTs are auctioned off.

It all seemed fine, but then we realized that the metadata of a `ChildEdition` cannot be modified because it is a static snapshot of the `MasterEdition` metadata. Even if the metadata of the `MasterEdition` was set to be mutable, the `ChildEdition` metadata could not be modified. It was a shame, because we wanted our children NFTs to store unique metadatas with unique images. Since we didn't want to rewrite the code to only mint `MasterEditions` in every cycle, we came up with the following workaround: we set the `MasterEdition` metadata to be mutable and update its metadata after every new edition mint. That way, each edition will take a snapshot of a unique metadata containing unique NFT images and attributes.

With that sorted out, we thought the remaining 4 days of the Hackathon will be enough to mock up a webapp through which users can interact with the contract. Thereupon came the setback that eventually led to us to miss the Hackathon deadline. We had all kinds of data structures in Rust that somehow had to be ported to JS. For example, all fundraisers had a unique ID that mapped to the public key of the fundraiser's state account where all kinds of info about the fundraiser is stored. For this mapping we used a `BTreeMap<AuctionId, Pubkey>` (as `HashMap` is not supported by the Solana runtime due to its random state) and stored it in a central pool account. Thus, whenever the webapp wanted to query the blockchain for the state of a fundraiser, we queried the central fundraiser pool account for the `BTreeMap` and then queried the specific fundraiser state by taking the `Pubkey` value from the `BTreeMap` via the unique fundraiser ID key. Since then we have reworked this part to not use a `BTreeMap`, but we have other contracts still make use of this type. So how do w

Gold.xyz - a new chapter in fundraising

### Bootstrap funding for your community's treasury with custom NFT auctions on Solana.

Gold.xyz makes your community self-sufficient by launching you towards becoming a DAO: 
 that is, **giving you a treasury to govern**.

It utilizes the cheap speed of Solana with public smart contracts and mixes it with the power of the ownership economy to kickstart your community's finances.

Like [nouns.wtf](https://nouns.wtf/) or [wizardsDAO](https://wizardsdao.com/) but anyone can do it without crafting smart contracts. Nouns.wtf is an endless auction for one generative NFT a day where the demand and scarcity drove the prices to 40+ ETH per NFT. The profits then go into the collective Nouns DAO treasury which is governed by the NFT holders. 
 Simple and brilliant. 
 With gold.xyz, **you can do this yourself**.

Since you can add custom properties to each sold NFT, you can even recruit a team for a crypto game with all NFTs assigning unique attributes to players. You can bootstrap a community where everyone shares a common identity through your NFTs and collectively have ownership of the group.

It doesn't matter if you are 2 or 2000 in the community already, it is time for auctioning off NFTs for exclusive membership and governance rights. If you are an artist looking for ways to monetize your content or an aspiring DAO that is looking for a gradual and sustainable way to grow your group and treasury, look no further!

Stay in the loop: [gold.xyz](https://gold.xyz)