Age and Maturity counters on balances & transactions

Discussion space for community admins

Moderators: hugo, alexandre, rmvanarkel

Post Reply
Mathiaskei
Posts: 31
Joined: Wed Nov 21, 2012 8:36 am

Age and Maturity counters on balances & transactions

Post by Mathiaskei » Fri May 16, 2014 3:42 pm

Hi Everyone using C4C. I have just received a newsletter from Cyclos informing me of new exciting features of C4C version 4.1. Among the features I noted is the "Age and Maturity counters on balances & transactions (optional)". I got this optional function when was configuring my currencies. What exactly does it mean so that I can utilize my Cyclos instance to the maximum. Please help!

Kind regards,
Dr Katura Mathias Malilah
Arusha, Tanzania

cycloshost
Posts: 578
Joined: Mon Jan 30, 2012 8:12 am
Contact:

Re: Age and Maturity counters on balances & transactions

Post by cycloshost » Mon May 19, 2014 4:25 am

We also have this doubt, is there a further explanation in the Wiki? We activated the aging but could not see anything on the user balances/listings.
cycloshost.com
Cyclos administration and hosting

admin
Site Admin
Posts: 1413
Joined: Mon Jan 24, 2005 10:31 am

Re: Age and Maturity counters on balances & transactions

Post by admin » Mon May 19, 2014 2:41 pm

Hi,

The rates features, although working, are still much in development. At this moment we cannot give detailed information.
The working of the rates is relatively straightforward.
Here is a general explication:
Rates are counters which are build in in the currency and are applied for any amount or transaction within the currency. The rate counters can give interesting information about a system and about individual accounts. The rates are expressed in days and count either the number of days since creation (age counter, A-rate), or the number of days still left until a loan expires (loan counter, D-rate). It is possible to apply fees based on the counters using a fee extension. In a rate enabled currency each transaction and each account balance will have a rate, which the administrator can view, and optionally the user as well. The rate of an account balance is the average rate of all transactions that make up the account balance. When a payment occurs the counter values will be recalculated for both source and destination account.
[edit] A-rate (aging)

The A of the A-rate stands for 'Age', meaning that it represents the time since the Units were created. When Units are created the A-rate value is 0 (zero) by definition. This is not editable via the user interface. The A rate simply increments with the time. For example if you have an account balance of 100 Units and the A-rate is 40, and you look ten days later it will be 50 (provided that no transactions occurred during those 10 days). The amount does not matter as the balance is aging as a whole. When you pay another person (withing the same currency) than the amount does matter and will affect the result. Continuing the above example, if you now pay the 100 Units to a user that has 10 Units on his account that have an A-rate of 100, your amount will have more weight in the end result, being the new A-rate at the balance of the receiver. The aging rate of the account balance of the person you paid might be higher, but the amount of the payment is also taking in account when a transaction is done.
[edit] D-rate (diminishing)

Like the A-rate the D-rate a also a time' counter, but contrary to the a-rate the d-rate does not increment but decrements (diminishes) over time. This means obviously that it will need to have an initial (time) value. This initial value is a number of days that is defined in a transaction type (available only for transaction types within a currency that has the d-rate enabled). This transaction type is typically a loan. Like the a-rate the d-rate is also originated on Unit creation (payment from an unlimited system account, mostly the only system account that is allow to go negative). The given d-rate will be the number of days that the (loan) amount will need to be paid back in conventional currency. Therefore the D rate is also referred to as the 'maturity counter'.

With the D-rate you can know for any balance in the system in what extend it is 'backed' by conventional money. For example, if a user has 100 with a d-rate of 20 it means that in 20 days the d-rate on the balance will be zero. Subsequently the 100 Units will be available as cash (conventional money). Of course there is the issue of users that default on their loans (non-payers). The organization needs to handle this just as any bank or financial institution. Usually with guaranty funds or assurances. This does not interfere in the calculations.

If somebody has a d-rate it means this person cannot convert the Units to conventional money directly. This because it is not available yet in cash. He would have to wait for the D-rate to be zero. To be able for user to convert at any time a fee can be charged. This fee should cover the costs that the organization will make to pay the interest of a loan (in the conventional financial market). With this loan the organization can pay out the 'early converter' while the whole system remains fully backed. When the money does come (in 20 days) the organization can pay back the loan to the financial institution that gave the (money) loan.

The possibility for users to be able to convert at all times, and having a fully backed system (with conventional currency) are two very imported elements that most complementary currency systems lack. Complementary currency systems limited convertibility. At one hand this is an incentive of local spending, but at the other hand very hard defining values.

An advantage of a Rate system is that the early converters are charged proportionally to the d-rate of the amount the convert. The conversion fee will be higher for 'newer' Units. This results in a natural incentive for older Units what will increase the 'term roder'. As users can view the d-rate (of their balances, and incoming/outgoing transactions) there will be a preference for 'older' Units. As the older Units are being used for trade the newer Units will be more suitable for savings, and will age automatically.

Rules D-rate

It is possible to overrule the default creation value (which is set on the currency, as with any rate) on the transfer type.
For now, creation values can only be set on transfer types from unlimited accounts to limited accounts, as these are the typical transfer types via which unit creation takes place.

Mathiaskei
Posts: 31
Joined: Wed Nov 21, 2012 8:36 am

Re: Age and Maturity counters on balances & transactions

Post by Mathiaskei » Tue May 20, 2014 2:34 pm

Thank you Admin for your explanation of Age & Maturity counters functionality. I am sure "Cycloshost.com" should also benefit from that explanation. But the functionality seems to be complex. I promise will learn it slowly until I can master it.

cycloshost
Posts: 578
Joined: Mon Jan 30, 2012 8:12 am
Contact:

Re: Age and Maturity counters on balances & transactions

Post by cycloshost » Thu May 07, 2015 9:08 am

It is possible to apply fees based on the counters using a fee extension.
Is it possible to have an example on this ?

Is it possible to use the counters to allow a transaction? For example, to define a transaction that can be processed only if the age counter is greater than a number of days.

Thanks!
cycloshost.com
Cyclos administration and hosting

Post Reply