What if 0x could be used for decentralised real-time bidding advertising?

A look into ZEIP18 and the opportunities it opens up by allowing orders to be funnelled through external contracts.

Felipe

Published in

Paratii

10 min readFeb 20, 2018

🚨 This is a crude post. Ideas are presented raw to be killed early or stolen quickly.

There has been a lot of talk on crypto collectibles becoming “the application of 2018" for decentralised networks. Media distribution businesses are also in a frenzy, many believing this is the year when GAFA begins to fail, and distributed alternatives enter the mainstream.

Another increasingly promising field, and the one we’ll be looking into here, is that of decentralised exchanging. 0x, one of the most used DEX protocols, has seen a staggering growth of developer activity in its ecosystem, with a dozen relayers being actively worked on and some turning profits already. The emphasis of the project on open governance seems to be yielding fruits: ZeroX Improvement Proposals, or ZEIPs, are working smoothly since the network has launched, with a lot new tweaks and features in sight. Here, we’ll explore the possibilities opened up by one of this proposals.

0x protocol

Off chain orders being passed around before settling on chain. By 0x.

0x is a building block for decentralised exchanging. The protocol defines a message format for orders (as in an order book), to be signed and communicated off-chain. But no one would have reason to “listen to”, or to collect such orders, unless they can earn something with it. That’s where Exchange.sol comes into place. This contract can receive orders “injected” into it by any party, and execute one against another, on-chain, atomically. It is a simple contract and can only fill or cancel orders.

One can make point-to-point orders (in case the counter party is already known, and there is no need to find liquidity)… or, otherwise, broadcast orders that don’t previously specify a counter party and can be picked up by an agent willing to find matches for them.

Makers, Takers and Relayers

In 0x terminology, the maker is the agent who makes an ask order, and the taker is the agent which makes a bid order.

Relayers, in turn, can be seen as “robots” that listen to such orders and aggregate them into order books. They compete in providing liquidity to traders, by running flexible matching strategies (which may include batchFilling of orders, for example), pairing compatible ask-bid orders and injecting them into 0x’s exchange contract. Relayers do this in exchange for a fee, usually charged upon the taker. This scheme originated the expression “off-chain order relay with on chain settlement”, commonly used to the describe the type of protocol 0x conforms to.

A relayer can maintain, on its own, a friendly interface imitating an actual centralised exchange order book (e.g. Radar Relay); they can focus on APIs for providing liquidity specifically to dApps that need multiple tokens to operate (e.g. Amadeus); they can even adopt models or tackle niches we’re not aware of, yet.

ZEIP18: decoupling agents for increased flexibility

ZEIP18 was put forth in the last day of 2017, and is still under discussion. It’s final aim is to allow orders to be funnelled through pipelines of custom logic.

The basic proposal is to decouple the taker of an order from its msg.sender (in the current implementation, the taker is always the sender), by allowing the signature of the taker to be passed into fillOrder.

What’s interesting is that a trader can also set the taker field as the address of an Externally Owned Account - a smart contract - that will be required to execute the order. This contract can be then used to implement arbitrarily complex processes, while maintaining a clean distinction from the protocol’s core contract and components.

Illustrated by the 0x team on Front Running, Griefing, and the Perils of Virtual Settlement pt.2

Some of the things one could do through such mechanics are (ideas come from Will Warren):

Creating orders that can only be filled by addresses in a whitelist, or with a signature from another party.
“Funnel orders through a contract that eliminates front-running and trade collisions by enforcing rules around trade execution”.
“Funnel orders through a contract that allows a network of “wranglers” to liquidate a trader’s margin position if it falls below its collateral requirement, per the rate provided by a trusted price oracle”.

But what if we could use this EOA to enforce non-financial logic? Suppose that, in order for the taker to pass in his signature and fill the order on Exchange.sol, he first has to receive a signature himself, and one that proves not only identity but also the fact that its issuer has received and hashed a unique piece of data?

A decentralised RTB-driven ad-delivery network

Let’s consider the following case: an internet user browses to a random page that displays advertising right on the spot. A cookie sends user and contextual information to a labyrinthian supply chain and, after some milliseconds, an advertiser’s bid has already been matched with your profile, probably by a demand-side platform (which means your attention has been bought for some pennies), and an ugly banner comes to life in the screen.

The chain of intermediaries linking advertisers to final audiences. *Photograph by Terence Kawaja/Luma Partners*

That’s a rough summary of the process that actually takes place. The machinery in between is monstrous, in reality. Traffic data is aggregated by supply-side platforms (SSPs); processed by data management platforms (DMPs); impressions are put for sale on exchanges; bids for them come in through demand-side platforms (DSPs); originally sent by agencies. In most cases, the publisher is responsible for ensuring the ad has been delivered.

This logistic allows for precise user segmentation and near-instant trades. However, it doesn’t really optimise for price (with all those intermediaries to feed), and the data it shuffles around is not fully auditable, since it travels between a number of closed silos. You have widespread liquidity, but no global accountability. Also noteworthy, the process is twofold: a payment happens, then an ad is delivered. The execution of both is not atomic by design (we’ll see below how it could potentially be).

The idea here is to try abstracting this labyrinthian “exchange mechanism” through 0x, placing its execution in the hands of relayers.

A client that keeps issuing off-chain receipts.

Let’s imagine we have a client for consuming content, that automatically issues receipts as its user navigates. These are basically data packets, communicated off-chain, saying: “Hey, I’m here, this is what I’m doing, and here’s what I’m willing to do”. This client can be a browser, a dApp, or even a video player, churning out such packets. They take the form of a 0x-conforming message, containing, in special:

takerTokenAmount: the commission sought by the user on any ad shown to himself.
makerTokenAmount: this field would be passed in empty, since the users won’t be trading tokens for tokens, but rather attention (a commitment enforced via an external contract) for tokens.
feeRecipient: the owner of the content on which the ad is being placed — the owner of the webpage, the video creator, the guy who wrote the article on which the banner displays. Even though the end-user acts as the order maker, in advertising, the bulk of the value should usually go to the creator of the content that provided the ad-placement opportunity, in first place.
takerFee: the price to be paid to the publisher or content creator for placing an ad on his stuff. This is ideally fetched by the maker client from the context where the user’s navigating (if the client is a web3 browser, it can fetch a price for each page, set by each domain owner).
maker: the end-user’s Ethereum address.
metadata: arbitrary user and context information, including a “proof of view”-type signature stating the client has received and worked upon a unique piece of media.

🚨 Let it be clear that two bold liberties are being taken here: first is that we assume a field for metadata on 0x orders. This is currently not implemented. However, an optional field could potentially exist, through which any kind of additional logic could be enforced by an external taker (e.g. by checking if the metadata on both a bid and a corresponding ask order match, for example, or fit within certain constraints). Second, “proof of view” is not a formula written in stone. There are multiple approaches to generating receipts of the kind, but none is infallible, or consensually taken for granted.

💭 Orders with empty makerTokenAmount and an optional metadata field could even come to constitute a distinct order type, as ZEIP4 lays the ground for.

Relayers can then listen to such orders and aggregate them under a hosted order book. On it, any media buyer could act as a taker and place orders specifying “bids for the attention” being offered on the other side of the market.

By allowing media buyers to set the taker parameter of their bids as an EOA, we can funnel orders through custom logic for ensuring a piece of media has verifiably been delivered, as specified by sender. Such logic could begin with media buyers placing bids with the following fields, in special:

takerTokenFillAmount: the price of the media buyer’s bid.
taker: the address of a smart contract that specifies the adHash of a content-addressed piece of media, on IPFS, for example.
expirationTimestampInSec: the period of time during which the bid is valid.
metadata: arbitrary user and context information.

Relayers match-make as they want, and inject paired orders into 0x’s exchange contract. The taker contract listens to new orders and fetches the address of whichever maker is put into trade with it. It sends the hash of the ad to be displayed to the maker address, and only passes his signature to execute the trade once it receives a “proof of view” back from the maker, hashing the referenced ad’s data (maybe along with the salt of the sender’s order, to avoid clients from storing reusable proofs). The client would listen to the contract’s message, fetch and display the referenced media piece, generate the proof and respond with it in order to get its fee. The contract:

checks if the proof is valid.
checks if it’s sender is indeed the maker on the exchange order.
checks if metadata specified by the bid order matches that (or the requirements) of the ask order.
checks if the expiration time of the order hasn’t passed.
passes its signature to execute the trade.

This setup yields some interesting consequences and questions:

It makes a clear split between the sources of value for any given impression: the context (provider) and the user. Traditionally, information on both is handled by third parties who share fees upon any exchange of “payment for ad-delivery”, the publisher usually being an intermediary himself that takes a large portion of revenue from the creator of the content that originated the ad-opportunity, in first place. Eliminating these third parties sets free a considerable amount of the overall exchanged value, and opens up the possibility for directly rewarding the targeted user. The mechanism outlined above goes a step further and poses the end-user as the order maker, which is a bit of a paradox since the context provider (content creator, domain owner, etc) traditionally receives the bulk of the value exchanged in any given “payment for ad-delivery” transaction. However, it also states the question: should most of the revenue indeed go to the context provider? How substantial should be the share of the targeted user? Should each determine their own “minimum prices”?
Presuming media buyers would be willing to place orders in the above-mentioned formats completely ignores the OpenRTB and other industry-wide standards. On the other hand, it makes the case that, maybe, we’ll soon witness the birth of specialised, industry-specific relayers very different than the ones we have today. ZEIP4 proposes a new field for 0x messages that defines an orderType, and might pave the way for a scenario on which some relayers operate orders of a certain type only.
Trading impressions on 0x makes the exchange execution atomic with the media delivery. Either both happen, or none. This places a lot of responsibility on relayers, since failed trades mean they had to put up with the gas cost of injecting orders on-chain but didn’t get any fee. Again, on the other hand, this means there can be relayers (or even service providers to relayers) that specialise in analysing metadata and filtering orders, or even indexing maker or taker addresses according to their “completion rate” on trades initiated.

Along dozens of technical matters, these are a few open issues to anyone willing to explore the notion of modular advertising trade networks upon 0x.

Regardless of immediate practicability, the objective here was to put forth the idea that 0x, and DEXs in general, will sooner or later decentralise non-financial markets too. Every digital industry has its never-ending supply chain waiting to be abstracted into an open market. It is a matter of time until a thousand relayers will bloom.

Paratii is on reddit, and the team is accessible through Telegram (BR here 🇧🇷, EN here 🇺🇸). Don’t hesitate to get in touch via email, or👇