Category: Comparisons

Prowl Updates

I have tried to catch up with some Prowl related updates, most of which have been in places other than the discussion group. So I just took the liberty of copying and pasting excerpts to help consolidate previously scattered discussions in one place. I also included some email excerpts that I thought might be interesting to others. Please feel free to ask questions or post comments that will help clarify not just Prowl, but the whole currency design.

I have to admit that I was surprised to find, in another site, the same core ideas expressed in here and — traceability, accountability, transparency, auditability, even certain implementation aspects, repeated within the same context albeit in fancier words. The surprise mostly came with disappointment that while there was some mention of Twollars as an inspiration, apparently Prowl’s earlier announced release and demo failed to spark the same insights that I have been expounding and struggling to embody for a long time now.

But I’ll remain committed to openly discussing updates, example codes and potential strategies, which others are encouraged to build upon or tweak as necessary. There are many opportunities to develop your own designs on the evolving Prowl-like currency services that are sure to come within this year. I would especially like to see designs that cater to unsophisticated user groups – that’s a key aspect that people often forget.

Interoperability and Configurability

Would it be possible to reconcile the fundamental differences between the following two approaches:

“Currency designed for transactions between members of independent entities or brands”


“Currency designed for transactions between members of the same entity or community”

My doubts have resurfaced after reading some recent online discussions related to currency information systems. At issue is the importance of interoperability between different currency entities as supported by adhoc service providers.

With community-oriented currencies,  the expectation is for the majority of transactions to occur between members of the same currency entity, so the administrative system of one currency does not have to worry about understanding information from another currency system. This obviously has the advantage of freeing each currency issuer to configure their currency and transaction grammar as needed, without worrying about what other issuers are doing.

In contrast, expects that separation of concerns and scalability would inevitably lead to a majority of transactions occuring between members of different currency entities. Where each entity specializes in serving a particular market need, access to product diversity is only possible through interentity trades. Each entity could still configure currency settings and use proprietary messaging/record formats. However, the need for publishing and reporting conventions is going to be unavoidable under a scenario of global interentity transactions.

It was interoperability concerns that led to the development of Prowl as a potential starting point for discussing uniform representation and standardized accounting terms, while still allowing for variations in parameters and calculation specifications. Without interoperability, it would not be possible to achieve traceable and auditable currency brands.

Market Specialization, aka Self-Determined Obligation/Duty

One of the key differences between satconomy and other ledger-based currency systems arises from the concept of ‘obligations’. In other posts, I have used the term ‘debits’ as a quantification of obligation, and I’ll continue that usage here.

In Ripple, debits represent the obligation of a participant to the neighbor node that it used as a payment intermediary. It doesn’t matter in this analysis whether or not there is an actual manual settlement of ‘debts’. The main point here is that the obligation arises as a result of a market transaction, or what some alternative currency proponents refer to as property transfer.

In LETS, obligation also arise from a market transaction. The difference with Ripple is that the debits are owed towards the whole community, and anyone that belongs to that community may cause a member to accrue debits or cancel it through a market transaction. In contrast, Ripple credit-debit issuance and cancellation are specific to neighboring nodes.

In satconomy, obligations arise even before any market transactions take place and without prior contractual arrangements. Even before an entity’s obligations are quantified as debits, the obligation is already there, qualified as mission statements or organizational goals. Debits are declared as soon as an entity issues equivalent credits for member contributions towards its goals.  Again, no market transaction precipitated the recording of new credits and debits, or at least it would be absurd to call the process of product creation as a case of ‘property transfer’, when technically the credit issuer and recipient within the entity end up becoming co-trustees of the entity’s product inventory and debit account. 

In satconomy, debits represent the quantification of an entity’s obligation to the market as a whole. Not because other market participants have necessarily made any demands on the currency issuing entity, but simply because that entity has made it an obligation to specialize in delivering certain goods or services to the market. There’s nothing new in this concept of ‘self-determined duty’, entrepreneurs are always trying to research and develop new product offerings all the time without explicit prompting from the market.

But someone might argue, how could a currency issuing entity cancel its self-accrued debits when it owes no one in particular? By selling its products to other entities that it perceives as engaging in sustainable market activities. All that happens in a satconomic market transaction is the cancellation of equivalent credits and debits (quantified obligations and contributions). No new ledger entries are recorded out of expectations for future reciprocity in a market transaction.

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.

Comparison to Mutual Credit Systems

The following implementation scenario might help explain satconomy to those who are familiar with LETS, TimeDollar or mutual credit type systems:

Suppose that instead of individual trading accounts, members decided to organize into unit entities within a trading community or market. The unit entities would be known within the community by its brand. Each entity does not need to trade with other entities or borrow from others in order to issue currency. Instead, if an entity member has made a perceived contribution to the entity’s goals, then that member is awarded credits and the entity accrues the corresponding amount of debits. The amount of currency or credit-debit pairs that an entity could issue is self-determined within the entity – for example, by a supervisor, manager and other positions of authority that monitors the level of member contribution to its goals.

The member who earns the credits can then spend it on products in the market, or more rarely, redeem it for the products of the entity if those are not already provided as benefits to the members. Currency is intended primarily to be used outside the issuing entity. When the entity is able to benefit someone with its products, goods and services, its debits are cancelled together with an equal amount of the beneficiary’s credits.

In other words, satconomy may be implemented as a mutual-credit community where the members organize into unit entities, each with a declared market specialization. Currency is issued within an entity as credit-debit pairs, which translates to an entity account that has both credit and debit balances as opposed to a single net balance. Only the entity by itself could increase its balance amounts, and those balances have to increase by the same amount at the time of currency issuance. Finally, credits may only be used to cancel debits that are already existing. 

Comparison to Stock or Bond Issuing Entities

Unit entities in satconomy have operational similarities with publicly held corporations, which issues shareholder stocks, and municipal governments, which issues bonds. However, there are important differences:

(1) Instead of quantitatively symbolizing the status of an owner as a shareholder or a lender as a bond holder, credits in satconomy are awarded based on the recipient’s perceived contribution to the entity’s goal or mission. 

(2) An entity may issue any amount of its currency according to its self-determined limits, as long as the currency is issued as credit-debit pairs. That is, for each self-determined unit increase in the entity’s credits, its absolute debit quantity must also increase by an equal amount.

(3) The credits are intended, but not guaranteed, to be redeemable into products of the market in general. Redeemability is not specifically limited to the products of the issuer.

(4) When the credits are redeemed for products in the market, the credits are cancelled together with an equal quantity of the product provider’s debits. There is no reusable currency transfer between entities. Each entity does not need to acquire currency from other entities since an enity could independently issue its own brand of currency.

For added emphasis, it is worth repeating that there are no guarantees that credits could be redeemed for products in the market, or that the debits of the entity would be cancelled eventually as a symbol of fulfilling its self-determined obligation to the market.