To recap, here’s what developers can expect from today (June 14) forward:

June 14

✅ API: Begin using the new Seaport offers and listings endpoints on Mainnet

✅ API: Begin parsing new Seaport offers and listings from /assets and /bundles endpoints on Testnets

✅ SDK: Begin using new Seaport-ready functions in SDK v4.0.0 on Mainnet

June 21

✅ API+ SDK: Offers and listings can no longer be posted to Wyvern v2.3 contract using OpenSea

July 13

✅ API + SDK: Offers and listings can no longer be fetched from Wyvern v2.3 contract using OpenSea

For more details on each of these updates, please refer back to our detailed Seaport migration guide.  If you have any questions, please reach out on Discord as we’re here to help.

Seaport as a protocol is decentralized and open source - anyone can use it, with no contract owner, upgradeability, or other special privileges. In that spirit, we’re also sharing the Seaport Dune abstraction table that will allow anyone to easily and quickly query transactions made on Seaport. 

While it’s most directly useful for Dune wizards, we believe this query structure and explanation could also be useful for any on-chain sleuths, and any services utilizing blockchain data. The query structure should help you understand how the on-chain data maps into transaction data -- including variables such as purchase types (e.g. if transaction was a standard offer, collection offer or attribute offer) and number of NFTs transacted.

Calls and successful transactions

Similar to Wyvern, Seaport broadly has two types of tables: calls and completed transactions tables. 

The calls tables, e.g. seaport."Seaport_call_fulfillAdvancedOrder" (where collection and trait offer calls live), include all attempted transactions that are submitted on chain, including failed transactions. These tables are where we get the data we need to categorize transactions into different purchase types (e.g. buy now or collection offer).

The transaction completed tables, most notably seaport."Seaport_evt_OrderFulfilled", is where we find successful transactions through Seaport. This is where we get data on the final purchase amount and fees.

Offers and considerations

Seaport is very different from Wyvern in its usage of offers and considerations. As we shared in our last blog post, offerers can agree to supply a number of ETH / ERC20 / ERC721 / ERC1155 items — this is the “offer.” In order for that offer to be accepted, a number of items must be received by the recipients indicated by the offerer — this is the “consideration.” 

The call and transaction tables include data on both offers and considerations in json arrays. In the abstraction, we turn this data into an easily query-able unique transaction-level table that is formatted similarly to Dune’s current nft.trades table - with some additions (e.g., fees, number of NFTs transacted).

Currently, the query supports offers, auctions, private sales, bundles, bulk purchase and buy now transactions involving transfers of ERC-721 and ERC-1155 NFTs for ERC-20 tokens like Ether. We will continue to update this abstraction and documentation as the community begins to more fully explore Seaport. 

Zones

 We also separate out “zone” as a variable. A zone is an account (usually a contract) that performs additional validation prior to fulfillment, and that can cancel the listing on behalf of the offerer. OpenSea’s current zones are 0xf397619df7bfd4d1657ea9bdd9df7ff888731a11, 0x9b814233894cd227f561b78cc65891aa55c62ad2, and 0x004c00500000ad104d7dbd00e3ae0a5c00560c00.

But Seaport is a flexible, open protocol, and we look forward to seeing many more “zones” pop up and use the contract. You can use this abstraction to query data for different zones as well -- just change the zone you’re selecting for 😎

How do I use it?

The fully-commented query is available here if you want to dig into how it works. You can also simply query the abstraction table from Dune: the table name is seaport.view_transactions. Many thanks to @sohwak, our amazing Dune wizard who wrote this super efficient query! Also special shout out to our frens at Dune, who have been amazing to work with throughout this process.

We will release a larger OpenSea Dune abstraction soon, that will make it even easier to query OpenSea data across Wyvern and Seaport. We’ll also work with Dune on making Seaport part of nft.trades. These are all part of our larger efforts to engage more with our community through data -- including through our recent community analytics bounty program.

This is just the beginning. We look forward to bringing the community more new features -- and more data! -- much faster. LFG! 💪

Neutralizing a critical vulnerability in Wyvern Protocol

—

TL;DR — In Q1 of 2022, a security researcher reported a critical vulnerability in the Wyvern 2.2 smart contracts that powered OpenSea. The vulnerability was neutralized before it could be exploited, and users are no longer at risk. We awarded the vulnerability reporter a bug bounty. Historical blockchain logs provide no indication that the vulnerability was ever exploited in the wild.

—

The “Horton Principle” is a maxim in designing cryptographic systems that says “mean what you sign and sign what you mean.” Earlier this year, a security researcher pseudonymously named Gus reached out to OpenSea to disclose a violation of this rule uncovered in Wyvern 2.2 — the core smart contract that powered OpenSea’s marketplace.

The researcher, in cooperation with the OpenSea security team, Wyvern protocol developers, and @samczsun, discovered that the vulnerability could be leveraged to steal offered WETH from the wallets of a subset of users with active offers on the OpenSea marketplace. The vulnerability required no action on the part of the user to exploit — certain users who had signed legitimate listings or offers in the past were at risk even if they took no further action.

This is the story of how the community – including Wyvern core developers, security researchers, and OpenSea – neutralized the vulnerability before it could impact users.

The Vulnerability

In the architecture of the Wyvern protocol, users author listings or offers off-chain by signing over commitments to the specifics of the listing or offer — most typically, parameters indicating an intent such as "I want to sell Bored Ape #312 for 100 WETH." These off-chain listings or offers can then be accepted by a counterparty using the Wyvern contracts on the Ethereum blockchain. For example, someone might elect to buy your listed NFT, in which case they would submit the signature you provided along with the listing or offer data in a call to the Wyvern contracts, and provide the payment required (which would go to you, less any fees).

Wyvern listings contain many different parameters used to indicate listing or offer information and authenticate other involved smart contract calls, which are aggregated together into a single commitment that the user signs and the contract checks –thus ensuring that items are only transferred if the user actually approves the listing or offer. Several of these parameters are variable-length, and the Wyvern 2.2 contracts (written before later standards in ABI encoding) concatenated them together without proper domain separation:

index = ArrayUtils.unsafeWriteAddress(index, order.target);
index = ArrayUtils.unsafeWriteUint8(index, uint8(order.howToCall));
index = ArrayUtils.unsafeWriteBytes(index, order.calldata);
index = ArrayUtils.unsafeWriteBytes(index, order.replacementPattern);
index = ArrayUtils.unsafeWriteAddress(index, order.staticTarget);
index = ArrayUtils.unsafeWriteBytes(index, order.staticExtradata);
index = ArrayUtils.unsafeWriteAddress(index, order.paymentToken);

Note particularly the three lines appending variable length byte arrays to the temporary array (which is hashed afterwards). In this implementation, orders with different parameters - say calldata = 0x01 and replacementPattern = 0x0101 and calldata = 0x0101 and replacementPattern = 0x01 - would have resulted in the same computed commitment. Due to this sort of collision, a clever adversary could have taken a signature from one listing or offer and come up with a different listing or offer - not signed by the user but resulting in the same commitment - that would have been considered by the smart contract to be valid. More specifically, bytes could be "shifted" by an attacker between order.calldata, order.replacementPattern, and order.staticExtradata, to create an offer or listing with different semantics that would result in the same commitment.

In order to understand the particular way by which this can be exploited, it's important to understand how Wyvern works under the hood.

Calldata and Replacement Pattern

In the Wyvern system, digital items (such as NFTs) can be effectively "swapped" for other digital items via arbitrarily complex smart contract transactions. To allow this, listings or offers specify calldata with which the Wyvern contracts will call a given target contract in exchange for the listing or offer amount. In many cases, it is desirable for the calldata to be mutated at time of fulfillment (in a highly constrained way).

This is accomplished generically through the concept of a replacementPattern — a bitmask that the listing or offer maker commits to that specifies the portions of the calldata the listing or offer maker is willing to have mutated by the taker. When the listing or offer is filled, the taker passes in calldata that is mutated to their liking, and the Wyvern contracts apply the bitmask from the replacementPattern in order to determine the bits in the final calldata that the taker is allowed to submit mutated.

Why exactly is this clever machinery needed? Consider the following example:

In OpenSea offers, the offer specifies that Wyvern must successfully call the transferFrom function on an ERC721 on the Ethereum blockchain in order for payment to be transferred to the offer taker. However, since the address of the taker is not known at the time of offer creation (offers are made specific to NFTs, not their holders), the offer must allow the taker to specify their address as the from in the transferFrom call at time of order fulfillment. Thus, the above mechanism is used to let the offer taker specifically mutate the portions of the transferFrom calldata that specify the transfer's from value.

This capability, in tandem with the Horton principle violation, is the crux of how this exploit could have materialized.

The Exploit

The first 4 bytes of calldata specify which function should be called on a target contract. These bytes are called the function selector and are the first 4 bytes of the SHA3 hash of the function signature. In the above example, the function selector is 0x23b872dd and corresponds to the signature transferFrom(address,address,uint256). This function inputs 3 parameters: address from, address to, uint tokenId.

Violating Horton's principle allows for several potential exploits. The most potent of these was that, in certain clever cases, the attacker could "shift bytes" between the callData and replacementPattern in a manner that modified the resultant function selector that was called.

The function whose selector is "closest" (fewest bits differ) to transferFrom is the function getApproved(uint) with the selector 0x081812fc. Only 10 bits differ between it and the function selector for transferFrom.

There is a 1 in 1024 chance that a random, 4 byte bitmask has ones in the correct places such that, when applied through the replacementPattern mechanism, the function selector would change from 0x23b872dd to 0x081812fc. Conveniently, an ETH address is effectively 20 random bytes.

Recall that, because of the Horton principle violation, an attacker can effectively shift adjacent bytes between the calldata, replacementPattern, staticTarget and staticExtradata values while arriving at the same order hash. Notably, an attacker could convince the Wyvern contracts that the order maker signed the former of these two payloads, when they in fact signed the latter:

// Malicious payload
...
'calldata': '0x23b872dd00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000f6005af36', 
'replacementPattern': '0x6bfa60bbdba5966b9209e81567dedb00000000000000000000000000000000000000000000000000000000000002b300000000ffff', 
'staticTarget': '0xffffffffffffffffffffffffffffffffffffffff', 
'staticExtradata': '0xffffffffffffffffffff0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
...

// True payload
...
'calldata': '0x23b872dd00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000f6005af366bfa60bbdba5966b9209e81567dedb00000000000000000000000000000000000000000000000000000000000002b3', 
'replacementPattern': '0x00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000', 
'staticTarget': '0x0000000000000000000000000000000000000000', 
'staticExtradata': '0x',
...

We can see that, in this example, our hypothetical attacker has shifted the last 15 bytes of the maker's address (which, in the true payload, is part of their specified "fixed" calldata) into the start of the replacementPattern.

The 4 bytes 0x6bfa60bb in the maker's address, coincidentally, have 1 bits in the places corresponding to the bitwise difference between transferFrom and getApproved. In turn, the attacker would be able to fulfill the order with calldata specifying a call to getApproved(0) instead of transferFrom:

...
'calldata' '0x081812fc00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000f6005af36'
...

The function call getApproved(0) does not revert for 0-indexed ERC721 contracts and is also a view function, which does not update the state of the contract. If this exploit had been carried out, this would have allowed an attacker to fulfill an offer without sending or even owning the NFT the buyer wanted, while still being paid the victim's WETH.

Given that the attacker could shift the replacementPattern to start at any point in the address, the attacker could extract 16 different 4 byte starts to the replacementPattern. This means approximately 1 in 64 offers could have been exploitable.

The Remediation

The OpenSea team was immediately compelled to action by the report of the vulnerability — the only way to protect our users was to migrate OpenSea’s listings and offers to a new version of Wyvern and disable Wyvern 2.2. The Wyvern governance contracts, however, mandate an upgrade timelock period of at least 14 days — meaning that, if we were not careful, we would incidentally alert potential attackers to the presence of the vulnerability before it had been neutralized.

Coincidentally, at this same time, OpenSea’s users were facing a persistent but unrelated issue: “hidden” listings. We have written extensively about the hidden listings issue, as well as the steps OpenSea has taken to help prevent similar attacks in the future.

It was clear that our best option was to “kill two birds with one stone” by initiating an upgrade that would solve both issues. We did this by including a new feature in the Wyvern 2.3 upgrade — EIP712 support, which implements a signature protocol that is not vulnerable to the Horton principle violation described above.

Our security & protocol teams raced to implement the Wyvern 2.3 contracts, and were fortunate to have Trail of Bits conduct an audit of the new contracts before their submission to the Wyvern DAO.

On February 18th, in partnership with the Wyvern governance community, we commenced the upgrade to Wyvern 2.3 and announced the migration publicly. Wyvern DAO stakeholders approved the upgrade proposal promptly and the two-week new version upgrade timer began its countdown.

Wyvern 2.3 was successfully migrated to on Feb. 25th and Wyvern 2.2 (the vulnerable smart contract) was disabled through Wyvern governance at the same time.

Our reviews of on-chain logs indicate that the vulnerability was fortunately never exploited in the wild.

For his responsible participation in the OpenSea bug bounty program, security researcher Gus was awarded a $3m bounty. We are thrilled to have seen the bug bounty program accomplish its stated goal in securing our users, and encourage other security professionals to submit any vulnerability reports through our Hacker One page.

Acknowledgements

Wyvern 2.3 is, at time of writing, the most used smart contract on Ethereum. Neutralizing a vulnerability in it was an incredibly delicate and high-stakes operation, and we at OpenSea are enormously grateful to everyone who lent time to this effort.

First and foremost — thank you to Gus for his responsible and productive participation in the OpenSea bug bounty program.

Second — we thank members of the broader community: the Wyvern core developers & community, @samczsun, and Trail of Bits.

Lastly — we want to acknowledge the tireless work of individual contributors on our team who lent countless nights and weekends to this effort.

FAQ

There was a lot of talk on Twitter about OpenSea users getting phished in late February — was that related to this vunerability?

No — at the tail-end of the Wyvern 2.3 migration, approximately 10 OpenSea users were subjected to phishing attacks that occurred off of the OpenSea website. The phishing transactions did not leverage the above vulnerability in any capacity. Thankfully, the EIP712 standard that was launched in Wyvern 2.3 makes it much more difficult for attackers to dupe users into signing malicious payloads.

Was Wyvern 2.2 ever audited by third parties?

Yes — an audit was conducted by Solidified. Audits — though critical as a backstop for security — are not a silver bullet, and sometimes miss critical vulnerabilities, as illustrated by this case. This underscores the importance of bug bounty programs in the smart contract security space.

Where can I learn more about OpenSea's bug bounty program?

Information on OpenSea's bug bounty program can be found on HackerOne. Notably, we've recently updated our HackerOne to reflect the higher tier with which we pay out disclosures for critical vulnerabilities on the smart contracts we leverage.

The new Seaport protocol will open up a range of new paths for OpenSea and the developer ecosystem more broadly:

• A composable, open-source contract on top of which developers can build their own marketplaces

• The ability to create custom rulesets for the fulfillment of a listing or offer, using a concept called “zones”

• Support for multiple fees and custom creator fees

• Potential for new types of transactions: collection offers and batch fulfillment (including floor sweeping), batch listing, and more

Required changes for developers

As we migrate the OpenSea marketplace over to Seaport, there are a few implications to our APIs and SDK that will affect our existing developers.  When we initially launch the new protocol, we will operate Wyvern and Seaport in parallel for a period of one week following the launch - and this means that you’ll need to update your project in order to fetch and interact with orders from both contracts.

We’ve summarized the set of changes that are required in order for projects to be compatible with the new Seaport protocol when it launches on OpenSea in the coming weeks. If your project does not incorporate these updates, it will not be able to fetch or interact with offers or listings on OpenSea that use the Seaport contract as we deploy it to our marketplace.

Here’s an overview of what to expect, with more details about each step in the sections that follow:

Today (May 25)

✅ API: Begin using new Seaport offers and listings endpoints on Testnets

✅ API: Begin parsing new Seaport orders from /assets and /bundles endpoints on Testnets

Tomorrow (May 26)

✅ SDK: Begin using new Seaport-ready functions in SDK v.4.0.0-beta on Testnets (May 26)

Seaport live on OpenSea

✅ API: Begin using new Seaport offers and listings endpoints on Mainnet

✅ API: Begin parsing new Seaport offers and listings from /assets and /bundles endpoints on Testnets

✅ SDK: Begin using new Seaport-ready functions in SDK v.4.0.0 on Mainnet

Seaport live + 7 days

✅ API+ SDK: Offers and listings can no longer be posted to Wyvern v2.3 contract using OpenSea

Seaport live + 30 days

✅ API + SDK: Offers and listings can no longer be fetched from Wyvern v2.3 contract using OpenSea

OpenSea API

When we begin to use the new contract, our API will enable developers to fetch and post offers and listings from both the Wyvern and Seaport contracts. Since offers and listings from the new contract will differ from those on the Wyvern contract, developers will need to update their OpenSea API integrations to account for these differences. Current API implementations will continue to function against the Wyvern contract, however changes are required to fetch and post offers and listings from the new contract.

In order to be compatible with the Seaport contract, developers will need to make the following changes to their projects:

• Developers using the existing /wyvern endpoints will need to migrate to the new endpoint that supports offers and listings on the Seaport contract.

• Developers using the existing /assets and /bundles endpoints will need to begin parsing orders from the Seaport contract that are returned from these endpoints.

Migrating from /wyvern endpoints to new Seaport orders endpoints

With the launch of the Seaport contract, we will be deprecating the /wyvern endpoints - at this point, POST requests will no longer be supported and GET requests will only continue to function for 30 days post-launch.

The new Seaport offers and listings endpoints enable developers to create and fetch both listings and offers on the new contract.  Developers will need to begin using these new endpoints to interact with the Seaport contract via the OpenSea API.

Starting today, we have enabled support for these new endpoints on our Testnets API (Rinkeby) so that developers can begin to prepare for the migration. More details on these new endpoints can be found in our developer documentation:

• Retrieve listings

• Retrieve offers

• Create a listing

• Create an offer

Parsing Seaport orders from /assets and /bundles endpoints

Since the format of Seaport orders differs from those on the Wyvern contract, we’re adding a new field to the /assets and /bundles endpoints through which Seaport orders will be returned separately from Wyvern offers and listings.

Developers using these endpoints will need to update any parsing logic on the responses from these endpoints in order to specifically handle orders returned from the Seaport contract.  Each item in these responses will now include the seaport_sell_orders field, which will contain an array of listings from the Seaport contract on the NFT.

This new field matches the way in which Wyvern listings are currently returned through the existing sell_orders field:

"asset": {
  ...
  "sell_orders": [],
  "seaport_sell_orders": [],
  ...
}

Once the Seaport contract integration is live on OpenSea, all new offers and listings that are created will be returned in the new seaport_sell_orders array.  As liquidity moves over to the new contract, you will see fewer and fewer listings being returned in the legacy sell_orders array, so we recommend that you cease to rely on this field after our forthcoming launch of Seaport on OpenSea.

OpenSea SDK

Similar to the OpenSea API, our JavaScript SDK has been updated to support the fetching and posting of offers and listings on the new contract. Developers should plan to adopt Version 4.0.0 of our SDK when we begin using Seaport on OpenSea and begin to use our new methods that have been updated to support orders on the new contract.

With this SDK update to support the new Seaport contract, there are notable changes that developers will need to address within their projects:

• All Wyvern-specific models will be deprecated in the new version of the SDK.  Wyvern support will be maintained through a legacy set of functions that developers can continue to use while the contract is still enabled on OpenSea.

• For each of these deprecated functions, we’re providing a new function that is compatible with orders on the new Seaport protocol.

With this upgrade to Version 4.0.0, the function names from Version 3.0.4 are now connected to the Seaport contract and will only begin to function when Seaport launches on OpenSea. In order to preserve support for Wyvern, developers can use the following functions to maintain support for offers and listings on the Wyvern contract:

• isOrderFulfillableLegacyWyvern

• cancelOrderLegacyWyvern

• fulfillOrderLegacyWyvern

• createBuyOrderLegacyWyvern

• createBundleBuyOrderLegacyWyvern

• createSellOrderLegacyWyvern

• createBundleSellOrderLegacyWyvern

• getCurrentPriceLegacyWyvern

• getOrderLegacyWyvern

Starting on May 26, developers can begin testing against Version 4.0.0-beta on Rinkeby in order to prepare for the migration.

Using the new contract

While our API and SDK provide helpful abstraction layers on top of the underlying contracts that we use here at OpenSea, we also realize that a growing part of the developer ecosystem is interested in building directly off of these contracts themselves. With the release of this new contract, we’re excited to expand our developer stack by opening up this contract for the entire ecosystem to build around and participate in its ongoing development.

If you’re interested in getting started, we’ve released a set of reference documentation that you can use to learn more and begin building.

We also currently have a two-week audit contest running with code4rena with a $1 million prize pool, where we’d love participation from the community in reviewing the Seaport contracts. Please join us for the largest pool size in code4rena’s history!

In this first edition, we’re sharing a recap of recent news and updates to the OpenSea Developer platform - including our API, SDK and developer events.

Let’s dive in!

Product Updates

Stream API now in beta

On May 5th, we launched a beta version of the Stream API, a new websocket-based service that enables developers to receive events as they occur across our marketplace.

We’ve built the Stream API to better support a range of use cases that rely on dynamic data, such as price fluctuation, listings, bids, and ownership changes. Instead of polling for updates, you can subscribe to receive events as they occur - whether for specific collections or globally across the entire OpenSea marketplace.

The Stream API makes it easier to build many new features, such as:

• A push notifications service that alerts people when they receive new bids on their listing.

• An activity feed that provides a timeline of sales of NFTs from a specific collection.

• A real-time dashboard that enables people to visualize and track key trends and metrics.

• A display of NFTs that have recently had their metadata updated.

With this beta launch, we’ve provided a JavaScript SDK that provides a simple way to manage connections and individual subscribers to the Stream API and its various events. And as an example of what’s possible, we’ve also built a new tool that leverages the Stream API to automatically post updates to Discord which you can clone on GitHub.

To get started, check out our Stream API developer documentation which will walk through setup and how to use our JavaScript SDK.

Update to orders endpoint

On April 26, 2022, we began to require the side parameter to be included in all requests to the /wyvern/v1/orders endpoint. This parameter is used to filter the response to either buy or sell orders and was previously optional. Moving forward, requests will fail if they don’t include this parameter. Learn more here.

Solana update

Our Solana Beta is now live! Using our Solana marketplace is similar to using Ethereum and Polygon, but there are a few differences. Solana is a separate blockchain from Ethereum, so a Solana-compatible wallet is required to be able to purchase Solana-based items using OpenSea. Check out our guide to learn more about how Solana works on OpenSea.

Developer Events

OpenSea recently teamed up with Replit to host the Hello NFT World Hackathon. Check out the BUIDLs and winners in the Hello NFT World Hackathon Recap.

Developer Resources

Just getting started? Here’s a set of helpful tools and links to help you get up and running:

• NFT API Developer Docs

• Stream API Developer Docs [New!]

• JavaScript SDK - don’t forget to update to the most recent version!

• OpenSea Developer Blog

• Changelog

• OpenSea Developers on Twitter - real-time updates on our API, SDK

• OpenSea Developers on Discord - join our community of builders

Tutorials

Looking to create your first NFT smart contract?

Dive into this step-by-step tutorial which will walk you through everything needed to create an NFT contract that you can trade on OpenSea. This tutorial includes many different components of building, deploying, and selling a non-fungible contract on Ethereum's Testnet that can be bought on OpenSea.

That’s a wrap for our first newsletter! As part of our ongoing efforts to improve developer tools, we welcome any feedback from the community. Please complete this form and include any blockers or wish list items.

Thanks for reading! We look forward to seeing you on the next one!

Hello World meets web3 🖥️

The Hello NFT World Hackathon encouraged the advancement of web3 by bringing together creators, artists, developers, and entrepreneurs as “BUIDLers” to create innovative web3 NFT Projects.

Together, they pushed the boundaries of NFTs and surfaced new types of utility. Over the course of eight days, projects explored various concepts ranging from web3 education, NFT DeFi, and even blockchain dating!

In summary, a total of 73 teams submitted BUIDLs to the four Hello NFT World tracks:

• Gaming and Metaverse

• Most Hilarious

• Onboarding for All

• Most Creative

How winners were chosen

Each BUIDL track had a $5K first place prize, but it didn’t stop there. The top three BUIDLs in each track advanced to the $25K Quadratic Voting round. A total of 12 teams battled it out in the Quadratic Voting round.

What is Quadratic Voting, you ask?

A voting scheme introduced and often discussed in the Radical Markets community. It is often considered an innovative improvement of the traditional 1-person-1-vote or 1-dollar-1-vote voting schemes. The simplified formula on how quadratic voting functions is cost to the voter = (number of votes)².

To learn more about on-chain MACI Quadratic Voting, you can dive into the DoraHacks explainer here.

To view the top 12 BUIDLs and the Quadratic Voting results, head over to DoraHacks and check out the leaderboard. You can also jump to the bottom of this post to watch the Hackathon Kickoff, and the two Demo Days hosted by DoraHacks.

The First Place Track Winners

Gaming and Metaverse

Belly NFT

A collectible, craftable NFT experience!

Belly.io rewards loyal fans with NFTs. As content creators, Belly wanted to BUIDL a way to reward their loyal fans. As developers, they wanted to do something fun and creative, and since so much of their content in the past revolved around food, a collectible, craftable NFT experience seemed like the perfect way to do all of that! Check out the demo, visit the Belly NFT BUIDL.

https://dorahacks.io/buidl/2661

Most Hilarious

Spamazon

Buy anything with anything.

Have you ever wanted to trade your 10 ETH NFT for a $20 book? Well, Spamazon has the place for you! Spamazon gives NFTs a new purpose: payment for a purchase, on or off the blockchain. If your local food or furniture store has a risk appetite, they can accept NFTs as payment or collateral until payments are made using all Spamazon. Buyers can benefit from bartering with their NFTs or posting them as collateral until they daytrade for enough money to repay. A store that adopts this concept can reach a new market that doesn't require an intermediary trade for currency. Ready to LOL? To learn more, visit the Spamazon BUIDL.

Watch the demo here

https://dorahacks.io/buidl/2677

Onboarding for All

NEWFRENZ

Onboard your frenz in web3 with a simple link.

NEWFRENZ is an interactive onboarding into web3 for beginners. The user is invited to navigate through different sections to learn essential information about blockchain, NFT, etc., and complete a series of tasks (connect wallet, switch to testnet, use a faucet, and finally minting an NFT). To learn more and start your web3 onboarding, visit the NEWFRENZ BUIDL.

https://dorahacks.io/buidl/2658

Most Creative

ShaadiOnChain

The one-stop destination for all your blockchain love life needs.

Weddings in India are regarded to be an everlasting love relationship. ShaadiOnChain now allows you to record your love for the rest of your life. Many Indian couples have begun to celebrate and register their weddings on the blockchain, although this can be difficult for those unfamiliar with web3. ShaadiOnChain provides a simple interface for couples to enjoy a fully loaded love journey on the blockchain. To learn more, visit the ShaadiOnChain BUIDL.

https://dorahacks.io/buidl/2624

All Hello NFT World BUIDLers received this exclusive POAP. What’s a POAP? More cool web3 stuff, learn more at https://poap.xyz/

Thank you again to all of our BUIDLers, Judges, and Partners.

Join us in our Discord and help us BUIDL and advance web3.

If you are interested in learning more about web3 and NFTs, check out the following resources:

1. What is Blockchain?

2. How does Ethereum work anyways?

3. ETHhub Reading & Community Resources

4. NFT intro guide

5. How to Start Coding in Web3

6. Hands-on Ethereum Day

📣 Orca size THANK YOU to DoraHacks for their guidance, support, and helping ensure the voting mechanism worked without a glitch over the weekend.

Hello NFT World Videos

How to Create an NFT on Replit (you can follow along with the replit here)

Demo Day One with DoraHacks

Demo Day Two with DoraHacks

Hello NFT World LIVE!! Kickoff

With the massive growth in the NFT ecosystem, we know that it’s becoming increasingly challenging to rely solely on our REST APIs to stay up-to-date across a growing number of items and collections. The need to continuously poll these endpoints to refresh the data in your service can be resource-intensive and inefficient.

We’ve built the Stream API to better support a range of use cases that rely on dynamic data, such as price fluctuation, listings, bids, and ownership changes. Instead of polling for updates, you can subscribe to receive events as they occur - whether for specific collections or globally across the entire OpenSea marketplace.

The Stream API makes it easier to build many new features, such as:

• A push notifications service that alerts people when they receive new bids on their listing

• An activity feed that provides a timeline of sales of NFTs from a specific collection

• A real-time dashboard that enables people to visualize and track key trends and metrics

• A display of NFTs that have recently had their metadata updated. Examples of metadata updates include changes to title, description, and image.

With this beta launch, we’re providing a JavaScript SDK that provides a simple way to manage connections and individual subscribers to the Stream API and its various events. And as an example of what’s possible, we’ve also built a new tool that leverages the Stream API to automatically post updates to Discord which you can clone on GitHub.

We’re excited to get this beta version in the hands of the ecosystem and we’ll continue to iterate and improve upon the Stream API during beta period. To get started, check out our Stream API developer documentation which will walk through setup and using our SDK. Please let us know what you think and share your feedback, questions, and issues in our Developers channel in Discord.

We can’t wait to see what you build!

FAQs

Do the events received from my subscriptions count towards any rate limits on my API key?

No, events are not counted towards any API rate limits.

What is the typical streaming rate that I should expect from the Stream API?

The streaming rate depends on a range of factors - from the amount of collections that you’re monitoring to the type and amount of events that you’re subscribed to. For instance, if you’re subscribed to receive bid events across all collections on OpenSea, you’ll be receiving messages at a significantly higher rate than you will for a subscription to order cancellations on a small collection.

Should I expect that some events can be received out of order?

You should be prepared to handle receipt of events out of order as we don’t guarantee delivery of events in the order that they occur. Payloads include the event_timestamp field, which represents the time at which the event occurred and is the most definitive resource in determining order. We also include a sent_at field that refers to the time at which we sent the message out through the websocket.

Is it possible for some events to be missing?

The Stream API is a best-effort delivery messaging system and messages that are not received due to connection errors will not be re-sent. So it’s possible that there can be missing messages if the socket connection is unstable.

What blockchains does the Stream API support?

The following blockchains are supported on Mainnet networks:

• Ethereum

• Polygon mainnet

• Klaytn mainnet

• Solana mainnet

The following blockchains are supported on Testnet networks:

• Rinkeby

• Polygon testnet (Mumbai)

• Klaytn testnet (Baobab)