CXP protocol Intertrading API 1.

0 (beta) for community currencies The Intertrading Protocol Group, October 2013

Introduction
This protocol provides a currency conversion mechanism hich increases the purchasing po er of complementary currencies! "sing the #ommunity $%change Payments &#'P( protocol and )PI, complementary currency systems can reach agreements to trade ith other communities, and their users ould be able to spend the means of payment they have generated in one system to purchase products and services from other systems! This conversion mechanism is articulated through a common base unit hosted in a common e%change server &ledger(, hich ould process the clearing bet een different currencies! This practice e call *intertrading*! The participating community e%change systems ould collectively decide the rules governing intertrading transactions ith other communities, ta+ing decisions li+e, hether to manage e%change rates and balance of trade through internal policy, or hether to float the currency against their neighbours! )n automated system to set the e%change rate according to the balance of trade should be available for communities to opt in to! Definitions User, a person supplying or procuring goods and services! Currency, a unit of value and it*s rules, eg, credit limits or prices &e%change rates(! Account, an account controlled by a "ser ith a record of a -uantity of currency! Community, a group of )ccounts denominated in a common #urrency! Intertrading Circle, a #ommunity of #ommunities using a *base* #urrency! Virtual Customer, the #ommunity*s )ccount in the Intertrading #ircle! Import-Export Account, the )ccount in the #ommunity hich is used to connect to the Intertrading #ircle! The balance is al ays the negative of the associated .irtual #ustomer )ccount! Governing Body, the governing body for each #ommunity &including intertrading communities(! )n association providing accounting services bet een community currencies should include the follo ing elements in its constitution! How to use this Protocol Once there is a governing process in place bet een the member communities a number of design choices should be made as follo s,

Template for a constitution.
1. W o can !oin" )n Intertrading #ircle is a club! /embership is voluntary and at the discretion of the club*s Governing 0ody! The club can have rules hich the member #ommunity agrees to abide by! /ember #ommunities should implement the )PI preferrably using open1source soft are! #. W at is t e !oining process" The 2oining process is determined by the communities ithin an Intertrading #ircle or ith hom a #ommunity is intertrading! 3hen a #ommunity 2oins an Intertrading #ircle, an account in the Intertrading #ircle is created for the ne community and an )PI +ey or login is given to them! They can be given credit limits according to any rules! $. %o& to determine exc ange rates" )ll member #urrencies are e%pressed as a multiple of a base #urrency! /embers can be responsible for declaring and maintaining their o n e%change rates, or e%change rates can be automatically set to +eep Intertrading balances bet een agreed limits! 4oining #ommunities usually have a nominal currency value, so they may be able to declare this themselves! There may be a given moment, periodically, for #ommunities to redeclare the values of their #urrencies! '. W at is t e (ase unit" Intertrading means that the base unit is a fi%ed amount and all #urrencies are calculated in relation to it! In a free1mar+ets such as 5ore%, the base unit floats against all the other #urrencies! $%ample base units, a bas+et of currencies, 63h, miligrams of gold, minutes, or dollars! ). %o& are credit limits (et&een mem(er communities determined" It is advised to start simple! /any ays are possible! $g, /ultiple of members, percentage of last 3 months trade volume or reputation! *. W at +ind o, monitoring s ould ta+e place" /onitoring needs to be supported by the Intertrading #ircle soft are! To identify fraud, transactions can be monitored for unusual activity! To identify #ommunities at ris+ of default, credit limits can be monitored! To identify opportunities for enterprise, supply and demand &re-uires offers and ants info( can be monitored! Other, eg, transactions can be monitored to chec+ the distance fresh food is travelling! -. En,orcement and sanctions )n Intertrading Governing 0ody can bloc+ a .irtual #ustomer )ccount to stop a community from intertrading! .. /egal considerations 7a s and regulations differ in every country! It should be possible for intertrading associations to come together in a super1association and implement this protocol bet een themselves! This is called nesting!

Technical Implementation
The clearing service could be implemented using a straightfor ard accounting application such as #yclos! ) prototype server and client already e%ist in 8rupal! The clearing service must • host one account representing each member e%change, hich mirrors an account on the e%changes o n server, called the *intertrading* account, • chec+ integrity ith the member e%change! • impose agreed balance limits, ma%imum and minimum, on each e%changes account • +eep a definitive bac+up record of each transaction • produce reports The system is not e%pected to run ithout human oversight! 9pecifically, it does not allo communities to create accounts and access credit automatically! Authentication !ecurit"

There is very little incentive or opportunity to steal in a mutual credit system because • the credit cannot leave the circle • every transaction leaves a record • the credit has no value in itself :/ac is understood to be the most appropriate authentication method, because it is invulnerable to man1in1the1middle attac+s! API #ethods 3e assume here that accounts are created and approved on the clearing server, not via the client and the )PI! :andsha+e, #lient announces to server, refreshes +ey, and sends statement data, and server responds ith a description of the rules ; account stats! PO9T, http,<<myserver!com<server 7ist e%changes &ideal for a2a%(, =etrieve a list of other member systems, typically for populating a dropdo n idget! G$T, http,<<myserver!com<server<clients Prepare form &ideal for a2a%(, Typically called before a transaction is attempted, to verify client validity and prepare client about its balance limits on the server! G$T, http,<<myserver!com<transactions Try transaction,

The re-uest should be repeated every fe seconds to prevent a timeout! P"T, http,<<myserver!com<transactions =elay transaction, 9erver relays transaction to second client! P"T, http,<<myclient!com<transactions $essage structures The content of each message should be a 2son array! )ll -uantities are measured in base units i!e! the unit of the server! :andsha+e re-uest, >? *api* , 57O)T, <<version of this )PI *mail* , 9T=I@G &A3(, <<address of the site admin! *tic+s* , 57O)T, <<relative value of the currency against the internal unit *firstBtrade* , I@T$G$= &uni%time(, <<the date of the first trade in the system, *traders* , I@T$G$=, <<@umber of traders *transactions* , I@T$G$=, <<number of transactions in the last 30 days *uri* , 9T=I@G, <<The root path e!g! domain!org<myto nC-D *divisions* , mi%ed, <<&optional( 01 means cents O= list of acceptable centiles separated by pipeE *visibility* , 0OO7$)@, <<&optional( Toggle hether all this data should be visible to the public *logo* , "=7, <<&optional(The absolute url of the logo of the site &optional( *lat* , 57O)T, <<&optional( The latitude of the site *lon* , 57O)T, <<&optional( The longitude of the site FG :andsha+e successful response, >? *message* , 9T=I@G, <<html, *status* , $@"/, << 11 means no account, 0 means bloc+ed, 1 means trading *balance* , I@T$G$=, <<balance of the client *min* , I@T$G$=, <<minimum balance limit of the client *ma%* , I@T$G$=, <<ma%imum balance limit of the client *count* , I@T$G$=, <<number of intertrading transactions *+eymatch* , 0OO7$)@, << hether the stored +ey is the same as the given one! GF Prepare form re-uest, >? *volume* , 57O)T, <<7ast 3AH days volume *integrity* , 1, <<0oolean hether the balances add up to Iero! /ust be T="$J *balance* , 57O)T, <<balance of the client intertrading account GF Prepare form successful response data, >? <<according the limits of the sites account on the intertrading server <<suitable for client1side validation

<<both values are K 0 since they indicate the ma% value of a transaction in a given direction *spendBlimit* , 57O)T, <<in base *earnBlimit* , 57O)T GF 7ist of clients successful response, >? *servername!com* , *9ite Title*, *servername2!com* , *9ite2 Title* <<etc! GF Try transaction &=$7)L$8 to http,<<client2!com<intertrade(, >? *payer* , varchar, *payerBurl* , varchar, *payee* , varchar, *payeeBurl* , varchar, *destBurl* , 9T=I@G, <<*servername!com*, *srcBurl* , 9T=I@G, <<*servername!com*, *-uantity* , 57O)T, *description* , T$'T, <<2HH chars *really* , boolean, << hether or not to rite *tempBid* , varchar <<random string the server +no s not to try t ice GF Try transaction, response data, >? *code* , I@T$G$=, *args* , array&( GF :TTP $==O= #O8$9 This is an ad hoc e%tenstion of the http status codes http,<<en! i+ipedia!org< i+i<7istBofB:TTPBstatusBcodes $very ord ith M ill be the +ey of an accompanying array containing replacements, for use in translation! N, *Transaction ould e%ceed limits on server!* H, *Problem saving transaction on server, OMmessageP* A, *"n+no n account Q failed to create a ne account on intertrading server!* R, *8iagnostics from server, OMmessageP* S, *Invalid transaction field, Mfield, Mvalue* 11, */issing config field, Mfieldname* 12, *5ield Mfieldname should be Mrel 0, Tval* 13, *5ield Mfieldname contains invalid characters!* 1N, *Lour Intertrading ratio &balance<volume( e%ceeds MnumU, Mbalance < Mvolume* 1H, *Type error in field Mfieldname! 9hould be a Mtype!*

1A, *Lour e%change is not permitted on this net or+!* 1R, *3rong +ey!* 1S, *@ot enough data to authenticate!* 20, *9erver failed to authenticate ith remote client!* 2N, *Transaction ould e%ceed remote client*s account limits!* 2H, */isc validation error on remote client, Mmessage* 2A, *9erver not found, Mserver* 2R, *MmessageV, Targs <<anything else

Sign up to vote on this title
UsefulNot useful