Tagged: Ripple

Implementation Analogies: Boundaries, Bridges and Towers

To illustrate the overall implementation strategy in satconomy, it is worth comparing and contrasting it with the strategies that could be inferred from mutual credit and Ripple currency systems.

The implementation strategy in mutual credit currencies might be likened to building boundaries. Members are allowed inside the boundary and could trade with one another, while non-members are invited to join this mutually beneficial community relationship where the currency stays within common boundaries. Satconomy is not concerned with erecting community boundaries where the members trade with one another. Rather, satconomy promotes the creation of entity boundaries where members work with one another to provide products to the market in general. Entity-issued credits and products, rather than being restricted from flowing outside each entity’s ‘boundaries’, are meant to flow between entities in open market transactions.

The implementation strategy in Ripple might be likened to building bridges between nodes or islands of market participants. The unique payment routing feature in Ripple is intentionally restrictive in that only the directly connected participants are allowed to cross the bridge between them. If participant A does not have a direct bridge to the island of participant C, but B has direct but separate bridges to both A and C, then Ripple enables a transaction by requiring an IOU to ‘cross’ from A to B and a separate IOU to ‘cross’ from B to C. In this sense, B acts as an indirect relay person that converts the payment between A and C. Participant A’s payment does not reach C directly. In satconomy, there is always a direct payment between market transactors, causing the immediate cancellation of credits and debits between the involved entities. In contrast to how Ripple offers a manual settlement option for the cancellation of credit-debits pairs after a market transaction, satconomy requires an automatic cancellation-settlement of credit-debit pairs at the completion of the transaction itself.

The implementation strategy in satconomy might be likened to building towers, through which market participants could assess the value that each entity brings to the market. If an entity is deemed to provide benefit to the market, then the currency brand that it issues would be perceived as acceptable in a transaction. If the news or perspective from the ‘tower’ is not favorable towards a certain entity, then its currency brand would also lose favor in the market. In an effective implementation of satconomy, this metaphorical ‘tower’ facilitates access to highly transparent, up-to-date and verifiable information about market activities, entity account reports and analyst opinions.

Comparison to the Ripple Framework

Satconomy may be implemented in Ripple using the basic structure of binodal accounts. Each entity may be visualized as a cluster of nodes that revolve around a brand node or, for clarity of illustration, around unidirectional accounts formed between an entity’s pair of brand nodes. One of the brand nodes acts as an external interface to nodes that are outside of the entity, and the other as an internal interface to cluster member nodes. The brand account may be envisioned as forming the anatomical neck of the cluster. (Click on thumb size illustrations to view image file.)

Entity ClusterEntity Account

The member nodes hope to gain access to the market through the entity’s brand nodes. The internal brand node grants credits, which are essentially usable currency, to the individual member nodes, resulting in numerous entity accounts. The brand account limits the ‘flow’ of credits into and out of the entity though the following mechanism:

(1) The internal node assigns a credit limit to the external node, which limits the amount of ‘currency’ that could ‘flow’ out of the entity. This is functionally equivalent to an entity’s self-determined spendable credit limit or a currency outflow limit.

Outflow Limit


(2) The external node assigns a credit limit to the internal node, which limits the amount of ‘currency’ that could flow into the entity. This is functionally equivalent to an entity’s self-determined debit cancellation limit, i.e., as soon as all the entity’s debits have been cancelled thorugh the receipt of credits from the market, currency inflow is prevented.

Inflow Limit

The next features are modifications to the standard Ripple protocol.

(3) In satconomy, each unit increase to the currency outflow limit must result in a corresponding unit increase in the inflow limit. This would be the Ripple equivalent of the intra-entity currency issuance of credit-debit pairs. It is important to emphasize that the preassigned values to outflow and inflow limits dynamically change with currency issuance and use.

Currency Issuance


(4) In satconomy, currency outflow results in the dynamic decrease of the pre-assigned outflow limit. This dynamic decrease is NOT equivalent to the calculated relative value of used credits versus a nonchanging pre-assigned credit limit, but rather, the actual preassigned limit changes. Similarly, currency inflow results in the dynamic decrease of the pre-assigned inflow limit.

Currency Cancellation




(5) In satconomy, credit-debit cancellation between entities would be functionally equivalent to a Ripple autosettlement feature, if such a feature were to exist. Ripple offers a manual settlement option for the cancellation of the debt between creditor and debtors, which results in the restoration of the usable credit limit to the preassigned value. In contrast, there is no manual settlement option in satconomy:  An autosettlement feature is enforced wherein an entity-declared debt to the market is cancelled by the credits of consenting market participants. An entity’s debt is reduced through the provision of its product to market participants who redeem their credits against the market in general (and not simply against the credit issuer.) A satconomic market transaction does not result in a new record of redeemable credits, but results in its opposite – the destruction of redeemable credits together with an equivalent amount of pre-existing debits.

Manual vs. Automatic Settlement

(6) Since an autosettlement feature does not result in records of indebtedness, the inter-entity payment routing feature in Ripple becomes a nonbinding trust routing feature in satconomy. If a path of trust could be found to link unacquainted market participants, then the seller might choose to directly accept the buyer’s offer of credits (to be used for cancelling the seller’s debits). If no such path is found, the seller might choose to reject the buyer’s credits, or might still choose to accept the buyer’s credits anyway. There is no need for payment intermediaries in satconomy, but there will be a major need for trustworthy intermediaries, such as market analysts and advocacy groups, in verifying an entity’s currency brand qualities. A trust path might be indirect, but payments are always directly made between the market transactors in satconomy.