Lighting Network payment channels could be established between users and exchanges to speed the transfer of funds.
This would be a huge boon, moving many on-chain deposit and withdrawal transactions off-chain, but is possibly only the beginning.
Since Lightning Network payments can span different blockchains, an exchange could use a cross-chain Lightning node to expose its internal order book to external entities.
As an example, imagine that an exchange has an LTC/BTC trading pair and wants to allow non-exchange users to fill the orders in their order book.
The exchange runs a lightning node with a BTC channel and an LTC channel:
x: exchange node
a: third party node
b: third party node
<->: payment channel
a <---> x <---> b
The exchange dynamically sets the exchange rates across the channels based on their current best bid, best ask, and fee schedule.
With a best ask of 0.6 and a 1% fee, the exchange sets the BTC→LTC exchange rate like so:
a ----> x ----> b
When a payment is routed across the channels in this direction, LTC sell orders are filled.
With a best bid of 0.4 and a 1% fee, the exchange sets the exchange rate on the channel in the LTC→BTC direction like so:
a <---- x <---- b
A payment routed in this direction fills LTC buy orders.
In this way, exchanges can expose their internal order book externally and trustlessly. Anyone who wishes to make cross-chain Lightning Network payments will discover and travel over these routes with no special effort required by the exchange, assuming that their rates are competitive. Also, it’s likely that third parties will appear whose sole purpose is to search the Lightning Network for arbitrage loops and travel them until they are exhausted, thus bridging multiple exchanges when their order books cross.
exchange traded mutant
VXX is a dangerous chimeric creature; it is structured like a bond, trades like a stock, follows VIX futures and decays like an option. Handle with care.
And, currently being algo traded by a program written in Excel VBA.
Strange days indeed.
Investing in cryptocurrencies is not the same as buying
simple equity in a company.
Although each company has a different business model, they and the equity they issue are largely structurally homogeneous. They hold their monies in banks, pay for their expenses with wire transfers and cheques, follow prescribed rules of accounting, and issue stock that operates according to well understood rules. This is not to say that said practices are good or bad. They are simply a known factor.
Cryptocurrencies and tokens, however, are structurally heterogeneous. They have different codebases, modes of operation, levels of complexity, and security models. Although broadly lumped into the same category, they can, by the nature of these differences, have almost nothing in common.
Investing in one is like buying stock in a company with novel business models, banking practices, and accounting methods, and furthermore whose stock is issued under a bespoke scheme and follows unique trading rules.
Accordingly, a much, much greater level of care is required when making such investments. If any one of these novel mechanisms fail, your investment may go up in billowing smoke and flames overnight.
This is not to say that you should completely avoid cryptocurrencies and tokens, just, you know, do your homework.
I only program in PL/I because I'm BASED.
Programs first crawled from the murky oceans as simple lists of instructions that executed in sequence. From these humble beginnings they have since evolved an astonishing number of ways of delinearizing.
In fact, most programming paradigms simply amount to different ways to transform a linear source file into a program with nonlinear behavior.
- gotos that unconditionally jump to another point in the program
- an abort instruction that stops the program at some point other than the end
- a macro facility that substitutes one instruction for one or more other instructions
- a source file concatenation facility that concatenates multiple source files
- an include directive that is substituted for the contents of a source file
- structured repetition and selection, a la for, while, if, and switch
- subroutines and functions
- array oriented programming that replace explicit repetition with implicit repetition
- first class functions which delegation of behavior to the caller
- object oriented programming with dynamic dispatch, which allow the runtime type of an object to determine which instructions to execute
- aspect oriented programming, pattern matching against the structure of the call stack to execute instructions when functions are called or return
- event driven programming, executing instructions in response to external events
- declarative programming, which essentially delegates execution of one program to another
Parse structure from the languageless void.