Concept DAHF

From BiblePay Wiki
Revision as of 15:09, 15 April 2019 by Sunk818 (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


Decentralized Autonomous Hedge Fund

Core Values:

  1. Capital inflows into the fund - through BBP inbound - helping the state of our orphan sponsorships
  2. Inflows into a hybrid deflationary crypto/equity position
  3. Stability of Biblepay price
  4. Increased Intrinsic value of Biblepays IT state
  5. Exposing the trade secrets of Quant traders and hedge funds
  6. Ability for 3rd world countries to participate in highly leveraged positions normally reserved for accredited investors only
  7. Ability for 3rd world to hold retirement accounts in hedge funds
  8. Ability for 3rd world to execute complex TIMS trades reserved for accredited investors
  9. Consolidating secret hedge fund knowledge into a Biblepay virtual machine
  10. Competitive hedge fund portfolios and competing portfolio managers
  11. No single point of failure for 501(c)(3), core seed capital, custodial relationship or cash account
  12. No single point of failure for competing portfolios
  13. No single point of failure for market data providers or virtual machines
  14. Virtual Machine hedge fund portfolio language prevents non-biblepay-core code from being executed in the VM (virtual machine)
  15. Deterministic Virtual Portfolios creates hard rules for consensus allowing competing portfolios to send hard signals and execute on-chain trades


Core investor Group:

The Core investor group is a small group of seed-capital incubators, who are responsible for providing the initial investment capital to start the DAHF custodial asset account, create a relationship with the prime broker, secure the TIMS/PM agreement, create the 501c3 organization and stand behind the initial margin requirements to get the fund off the ground.

The Prime Broker will emit a daily report containing the M2M values of all securities held in the custodial account, and this feed along with feeds from the core wallet will allow us at biblepay-central for example to create accountability reports so that the fund is transparent. This allows all users to see the daily M2M value of all assets stored in the custodial account and therefore reconcile this against the day to day NAV of the fund.

Before the fund inception, Biblepay will create a PDF investor package and mail it to each sanctuary owner, and also to all who might be interested in being part of the core incubator group. The core will be comprised of accredit investors only (as governed by securities regulations). This group will sign into a contract that gives them shares of the DAHF core. In exchange for the risk, they will be privileged to receive 25% of the gross profit of the hedge fund up to a graduated amount according to the breaks table (approx $1 million is where the profit level for the core will decrease). The core group will need to raise approx. $1 million in order to have required cash levels to strike a deal with a prime broker for TIMS/PM leverage.

All positions executed by the Biblepay Hedge fund Virtual Machine - from any biblepay portfolio - will be added to the Prime Broker custodial account. These positions are considered to be opening or closing, have an origination portfolio ID, a global security type, a symbol, a quantity, and position description. To the core investor group, and to the prime broker, since these positions originate from any biblepay portfolio, they will not be recognizable positions, they will have a hash and the only way to make sense of what is stored in the prime broker is to audit the virtual machine portfolio itself. Another words, the prime broker will have many securities in a list with hashes and values but the casual observer will not be able to determine positions or originations.

The job function of the core investor group is to provide transparency and integrity to every user and auditor daily. Their job is not to enter or exit positions or to attempt to make money. Their job is to put the investors at ease knowing the custodial account has a constant state of value daily and the reports have integrity.

Virtual Machine:

The hedge fund virtual machine is a server side program, an entire financial system, capable of querying asset prices, analyzing asset prices, grouping positions, delivering reports, running contracts, emitting signals, executing financial functions, and more.

The virtual machines is comprised of a database layer, the orphan intelligence system, and the portfolio manager.

The database layer is broken into: Security Sync, Quote Retrieval, and Quote analyzer.

The Security Sync subscribes to an unlimited amount of data providers. Each data provider provides a geographical area, security type, symbol, greeks and quotes. The Sync will subscribe to the subscribers multiple times per day with a target goal of syncing all equity data to a state where it has one closing quote per symbol globally per day in the local SQL database. The quote retrieval system is capable of quickly retrieving a consolidated list of data for the OIS. The Quote analyzer is capable of consolidating synced data to make it easier for OIS to query higher level information (for example average price of the S&P DITM option over a 30 day time period).

The Portfolio manager implements the DAHF hedge fund programming language. This allows the Virtual Machine to interpret a portfolio script, analyze it, create result reports and transmit the response back to the portfolio manager. It also allows the virtual machine to persist and execute the DAHF script in a deterministic way, required for on chain security execution.

The OIS, Orphan Intelligence System, is the brain behind the virtual machine. This is the area of the VM that understands every secret quant piece of business logic learned by the commercial quants and hedge fund managers, that perform dividend capture, arbitrage, trending, settlement, etc. The OIS understands every strategy and position type, such as bear spread, bull spread, short box, long box, iron condor, double calendar, etc. The job of the OIS is to take a look at the execution range and script filters provided by the hedge fund script, and intelligently analyze the range for every possibility of profit. Then the OIS creates results summaries, rows of data with analysis results and sends it into caches. Using increasing intelligence levels, it re-analyzes the caches to consolidate more succinct and higher quality information. At this point the retrieval script may receive a consolidated reply, and successive calls will be faster, as the system grows its data store and cache. Therefore it will become faster and smarter over time.

Portfolio Managers:

The DAHF in production will not operate in production without honoring an input list of every decentralized portfolio created by competing portfolio managers. It is free to become a portfolio manager, you just enter an RPC command to register your fund and then you will work on creation of your hedge fund script using the hedge fund programming language we provide in the PDF.

Many portfolio managers will create competing portfolios in parallel. Their goal will not only be to provide Biblepay with the most profitable portfolios, but also in hopes to earn a percentage of the running portfolio's ROI. The portfolio manager will receive graduated returns, starting at 25% of the gross profit of the fund up to the break-level amount (approx. $1 million in profit) for portfolios executing positions in prod.

In order to get started, the hedge fund manager will first learn the DAHF programming language. Then they will create test scripts of actual portfolios and execute these scripts against testnet. Testnet gives the user access to the sanctuaries running the testnet hedge fund. (The testnet hedge fund will be exactly the same with real-live equity prices, and real-live ROI, but with fake testnet BBP and fake testnet BBP investments). This gives the PM the ability to create bona-fide portfolio scripts.

Once the PM decides he has something, he/she will issue an RPC command to place the script in prod.

Prod only executes opening trades from the top 5 portfolios, and executes closing trades from any portfolio with an open position.

Execution Engine:

During each block in prod, each sanctuary will execute a step for each of the portfolios active in prod, and therefore will receive execution signals depending on the current block number. For example, if 10 portfolios are active in prod, and portfolio 1-5 are deemed to be the top 5 portfolios (in respect to ROI per year, with portfolio 1 having a 100% yearly roi, and portfolio 5 having a 30% ROI), the core will listen to opening position signals from portfolios 1-5, but will only listen to closing position signals from 1-10.

Let us assume Portfolio 1s opening signal is: Sell SPY Bear Spread, Quantity 10, for a credit of $1.00 over a 2 strike range, with a 90 day duration. The execution engine will calculate the risk level allowed by portfolio 1 (Assuming it has a maximum exposure of 20%) and it will also calculate the maximum allowable single position risk (for example, no more than 1/365th of the capital divided by 5 active portfolios, possibly 1/1500th of the capital available for example) and let us assume that equals a quantity of 10. At this point the core would emit the sell signal of 10, for a credit of $1 X 10 = $20.00. The resulting options would be executed in the prime broker and the position would be held with its TXID in the prime broker, until the time where Portfolio 1s closing signal is activated.

Inflows and Outflows:

All inflows must be in BBP. Inflows are executed by creating a hedge fund account on-chain with an rpc command. Then BBP is sent to the internal hedge fund BBP address with a special command (this command marks the deposit as BBP owned by you). As the hedge fund NAV changes, your BBP value changes. When you request a dispersal the BBP value sent back to you is based on the current NAV (fund value) and current BBP value.

Outflows require a 30 day notice, to prevent hedge fund jumping. It is important that once the inflow is received, time is given to the fund to liquidate the bbp into the core, invest it in positions that may take a year to bear fruit, so therefore we implement this 30 day delay for outflows to allow the fund as a whole to operate efficiently.

All inflows sent to the holding account sit until a daily sweep occurs, where approx. half of the value is removed and converted into native currency for the custodial account. Then the resulting amount is held in custody with all other assets at the prime broker. An accounting entry will be created for audit trail purposes to show all inflows reconciling to amount in fiat, and corresponding amount in custody.


The Legal agreement will be structured so that the original seed capital founders in the core fund, being accredited have a legal right to start the hedge fund, and will be the representation for the relationship between the SEC and Biblepay. All assets held in custody at a registered prime broker will be related to positions authorized by the core group. The core will give authority to the biblepay virtual machine to execute trades on their behalf. The core will NOT manually execute any trades and will be prevented from doing so. Their only purpose is to provide seed capital, receive rewards for being the seed, provide prime broker facilities and transparency reports. Since authority will be given by them to the biblepay virtual machine, for executing security trades, the legality will be established. The chain itself will offer the ability for everyday end users to buy/sell the nav of the 501c3. The legal status must be determined in detail corresponding to in chain purchases and liquidations of the fund as a whole (by end users).

ROI for end user:

The end user benefits in most of the ROI, by receiving the net profit of the NAV of the fund after the core group deduction and the hedge fund manager deduction. Here is an example summary of ROI: Beginning of year, the fund started with a NAV of $1 million and 1000000 outstanding shares worth $1 each. At the end of the year, the NAV was $2 million (meaning the fund made a $1 million gross profit). $250,000 would be sent to the core investor group, $250,000 would be sent to the hedge fund managers leaving a $500,000 net profit. The fund now has $1,500,000 NAV, at which each share is now worth $1.50 (up from $1) for a 50% annualized net profit from the original invested capital in BBP.

RPC Commands:

An RPC command will exist to register yourself as a hedge fund manager, upload a hedge fund script, download hedge fund results, create yourself as a hedge fund investor, transmit BBP into the core hedge fund, request a hedge fund disbursement, check the value of the hedge fund, and more.Further reading here:<a href=""></a>