Check the repo here.

Note: Currently under active development. Contact project's maintainers at development@zap.org

Overview

The Zap platform serves as a data broker amongst the members of its network.

Data providers are incentivized to publish secure data feeds from a variety of endpoints which are monetized via provider-specific bonding markets.

In these bonding markets, data-consumers and/or speculators stake ZAP tokens to data-providers in exchange for data-provider-specific access tokens, ‘dots’.

Dots are redeemable as :

query requests to the data-provider in request endpoints(ex. smart contract endpoint)

subscription periods to data-provider streams in subscription endpoints (ex. ipfs pubsub socket endpoint)

an amount of ZAP token determined by data-provider-specific bond market price

The purpose of the API is to allow developers to register accounts, set bond market parameters and expose their tokenized service to both offchain subscribers and onchain user-contracts

The API allows developers to achieve the following:

register data-providers on our backend via the Registry class

write feed-specific data-provider daemons to serve both queries and subscription requests

operate ETH/ZAP-token wallets in their scripts

interact with our data-provider-specific bonding curves for data monetization and data-provider speculation

Incorporate data streams into their scripts

develop endpoint-specific feed handlers

What the API does not handle

account management

subscription storage

command line interface

Contract Overview

The ZAP platform currently exists as as a collection of contracts on the Kovan testnet. A list of the five main contracts and their purposes follows.

ZapToken: serves as a ledger for the zap tokens which may be bound to any data provider in return for finite access to a provider's data. The amount of access granted per token is based on provider defined supply/cost curve.

Registry: where data providers themselves are represented as structures in which public keys for data/query encryption, account addresses, bond pricing parameters and endpoint-specific parameters are housed.

Bondage: data-provider endpoint specific bonding is performed via this contract.

defines the available pricing curves in plots of access-cost(dot-cost) versus access-supply(dot-supply) based on provider defined parameters calculates request/subscription prices for given data providers via 'dot' prices. holds dots in escrow between user and provider during subscriptions and pending transactions allows ZAP to be bound for dots at price defined by point on provider specific curve allows dots to be burned for ZAP at price defined by point on provider specific curve

Dispatch: handles delivery and bond-market interface for smart contract endpoints (ex. a smart contract-powered futures contract for crypto-exchange prices which queries a data-provider, or "oracle", for BTC-ETH spot price at a timestamp)

Arbiter: handles data delivery and bond-market interface for temporal subscriptions. The first temporal subscription endpoint we are building out consists of IPFS Publisher/Subscriber socket subscriptions. (ex. user wishes to subscribe to a real time data feed for 2 hours)

Registry, Bondage, Dispatch, and Arbiter storage is decoupled from their logic, allowing these contracts to be securely updatable.

Bonding Curve Encoding

Token holders bond ZAP token to provider endpoints, which mint DOTS, redeemable for endpoint-specific services, according to a DOT-PRICE vs DOT-SUPPLY Curve. For example, an oracle(provider) answering queries for sports data will deploy a 'Sports Data' endpoint and price-supply function. If costs are uniform, this function will simply be a constant( the price per query), DOT-PRICE = 10 Another provider might offer subscriptions to market event signal data via a website. In this case, 1 DOT may be redeemable for 1 hour of signaling data. This hypothetical "Market Signals" provider has limited bandwith to provide socket data to subscribers and may decide to deploy a 'Market Singals" endpoint which increases in costs the more unspent dots have been issued and limited the total number of unspent dots to 100. "Market Singals" endpoint price-supply curve is set at DOT-PRICE = 2(DOTS-ISSUED)^2 Zap allows for peicewise price-supply functions as 'sum of powers polynomials' For DOT-PRICE = 2(DOTS-ISSUED)^2, the encoding of the function supplied in endpoint deployment is as follows [3, 0, 2, 1, 100] The first element is the `length` of the first polynomial in the piecewise function, the number of terms included Each number after that for `length` of terms in the piecewise segment are the coefficients to the `k`th term (e.g. that exmaple is 3 terms, with 0x^0 + 0x^1 + 2x^2) The last value in this function is the length of the peicewise segment itself, that is, the max number of DOTS for this piecewise segment. In this example, the limit is 100