Dynamic Binding at Transaction Time

One way to look at ‘coupling’ is the relationship that a transaction record implies between transactors. For example, the use of community currency implies membership in the same community or in communities that have an agreement in place to accept each other’s currency. In Ripple, direct transactions occur only if the transactors have preset limits with each other and payments have to be routed through pre-established accounts. These requirements may be viewed as ‘static binding’ or predetermined configurations to set limits on who could trade with whom.

In the case of mutual credit community currencies, it is not hard to see similarities with the pre-WWW philosophy that hyperlinks are to be made and maintained through a centralized database. A requirement that transactors must have an account with the same mutual credit accounting system highlights this similarity. But the similarity extends beyond considerations of ledger boundaries and into logical or abstract rules for initializing who could trade with whom. As long as the ability to transact requires a predetermined relationship, the ‘localized hyperlinks’ mindset applies even if the accounts were maintained in separate servers or accounting systems.

Under tyaga.org’s implementation scenarios, a transaction does not automatically imply that the transactors are members of the same community or that they have established credit limits with each other prior to the transaction. Anyone could potentially trade with anyone else. It is up to a potential recipient to accept or reject a currency brand at the time of transaction – essentially, the concept of dynamic or late binding as applied to a currency system design. This is similar to the WWW philosophy of allowing any web page to link to another page at-large, which is a less-controlled way of doing things but inherently more flexible and scalable. Even though mutual consent is required for an inter-entity transaction, such consent is only applicable to one instance of payment and does not imply past or future guarantees of currency brand acceptability between two brands.

Loose coupling, as described in a previous post, is expected to lower the barrier of setting up new currency brands, leading to more spontaneous currency brand creation (i.e., more ‘new web sites’ in the current analogy). Dynamic binding, as described in this post, is expected to lead to more diverse market selections and higher frequencies of inter-entity transactions (i.e., more ‘interdomain links’.)

As with all design trade-offs, however, there is a price to pay for such high expectations. Tyaga.org’s design approach for achieving flexibility and scalability comes at a substantial cost of stricter reporting requirements and greater dependence on service providers to make make sense of huge volumes of transaction data. The challenges of reconcilable reports, auditors and currency brand indices arise since each entity is allowed and encouraged to set its own currency limits as budgets, without having to predetermine transaction boundaries or specific entities as revenue sources.