Protocol Specification
Aspire is a suite of financial tools in a protocol built on top of the gAsp blockchain and using the blockchain as a service for the reliable publication and time-stamping of its messages.
Explore: AspireAssets
Protocol Specification
Summary
Aspire is a suite of financial tools in a protocol built on top of the gAsp blockchain and using the blockchain as a service for the reliable publication and timestamping of its messages.
The reference implementation is aspire-lib, which is hosted at GitHub.
This document describes exclusively the latest version of the Aspire protocol.
Protocol Specification
Transactions
Aspire messages have the following components:
- Source addresses
- Destination addresses (optional)
- A quantity of GASP sent from the sources to the destinations, if it exists.
- A fee, in GASP, paid to the gAsp miners who include the transaction in a block.
- Some ‘data’, embedded in specially constructed transaction outputs.
Every gAsp transaction carrying an Aspire transaction has the following possible outputs:
- zero or more destination outputs,
- zero or more data outputs, and optional change outputs.
All data outputs follow all destination outputs. Change outputs (outputs after the last data output) have no significance.
For identification purposes, all Aspire transaction’s ‘data’ field is prefixed by the string ASPR, encoded in UTF‐8. This string is long enough that transactions with outputs containing pseudo‐random data cannot be mistaken for valid Aspire transactions. In testing (i.e. using the TESTCOIN Aspire network on any blockchain), this string is ‘XX’.
Aspire data may be stored in three different types of outputs, or in some combinations of those formats. All of the data is obfuscated by ARC4 encryption using the transaction identifier (TXID) of the first unspent transaction output (UTXO) as the encryption key.
Multi‐signature data outputs are one‐of‐three outputs where the first public key is that of the sender, so that the value of the output is redeemable, and the second two public keys encode the data, zero‐padded and prefixed with a length byte.
The data may also be stored in OP_RETURN outputs or as fake pubkeyhashes.
The existence of the destination outputs, and the significance of the size of the GASP fee and the GASP transacted, depend on the Aspire message type, which is determined by the four bytes in the data field that immediately follow the identification prefix. The rest of the data have a formatting specific to the message type, described in the source code.
The sources and destinations of an Aspire transaction are gAsp addresses, and may be either OP_CHECKSIG and OP_CHECKMULTISIGgAsp ScriptPubkeys.
All messages are parsed in order, one at a time, ignoring block boundaries.
Orders, bets, order matches, bet matches and rock‐paper‐scissor matches are expired at the end of blocks.
Protocol Specification
Non‐Aspire transactions
aspire-lib supports the construction of two kinds of transactions that are not themselves considered Aspire transactions:
- GASP sends
- GASP dividends to Aspire assets
Neither of these two transactions is constructed with a data field.
Protocol Specification
mempool transactions
Always have block index = 9999999 (config.MEMPOOL_BLOCK_INDEX).
DB changes never persist across sessions.
Protocol Specification
Assets
All assets except GASP and ASP have the following properties:
- Asset name
- Asset ID
- Description
- Divisiblity
- Callability
- Call date (if callable)
- may be delayed with later issuances
- Call price (if callable) (non‐negative)
- may be increased with later issuances
Newly registered asset names will be either (unique) strings of 4 to 12 uppercase Latin characters (inclusive) not beginning with ‘A’, or integers between 26^12 + 1 and 256^8 (inclusive), prefixed with ‘A’. Alphabetic asset names will carry a one‐time issuance fee of 10 ASP and numeric asset names will be freely available. ‘GASP’ and ‘ASP’ are the only three‐character asset names. Example asset names: BBBB, BACON, A100000000000000000.
Assets may be either divisible or indivisible, and divisible assets are divisible to eight decimal places. Assets also come with descriptions, which may be up to 52 single-byte characters long and updated at any time.
Protocol Specification
Subassets
- Subasset names must meet following requirements :
- Begin with the parent asset name followed by a period (.)
- Contain at least 1 character following the parent asset name and a period (.) (e.g. PIZZA.x)
- Contain up to 250 characters in length including the parent asset name (e.g. PIZZA.REALLY-long-VALID-Subasset-NAME)
- Contain only characters
a-zA-Z0-9.-_@! - Cannot end with a period (.)
- Cannot contain multiple consecutive periods (..)
- A subasset may only be issued from the same address that owns the parent asset at the time of the issuance
- A subasset may be transferred to a new owner address after initial issuance
- A subasset has an issuance cost of 10 ASP
Protocol Specification
Memos
A Memo can be attached to a send transactions. When a shared public address is used for incoming transactions, a memo may be used to link an incoming payments with a specific user account identifier or invoice. Memos do not need to be unique. Multiple sends may have the same memo.
The Memo is a numeric value expressed in hexadecimal or a UTF-8 encoded text string. Valid memos are no more than 34 bytes long.
Protocol Specification
Transaction Statuses
Offers (i.e. orders and bets) are given a status filled when theirgive_remaining, get_remaining, wager_remaining,counterwager_remaining, fee_provided_remaining orfee_required_remaining are no longer positive quantities.
Because order matches pending GASP payment may be expired, orders involving GASP cannot be filled, but remain always with a status open.
Protocol Specification
Message Types
- Send
- GASPPay
- Issue
- Broadcast
- Dividend
- Cancel
Send
A send message sends a quantity of any Aspire asset from the source address to the destination address. If the sender does not hold a sufficient quantity of that asset at the time that the send message is parsed (in the sequence of transactions), then the send is considered an oversend.
Oversends are handled as follows:
1) Oversends using the legacy send transaction type are valid and filled as much as they can be 2) Oversends using the new default enhanced send transaction type after block 489956 are invalid and none of the asset is sent
aspire-lib supports sending GASP, for which no data output is used.
Issue
Assets are issued with the issuance message type: the user picks a name and a quantity, and the protocol credits his address accordingly. The asset name must either be unique or be one previously issued by the same address. When re‐issuing an asset, that is, issuing more of an already‐issued asset, the divisibilities and the issuing address must match.
The rights to issue assets under a given name may be transferred to any other address.
Assets may be locked irreversibly against the issuance of further quantities and guaranteeing its holders against its inflation. To lock an asset, set the description to ‘LOCK’ (case‐insensitive).
Issuances of any non‐zero quantity, that is, issuances which do not merely change, e.g., the description of the asset, involve a debit of 10 ASP.
Asset descriptions in enhanced asset information schema may be of arbitrary length.
Broadcast
A broadcast message publishes textual and numerical information, along with a timestamp, as part of a series of broadcasts called a ‘feed’. One feed is associated with one address: any broadcast from a given address is part of that address’s feed. The timestamps of a feed must increase monotonically.
Bets are made on the numerical values in a feed, which values may be the prices of a currency, or parts of a code for describing discrete possible outcomes of a future event, for example. One might describe such a code with a text like, ‘US QE on 2014-01-01: dec=1, const=2, inc=3’ and announce the results with ‘US QE on 2014-01-01: decrease!’ and a value of 1.
The publishing of a single broadcast with a textual message equal to ‘LOCK’ (case‐insensitive) locks the feed, and prevents it both from being the source of any further broadcasts and from being the subject of any new bets. (If a feed is locked while there are open bets or unsettled bet matches that refer to it, then those bets and bet matches will expire harmlessly.)
The text field may be of arbitrary length.
A feed is identified by the address which publishes it.
Broadcasts with a value of -2 cancel all open bets on the feed. Broadcasts with a value of -3 cancel all pending bet matches on the feed. (This is equivalent to waiting for two weeks after the deadline.) Broadcasts with any other negative value are ignored for the purpose of bet settlement, but they still update the last broadcast time.
Dividend
A dividend payment is a payment of some quantity of any Aspire asset (including GASP) to every holder of a an asset (except GASP or ASP) in proportion to the size of their holdings. Dividend‐yielding assets may be either divisible or indivisible. A dividend payment to any asset may originate from any address. The asset for dividend payments and the assets whose holders receive the payments may be the same. gAsp dividend payments do not employ the Aspire protocol and so are larger and more expensive (in fees) than all other dividend payments.
- TODO: dividends on escrowed funds
There is a small anti-spam fee of 0.0002 ASP per recipient with dividends.
Cancel
Open offers may be cancelled, which cancellation is irrevocable.
A cancel message contains only the hash of the gAsp transaction that contains the order or bet to be cancelled. Only the address which made an offer may cancel it.
Destroy
A destroy message sends a quantity of any Aspire asset from the source address to the default burn address. If the sender does not hold a sufficient quantity of that asset at the time that the destroy message is parsed (in the sequence of transactions), then the destroy is considered invalid.