Introducing AuctionHouse: An Ethereum Dapp For Auctioning On-Chain Goods

AuctionHouse is a work-in-progress auction protocol and decentralized application built on Ethereum. The alpha is running on the Morden Testnet and is hosted at:

• http://auctionhouse.dappbench.com via Amazon S3
• Code at Github and Etherscan verification
• On IPFS (the hash changes every time we update frontend code, which is frequently, so let’s save IPFS for a MainNet Beta).

You’ll need to be running a local Ethereum node, Metamask, or Mist to give it a try. If you’re new to Ethereum, and aren’t sure what we’re talking about, I recommend watching the video on Metamask.io which provides an overview on how to get started using a Dapp browser. For a walkthrough on using AuctionHouse, check out this post.

What is AuctionHouse?

In the physical world there are plenty of commodities, such as oil or soybeans, that are traded on exchanges. These items are said to be fungible, as a barrel of oil over here, is largely interchangeable with a barrel of oil over there. Exchanges do a great job of determining the market price by efficiently matching supply with demand for these goods. While these particular commodities are interchangeable, there are many real world examples of items that are one-of-a-kind, or non-fungible, such as a used 2006 Jeep Cherokee or a near-mint condition 1989 Ken Griffey Jr Upper Deck rookie card. These goods are unique because of their condition or other attributes, and as a result, there’s no market that can quote an efficient price for every unique item. As a result, auction platforms like Ebay, turn out to be much more efficient for fetching the best price for the seller.

In the blockchain world at the moment, we see plenty of examples of exchanges for fungible goods, often represented by tokens. It’s easy to find an exchange to buy tokens like Ether, Bitcoin, Augur REP, etc. But soon, as distributed applications and platforms built on top of blockchains begin to emerge, we’re also going to see non-fungible unique goods, identified by the metadata associated with them. For these types of goods, if an owner is looking to determine the fair price, then they’re best served running an auction. My colleague, Eric Tang, and I would like to present AuctionHouse: an auction platform for on-chain, non-fungible goods, built on Ethereum.

Here are some examples of the types of things we’d expect people will be looking to auction off in the blockchain ecosystem in the coming months and years as various new platforms emerge:

• A domain name registered on the Ethereum Name Service
• An on-chain virtual good (a sword in an Ethereum backed RPG, or virtual baseball card)
• A real world good represented by a token on the blockchain (a concert ticket)
• A token that represents a money-earning role in an on-chain economy
• A large block of tokens that would be easier to sell at once than gradually on an exchange
• Use the platform contract to run an auction within your own protocol or dapp instead of writing your own auction logic

How does it work?

People who are familiar with how auctions run on Ebay will be familiar with the basics of AuctionHouse, however the AuctionHouse platform is fully decentralized, so there is no owner or central company sitting between buyer and seller. Users can auction off anything on chain that conforms to the Asset Interface (more on that later), the AuctionHouse smart contract takes ownership of the auctioned asset, and it manages bids and associated ETH as the auction progresses and completes. The workflow is as follows:

1. Seller creates auction
2. Seller transfers ownership of asset to auction contract and activates auction
3. Bidders bid on the item, and the contract holds your bid amount in ETH. When you are outbid, your ETH is made available for you to withdraw.
4. At the conclusion of the auction, if the reserve price is hit, the item is transferred to the winner and the ETH of the high bid is withdrawable by the seller. If the reserve isn’t hit, the money and asset are returned.
5. There is an optional marketing incentive to encourage promotion of the auction amongst third parties (explained in next section).

Why another auction platform?

Auctions are commonly referred to throughout Ethereum examples and developer documentation. Why did we decide that the ecosystem could use another auction dapp like AuctionHouse? There were two reasons:

1. While smart contract code examples existed, we thought the ecosystem could benefit from a fully working Dapp with a decentralized protocol and reasonably polished interface for auction discovery and promotion.

We have been hacking on Ethereum for a few months, but this is the first time that we went end-to-end and built not only smart contracts, but also tests, frontend, and deployment across multiple networks. It was a great learning experience, and hopefully the result is the beginning of a sustainable platform that’s usable not only for ethereum hackers and developers, but also for the casual consumer who is running Metamask. UI matters, and there are certainly challenges ahead to make AuctionHouse highly engaging, but at the moment it is off to a reasonable start in terms of being usable and approachable.

2. We wanted to experiment with different incentives to make this platform sustainable in a decentralized fashion.

In a centralized auction system, the auction platform generally takes a cut. They use this in order to fund the various aspects of their business including hosting, marketing, fraud prevention, etc. However in a decentralized system owned by the participants in the network, this cut should be determined by the network and not any central party. Our first experiment in the alpha version of AuctionHouse is what we called the Distribution Cut.

A seller can optionally set a percentage of the auction finishing value to be sent to one predetermined address. The idea is that whoever controls that address is now incentivized to promote the auction and bring bidders to it, to increase the value of their cut. In all likelihood this will be a more centralized frontend that happens to have a large amount of traffic or a large social media reach. Our sample frontend (transparently) sets this fee to 5% of the auction finishing value, so that any auction created via our frontend will share in the profits with an address determined by the frontend. That specific frontend can then look at all running auctions and determine which ones to promote/feature based on its own self interest and expected gain. This creates a healthy ecosystem in which anyone who profits from the AuctionHouse network is incentivized to contribute positively to its growth in the future via marketing, development, and other services.

Of course a seller can set this distribution cut to 0% if it’s willing to promote its own auction and bring its own bidders. There are plenty of additional models of incentives we’re interested in trying to bake in, such as doing it at the per-bid level instead of the auction level in order to support multiple frontend platforms.

We need your feedback

There are three things we’d like feedback on specifically from the community before moving on to Beta:

1. Any item that adheres to the Asset.sol spec is auctionable, however we aren’t sure how to guarantee other than via social inspection and proof, that the underlying implementation of owner() and setOwner() actually transfer full semantic ownership of the asset to the winning bidder. In the fungible world, ERC20 has emerged as a standard, however in the non fungible world there can’t really be a standard as each asset has unique attributes, metadata, and functionality. There’s no standard bytecode to check against like there is with ERC20. Any suggestions would be appreciated in this github issue.
2. What do you think about the Distribution Cut incentive described above? What other incentives should exist for other roles in an auction ecosystem? In this case the auction sets an incentive for one party to market it, but how could it set an incentive for multiple parties? Can you securely set an incentive for a party on a per-bid basis? If we can’t solve feedback point #1 above, do we need a fraud resolution procedure? We’d love to discuss in this github issue.
3. Contract security is a big issue in this stage of Ethereum’s development. Do you think our contracts look secure, and have they implemented best practices? Any feedback is appreciated.

Notes on development

Lastly, as mentioned, this was our first time developing a Dapp end-to-end, and we’re excited to reveal it as an alpha so people can play around with it long before it’s finalized and ready for main network transactions. The dev process was a learning experience and it’s clear that there’s a long way to go before building a dapp is as easy as building a web app. We’ll address all our lessons learned and pain points in another post, but in the meantime we’d like to thank the teams behind:

• Truffle, for the development workflow, testing framework, and deployment support.
• Metamask, for the web wallet support.
• Web3, for the great web library for interacting with the Ethereum RPC interface.

Thanks for reading, and please share any feedback to @petkanics and @ericxtang.