Funtracker.site Bank has begun preliminary design of a derivative market run from within stellar.org networks integrated trade system.
It’s time our dreams become your reality.
I have been asked now by a few people and from some of our friends in NYC that have been asking me about the possibilities of setting up a derivative market on the stellar.net internal trading market. I think this could be huge with the present market of derivatives now at an estimated 1.2 Quadrillion USD in capitalized market value. If we just get involved in 0.001% of that market it would still be huuuge. So with my contacts interest and the known world capitalization in this market it seems like a no brainer.
Before I get into details about what would be different about trading derivatives on stellar.org net, you best know what derivatives are. In short: “The derivatives market is the financial market for derivatives, financial instruments like futures contracts or options, which are derived from other forms of assets. The market can be divided into two, that for exchange-traded derivatives and that for over-the-counter derivatives.”. To get more details on derivatives see https://en.wikipedia.org/wiki/Derivatives_market
The first problem I see is what systems would be required to enforce the outcome of derivative contracts. This is where my imagination steps in and sees a quorum of enforcement robots that monitor the base asset prices within the derivative and sign off on payments at the end of a contract to the winners and loosers of the contract.
Also the bots would be required to force liquidation in the event that the escrowed funds fall bellow the threshold limits for a margin call.
I foresee to start there would be a minimum of 3 robots that a minimum of 2 of the 3 bots would have to sign off on final contract payments. The bots would not be controlled by a single entity, it would be setup much like stellar.org in an uncentalized manner so that cheating by a single entity would not be possible.
In early stage of the prototype that will be running on testnet we can setup with a single bot to start first phase of testing and debuging of the project.
The same tools used to buy and sell assets like currency that already exist on stellar.org can be used to buy and sell the issued derivative assets. The main difference is that the asset would become worthless to buy after the expire date of the contract. The holders on record at the end of the contract would auto receive the final outcome of the contract if it ended at any positive value that would be sent to the same account that holds the contract issue. The account would also have to be setup with trust in the asset that it hopes to receive.
The way I see it participants that are selling contracts would have to put up a deposit of funds that would be locked in a multi-signature account with the signers being the team of robots. The asset within the escrowed account could be most any decided holding asset for the escrow but I assume it would be the base asset of the asset pair involved in the contract. The amount of this deposit is a big unknown for me as it is dependent on the volatility of the asset that the derivative is tied to and the volatility of the asset within the holding escrow. For this number we will need some experts to step in that can inform us on how to estimate these amounts.
Also the amount in escrowed accounts will be transparent in the stellar.org ledgers to the buyers so the buyers can also decide on what they are willing to risk with the amount seen in the escrowed accounts along with the outstanding contracts already floating in the open market on this contract also visible in the stellar.org ledgers.
I'm not sure about this one as it would be much more complex to even know how close a group of contracts were from becoming insolvent. If this could be done it might require less escrowed funds to create a group of contracts that might be working against each other like pairs of put call on an asset. Maybe just limit multi to put call on the same asset at some point and later expand on methods to track entire portfolios or at least all linked to a single asset on an account to verify liquidity.
I guess so but they will all go insolvent at the same time I would assume or am I wrong. maybe the added funds from more than one issue seller would add liquidity? I think I would have to run some spread sheet simulations on this to verify at some point.
I'm guessing someone will have to pay for the team of trust bots to perform there services of monitoring and signing of contracts. The final contract distribution would have some amount of the funds diverted to each of the team of bots involved in the contract. This might be in some small percentage of the net of the contract block or a fixed fee for each contract. There is also no reason there can't be more than one team of bots that can compete on prices charged for services rendered. The choice may also depend on what group of bots are most trusted on the net at the time. Their reliability records and such also would be a part or what the market would be willing to pay the trust bot group.
Not really sure about this as we have only 12 letters to play with in stellar.org as far as an asset name.
This is the method symbols used in USA and Canada option markets: The OCC option symbol consists of 4 parts:
Root symbol of the underlying stock or ETF, padded with spaces to 6 characters Expiration date, 6 digits in the format yymmdd Option type, either P or C, for put or call Strike price, as the price x 1000, front padded with 0s to 8 digits
Examples:
SPX 141122P00019500
This symbol represents a put on SPX, expiring on 11/22/2014, with a strike price of $19.50.
LAMR 150117C00052500
This symbol represents a call on LAMR, expiring on 1/17/2015, with a strike price of $52.50.
As you can see this symbol method would require a bit more than 12 letters in fact at times more than 20 letters would be needed. Also there underlying symbols in the example like SPX are limited to assets seen on the NYSE and maybe NASDAQ. We need even more flexibility with internal assets within stellar and outside markets as well. We also have use of more possible digits in stellar with 7 digits past decimal to play with in our price system.
One possible way would be to just point at the escrow account within the asset name with a short header of something like OPC_ or OPP_ symbolizing Option Call and Option Put with the rest being the escrow account for example: OPC_GDUP4D were GDUP4D…. would be the escrow account within stellar.org net. inside the escrow accounts data fields we could fill in more detailed info as to what the option was were I think we have 22 chars per field with as many as we want at a cost of 10 XLM to hold each added field. At the end of the contract the escrow will be distroyed so holding data fields cost is not much and is recovered for use in the next contracts.
Inside the fields of the escrow I see us using 2 of the 22 char data fields with the first being much the same as they use in OCC option symbol with maybe added 2 digits for more accuracy in strike price if we want like: USD 150117C0000525001 This symbol represents a call on USD, expiring on 1/17/2015, with a strike price of $52.5001 In this first data field the USD is just a short version of the asset, the full version of what the asset points at would be in the second field where we have 22 more chars to play with so in this case the USD is a USD asset within stellar.org so we would see: USD:GATE…. with GATE… being 8 or more of the first letters of the stellar issuer for this USD asset. it could also be IBM:NYSE or MSFT:NASDAQ if it was to be an asset of IBM on the NYSE exchange or Microsoft on the NASDAQ exchange. So with a format like this we can have unlimited coverage of all the international equity and commodity markets.
The bots responsible for the escrow can also be seen as the signers of the escrow fund so the buyer has access to all the info they might need as far as I know so far.
It would not be very complex. just some boxes to fill in that would include: the asset/issuer or asset:market of the intended derivative, the expire date of the contract, Put or Call select, The strike price, premium price desired, The number of blocks of shares in the contract (100 shares per block same as other markets or maybe added mini blocks of 10 like we have on some other select markets), and the base asset/issuer of what the contract is escrowed in and finally paid out in but valued at contract expire to worth in the derivative asset.
When the data is filled in the website would calculate what was needed as a deposit on the contract. The seller would then send the funds to the newly created escrow account that is pre setup with proper signers of the designated signer bots. There may be some added info in the memo for the the site to better track sellers and buyers of contracts.
I would assume that if a contract was issued to be sold but never purchased that the seller should be able to cancel the remaining unsold issues and recover some unused parts of the escrow at any time before the contract expires.
Note that the first buyers of the contracts from the market issuer, the premiums would be applied to the escrow account of that option.
Later resale or trade of the already purchased contracts would be transfered directly between present holder of the option asset and buyer.
Did I forget anything?
I should note that in this case we expected the asset of the derivative to be an asset within the stellar.net market, but in reality the derivative asset could point outside stellar market from feeds from the NYSE, NASDAQ, commodities or most any other world market or event that the bots can monitor. Over time different groups of bots will have the ability to monitor different feeds even beyond our present imagination.
The bots can be written in more than one language but to start I think the first will be in JavaScript nodejs. There may also be one written first or second in ruby as we already have some tools written in ruby for bots that are already running on the stellar.org net in a similar nature. One thing for sure I feel the bots code should be open source on all of them and they need to all work together as one.
I have to admit this project may be above me to complete myself and I am asking for help on this one as I have asked before on many of my other projects with little success in the past of getting little or any.
I think to start we need feedback and more ideas about the design and the problems that I have not yet foreseen before we can even begin to start to code up a proof-of-concept on each of the parts needed.
Funding would also help if someone doesn't have the skills or knowledge to help but has funds to contribute to the project that would help us get some expert consultants and programmers to step in and help to expedite it's completion. If you want to contribute funds you can contact the Funtracker.site Bank Manager or sacarlson at https://chat.funtracker.site/channel/bank for details. I estimate it will take 6 months to 1 year or more after coding begins to complete a proof-of-concept without much help.