-
Notifications
You must be signed in to change notification settings - Fork 10
1. Devise Primer
The Exchange Where Synthetic Assets IPO To Help Fund Managers Hunt Alpha.
Table of Contents
Assets aren’t listed on traditional exchanges so that hedge funds can generate alpha, but clearly markets aren’t fully efficient, and there is alpha to grab. Devise (pronounced \də.viz\) [1] is an alternative exchange containing (hundreds of) synthetic assets that are engineered from the ground-up to help hedge funds hunt alpha.
Each synthetic asset on Devise, which we call leptons [2] [3], is a stream of long/short dollar-balanced portfolios of 26 of the oldest and most liquid U.S. futures, whose weights are rebalanced on a daily basis, shortly after market close. In particular, Devise is a set of data streams, and leptons are not investments or securities and cannot be physically or digitally owned. Instead, buying a lepton is done by following its portfolio weight updates, and selling a lepton is done by betting against its portfolio portfolio weights updates.
Devise is restricted to professional investment managers (e.g. registered investment advisors), and they should exercise due discretion to determine if/when to buy, sell or ignore any lepton, similarly to how they would do so for any traditional exchange-traded asset. The Devise platform does not engage in, or facilitate the buying or selling of future contracts or any other security.
Scarcity of access to Devise is guaranteed so as to prevent inefficiencies captured by Devise leptons from being priced-in over time. The scarcity guarantee can be audited without a trusted central party, and in a fully decentralized fashion. Morevover, Devise can be accessed anonymously end-to-end if privacy or mitigating information leakage is a concerned.
Companies don't IPO so that investment managers can make money, and blue-chip stocks IPO very infrequently. Leptons IPO on (or are added to) the Devise alternative exchange if and only if they can provably make it easier for investment managers to generate alpha.
Specifically, for a lepton to make it to the Devise exchange, it needs to satisfy the four criteria of usefulness discussed in our Yellow Paper. Namely, the new lepton needs to:
- Have high incremental diversification value, both relative to the existing blockchain and to U.S. futures.
- Be at least as predictable as exchange-traded assets.
- Be at least as suitable for passive investment as U.S. blue-chip stocks.
- Not make tails of the set of leptons already on Devise heavier.
Every day shortly after market close, each lepton produces new long/short dollar-balance portfolio weights for the same basket of 26 liquid U.S. futures.
Here is an extract from the update made by a lepton on 20180803:
| Date | Asset | Weight |
|---|---|---|
| 20180803 | CME_BO | -0.028330 |
| 20180803 | CME_BP | 0.010222 |
| 20180803 | ... | ... |
| 20180803 | CME_US | 0.012396 |
| 20180803 | CME_W | 0.004431 |
Each weight can be used as a (relative) predictive score for the return between the settlement price on the day following the weights update, and the settlement price two days after the weights update. A large (and positive) weight predict that the corresponding asset will appreciate, while small (and negative) weights predict that the corresponding asset will depreciate. Each lepton can, therefore, be used as a set of 26 predictive signals; a form of alternative data.
Crucially, because a requirement for a lepton to be added to the Devise exchange is that it sufficiently diversifies existing leptons, as alternative data sources, leptons (are engineered to) complement each other.
Every new lepton added to Devise is not just a new alternative dataset that has a high predictive value in absolute terms, it also provably complements all alternative datasets already on the exchange.
The incentives of alternative data vendors and their clients often conflict. Vendors aim to sell their data to as many investment managers as possible to maximize revenue. However, as an alternative dataset becomes popular, it gets 'priced-in', and its intrinsic value to each investment manager using it declines. For that reason, investment managers typically seek exclusivity deals, thereby placing a cap on vendors revenue. The Devise platform aligns our incentive to yours.
Access to the Devise alternative exchange is capped to 100 seats at any point in time, so as to preserve the intrinsic utility of the exchange to you. In case you seek a higher level of exclusivity, you can bid for as many seats as you want, up to the maximum of 100.
Seats are reallocated on a monthly basis following an auction during which the rent per seat for the following month is determined. The auction algorithm aims at finding the fair value of the Devise platform. As a result, the cap on the number of seats does not limit our bottom line; our bottom line is directly tied to the usefulness of leptons on the Devise blockchain.
We believe that the more value hedge funds can generate out of the Devise alternative exchange, the more they will be willing to pay for a seat, and the more money Pit.AI Technologies makes, despite the capped number of seats.
Our rental contract is an Ethereum smart contract. The list of all public keys authorized to access the Devise platform, along with the total number of seats occupied, and associated bids, are forever publicly accessible as immutable data on the Ethereum blockchain, for free.
Hence, the Ethereum blockchain effectively serves as a decentralized audit system, which you can use to verify our auction pricing and seat allocation mechanisms, including checking that the cap on the number of seats allocated is enforced.
We provide utility functions to audit all our smart contracts in Python. You can also do this by querying our deployed contract directly from any node of the Ethereum network, for instance, Etherscan.
We know that information leakage erodes your alpha. Nobody needs to know what alternative data drive your investment process, not even your alternative data vendor, or what assets you buy/sell.
By using smart contracts instead of traditional paper agreements, a cryptocurrency instead of bank wires, and elliptic-curve cryptography to authenticate API requests, we never need to know who you are, neither does anyone else.
You have full control over which public key(s) you use to interact with the Devise platform, and no one can tell which investment manager owns which public key(s).
Every lepton is a trading strategy trading 26 of the most liquid and oldest U.S. futures. A trading strategy defines a mapping between a compressed representation of the state of financial markets [4] and a target set of portfolio weights. Leptons that are promising in-sample are considered to be IPOed on the alternative exchange, based on out-of-sample data.
A lepton is IPOed on the Devise exchange if and only if its out-of-sample returns time series is found to sufficiently add to the usefulness of the reference pool of assets consisting of all leptons currently on the Devise exchange, and a universe of U.S. futures accounting for 90% of U.S. trading volume. In other words, for a new lepton to be added to the Devise platform, it needs to add value to both all U.S. futures and all previously found leptons.
Specifically, to be IPOed on Devise, each new lepton should pass the four criteria of incremental usefulness relative to the reference pool above, as defined in our Yellow Paper, namely sufficient incremental diversification, sufficient predictability, suitability for passive investment, and acceptable tail impact.
First, we test whether the candidate lepton has sufficiently predictable returns out-of-sample, as per Section 4 of our Yellow Paper.
Simply put, the candidate lepton is rejected for not being sufficiently predictable when, with p-value 5%, we can reject the null hypothesis H0 that its measure of auto-predictability is as high as those of exchange-traded assets.
Exchange traded assets considered are a set of U.S. futures accounting for 90% of trading volume, and constituents of the S&P 100. Using out-of-sample data, we compute the measure of auto-predictability of each of the exchange-traded assets considered, and we learn a canonical distribution of measures of auto-predictability of exchange-traded assets by solving a Bayesian density estimation problem under a Normal-Inverse-Gamma prior.
We deem a lepton sufficiently predictable when its measure of auto-predictability is higher than the 5% percentile of the posterior distribution of the measure of auto-predictability of exchange-traded assets.
Second, we ensure that the candidate lepton sufficiently diversifies the reference pool out-of-sample, as per Section 3 of our Yellow Paper.
Each company in the S&P 100 is a landmark in the American stock market. Simply put, we want every lepton IPOed on the Devise alternative exchange to be as unique as a young American company IPOing and making it to the S&P 100.
More precisely, to be added to the blockchain, we require of the candidate lepton that it diversifies the reference pool by more than a company in the S&P 100 diversifies the rest of the S&P 100 on average.
We compute incremental diversification using the order-q variant of the Yellow Paper, with q=10, and the maximum-entropy estimation method.
Third, the candidate lepton needs to be suitable for passive investment, as described in Section 6 of our Yellow Paper.
We use as the benchmark for assets known to be suitable for passive investment constituents of the S&P 100, and we use 5% as the p-value for the statistical test of suitability for passive investment proposed in our Yellow Paper.
Finally, to be added to the Devise platform, a candidate lepton needs to have a non-negative impact on the tails of the reference pool out-of-sample, as defined in Section 5 of our Yellow Paper.
In other words, a newly added lepton should not make the tails of the Devise platform any heavier.
Access to the Devise alternative exchange is fully controlled by the rental smart contract. The fee model is a subscription model with monthly terms.
The monthly fee per seat varies depending on the number of assets listed on the exchange on the first day of the term, and the total amount of incremental diversification they added to the exchange at the time of their IPOs.
There is a fixed baseline fee per seat and per unit of incremental diversification. Clients request access to Devise by submitting a bid at a certain limit price for the fee per seat and per unit of incremental diversification, and for a certain number of seats. To be valid, a bid needs to be at least as high as the baseline fee, and the bidder should have a high enough balance in his/her account to honor the bid. Investment managers only need a seat to access Devise, but they can further restrict the scarcity of access to Devise by requesting many seats, up to the maximum of 100.
An indicative monthly fee per seat and per unit of incremental diversification for the following term is automatically calculated by the rental smart contract every time a bid is submitted, updated or canceled, by running an auction algorithm aiming at finding the fair value of the Devise alternative exchange under the capacity constraint. Indicative fee and seat allocation are frozen on the first day of the term, seats are attributed and successful renters are charged accordingly.
We have built the devise Python package so that you may perform any Devise-related tasks in a few lines of Python code. From funding your account, to interacting with our deployed Ethereum rental smart contract (on-chain or off-chain), to interacting with our crypto-powered API.
All we ask of you is that you use Python 3. If you don't want to switch to Python 3, you might find Pyenv useful.
In all code snippets below python and pip are Python 3 equivalent. Replace with python3 and pip3 respectively if the python alias maps to Python 2 on your machine.
The simplest way to install the Devise repo is from PyPi:
$ pip install devise
Alternatively, you may clone this repo and install it:
$ git clone https://github.com/devisechain/Devise
$ cd Devise/python
$ pip install .
For more detailed installation instructions, and for information on platform specific system dependencies, please consult our Installation Guide
All our smart contracts are Ethereum smart contracts. Our API on the other hand, which is used to retrieve any trading data about the Devise blockchain, such as historical weights and returns and ongoing weights, is hosted on a private infrastructure.
By default, we will always attempt to connect to the Ethereum network using a public node. You may also specify a specific Ethereum node URL to connect to.
For signing Ethereum transactions, we support hardware wallets (to be specific, Ledger Nano S for now, and soon Trezor), encrypted keystore files, and clear private keys.
Interactions with our Ethereum smart contracts can be of two types. Some operations only need to read the state of our smart contracts (e.g. to retrieve the list of all bids, the indicative auction price for the next term, the list of strategies on the blockchain, the list of all bids etc.). These operations are free.
Other operations need to change the state of our smart contracts, and consequently of the Ethereum blockchain (e.g. submit a bid, fund an account, etc.). These operations, like any on-chain Ethereum operation, can only be performed by Ethereum miners, and therefore cost `gas' in Ether.
Any gas charged will be deducted from your account, and on-chain transactions will fail if your account does not have enough Ether. We provide the @costs_gas decorator in Python to help you differentiate operations that cost gas from operations that are free.
Every Devise-related operation can be performed in Python using the DeviseClient class. From funding your account to interacting with our rental smart contract, to making calls to our cryptographic API.
To use the key files generated by a local Official Ethereum Wallet for signing, run
from devise import DeviseClient
# Create a Devise client object to interact with our smart contracts and API.
devise_client = DeviseClient(account='0xd4a6B94E45B8c0185...')or
from devise import DeviseClient
# Create a Devise client object to interact with our smart contracts and API.
devise_client = DeviseClient(account='0xd4a6B94E45B8c0185...', password='<your password>')where account is the Ethereum address of the account on behalf of which all Ethereum transactions and API requests will be conducted and signed.
When a password is not provided, you'll be prompted to type it in everytime a transaction needs to be signed.
To sign transactions with Ledger Nano S, run
from devise import DeviseClient
# Create a Devise client object to interact with our smart contracts and API.
devise_client = DeviseClient(account='0xd4a6B94E45B8c0185...', auth_type='ledger')You will be required to enter your PIN on the device once, and then review/approve each transaction to be signed from the device.
To sign transactions with Trezor, run
from devise import DeviseClient
# Create a Devise client object to interact with our smart contracts and API.
devise_client = DeviseClient(account='0xd4a6B94E45B8c0185...', auth_type='trezor')You will be required to enter your PIN on the device once, and then review/approve each transaction to be signed from the device.
To use keyfile-based signing from a custom path, run
from devise import DeviseClient
# Create a Devise client object to interact with our smart contracts and API.
devise_client = DeviseClient(key_file='<path to your encrypted json keystore file>')or
from devise import DeviseClient
# Create a Devise client object to interact with our smart contracts and API.
devise_client = DeviseClient(key_file='<path to your encrypted json keystore file>', password='<your password>')When a password is not provided, you'll be prompted to type it in everytime a transaction needs to be signed.
To use clear private keys for signing, run
from devise import DeviseClient
# Create a Devise client object to interact with our smart contracts and API.
devise_client = DeviseClient(private_key='<your private key>')The DeviseClient connects to the Ethereum network through a public node that is chosen for you by default. Which node we connect to does not make any practical difference. However, if you would prefer connecting to a specific Ethereum node, you can do so by populating the node_url argument of DeviseClient.
Security Note: We do not use the account management functionality of Ethereum nodes. All transactions are first signed locally and then submitted to the Ethereum network through a public node. Any credential you provide to us (password, encrypted keystore file or private key) never leaves your machine and, in particular, is never shared with any Ethereum node.
To access the Devise exchange, you need to have an escrow account with us that is sufficiently funded. This account is only used to collect rent and determine whether you are eligible to access historical data.
To create an escrow account with us, and/or provision an existing escrow account with qty ETH's worth of DVZ tokens, run the following command:
# Provision your escrow account with DVZ by transferring qty ETH from your Ethereum wallet to the rental Smart contract.
qty = 1000
devise_client.fund_account(amount=qty, unit='ETH', source='ETH')This command funds qty ETH's worth of DVZ into your escrow account with us at an ETH/DVZ rate such that 1 USD = 10 DVZ (Note: conversion rate updated hourly and may not match current ETH exchange rate).
You can check the balance of your escrow account in DVZ like so:
# Check the balance of your escrow account
balance = devise_client.dvz_balance_escrowHistorical data consists of the time series of portfolio weights as decided by each lepton on the Devise exchange, and corresponding marked-to-market returns, going back four decades.
Access to historical data is free, but limited to ligitimate use cases. To download historical data, you first need to request access as a one-off.
# Request the right to access historical data.
status = devise_client.request_historical_data_access()Access to historical data is only granted to clients whose escrow accounts are sufficiently funded to pay at least one month of rent for one seat. You can check if you have access to historical data by inspecting your account summary.
# Check if you are currently allowed to request historical data.
has_access = devise_client.client_summary['historical_data']
print(has_access)Once the smart contract has a record of you being authorized to request historical data, you can make an API request to download all historical data.
# Download historical weights of all leptons on the Devise
# exchange and stores them in the file 'devise_historical_weights.tar'
# in the current folder.
historical_weights = devise_client.download_historical_weights()
# Download historical returns of all leptons on the Devise
# exchange and stores them in the file 'devise_historical_returns.tar'
# in the current folder.
historical_returns = devise_client.download_historical_returns()For more details on the structure of downloaded data, please consult our trading specification.
Once you have downloaded historical data, we encourage you to estimate how much value you expect to get out of the Devise platform, in preparation for auctions.
Rents are always proportional to the total incremental usefulness, defined as the sum of all incremental usefulness each lepton added to the chain at the time it was found, as recorded on the deployed rental smart contract.
# Retrieve the total incremental usefulness of the exchange.
total_usefulness = devise_client.total_incremental_usefulnessWe use as incremental usefulness the incremental diversification, as defined in the Yellow Paper.
Bids are considered limit prices per unit of total incremental usefulness and per seat. That is, all successful bidders will pay the same rent per seat, which could be lower than implied by submitted bids, but can never be higher than implied by any successful bid.
The starting bid per unit of incremental usefulness and per seat is 1,000 DVZ; lower bids will automatically be rejected.
Rent per seat is calculated at the end of the month for the following month as the product of the auction price and the total incremental usefulness at the time of the calculation.
A bid can be submitted like so:
# Submit a bid for 10 seats on the Devise platform.
seats, lmt_price = 10, 2000
devise_client.lease_all(lmt_price, seats)For more details on the auction algorithm and other auction-related functionalities available in the devise package, take a look at our auction specification.
Although the same account may be used for sensitive on-chain transactions (e.g. token transfers) and API calls, we recommend using a separate account for API requests. We call this account the beneficiary account.
A beneficiary account can be designated like so:
# Designate a separate account as beneficiary of API data and updates.
beneficiary_address = '0x3453ff...'
devise_client.designate_beneficiary(beneficiary_address)Note that the beneficiary account is only allowed to make API requests on behalf of the paying account; it has no other privileges.
There can only be one beneficiary per account, so once a beneficiary has been designated, the paying account can no longer make API requests, and the DeviseClient used to make API requests should correspond to the address of the designated beneficiary.
Whether a beneficiary was explicitly designated or not, the address authorized to make API requests on behalf of the paying account can be retrieved like so
# Address that should be requesting data from our API on your behalf.
api_account = devise_client.beneficiaryLeptons produce new weights on a daily basis. Weights are available for download from our API by 7AM ET Monday to Friday, and are good until the following market close.
To download latest weights, run
# Download latests weights of all leptons on the Devise
# exchange and stores them in the file 'devise_latest_weights_[date].zip'
# in the current folder.
latest_weights = devise_client.download_latest_weights()For more details on the structure of downloaded data, please consult our trading specification.
Mining Devise leptons is currently restricted to Pit.AI Technologies, and will be open to the public shortly. Stay tuned.
Please read this section carefully before buying Devise tokens and leasing the Devise exchange.
Devise leptons cannot be owned or exchanged. A Devise lepton is a representation of financial markets, which clients rent access to, and to whom there can only be a limited number of access at any point in time. Buying or selling Devise leptons entails following or betting against the investment decisions made by the corresponding leptons. Devise leptons are not securities.
Securities exchanged as part of buying or selling leptons are liquid exchanged-traded assets, specifically futures contracts trading on U.S. exchanges. These future trades neither take place on nor are facilitated by the Devise platform.
Devise leptons can be bought, sold, ignored, or a combination of these, across time. More importantly, Devise data updates do not constitute investment advice.
The best analogy to Devise data updates are orderbook updates, which provide market participants sufficient information on what to do to buy or sell exchange-traded assets, but do not recommend buying or selling a specific security.
Clients choosing to buy or sell some or all leptons on the Devise platform do so at their own discretion and risk.
Devise is an alternative data solution, not investment advice.
By buying Devise tokens or requesting access to the Devise platform, clients acknowledge that they have read our Yellow Paper, and agree with the approach we propose therein for quantifying the usefulness of a tradeable representation of financial markets.
Clients also agree that payments in Devise tokens to access the Devise exchange are not refundable and are:
- Compensation for research and compute power spent towards increasing the usefulness of the representations of financial markets provided by the Devise exchange, as described in our Yellow Paper.
- Compensation for the infrastructure and processes powering the Devise exchange.
To learn more about our information-theoretic approach to quantifying the incremental usefulness of leptons, please read our Yellow Paper.
If you have any questions on the nature and/or structure of historical data and ongoing data updates, or any trading questions, we invite you to read our trading specification.
Auction rules and auction-related functionalities of the devise Python package are discussed in our auction specification.
We recommend that you take a look at our security best practices before making any transaction.
In case you would like to bypass this Python package and interact with our deployed smart contracts directly, we refer you to our smart contracts specification.
For details on how to use our cryptographic API directly, we refer you to our API specification.
You can also find out how Devise relates to Pit.AI Technologies' mission.
| [1] | The name devise comes from the French for 'currency'. |
| [2] | The name lepton comes from the analogy with elementary particles of the same name, that are in the same (half-integer) spin class but have different masses. |
| [3] | Strictly speaking, traditional exchange-traded assets are (special kinds of) leptons in the Devise sense. That said, traditional exchange-traded assets are to leptons in the Devise sense what electrons are to leptons in the particle physics sense: they are much easier to observe/access than other leptons, but carry the least weight in their respective lepton families. |
| [4] | These compressed representations are the result of ongoing ML research at Pit.AI Technologies to empower our AI to have access to as much price-sensitive information as human quants, without overwhelming our AI computationally. These are not alpha signals, but rather compressed versions of data that can be used to build alpha signals, where the compression preserves the extent to which alpha signals can be built and their quality. For more information, checkout `how Devise relates to our mission`_. |