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:

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 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 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?

  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?

  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

  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

  • 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.

Building live streaming on the blockchain at Livepeer. Previously Founder, VP Eng at Wildcard and Hyperpublic (acquired by Groupon).

Building live streaming on the blockchain at Livepeer. Previously Founder, VP Eng at Wildcard and Hyperpublic (acquired by Groupon).