Grassroots Bonds: A Grassroots Foundation for Market Liquidity

Grassroots Bonds: A Grassroots Foundation for Market Liquidity Ehud Shapiro London School of Economics and W eizmann Institute of Science UK and Israel Abstract Global cryptocurrencies are unbacked and have high transaction cost incurred by global consensus. In contrast, grassroots crypto cur- rencies are backed by the goods and services of their issuers—any person, natural or legal—and hav e no transaction cost bey ond oper- ating a smartphone. Liquidity in grassroots crypto currencies arises from mutual credit via coin exchange among issuers. Howe ver , as grassroots coins are redeemable 1-for-1 against any other grass- roots coin, the credit-forming exchange must also be 1-for-1, lest prompt redemption after exchange would leave the parties with undue prot or loss. Thus, grassr oots coins are incongruent with liquidity through interest-bearing credit. Here we introduce grassroots bonds, which extend grassroots coins with a maturity date, reframing grassroots coins—cash—as mature grassroots bonds. Bond redemption generalises coin re- demption, allowing the lending of liquid coins in exchange for interest-bearing future-maturity bonds. W e show that digital so- cial contracts—voluntary agreements among persons, specied, fullled, and enforced digitally—can express the full gamut of - nancial instruments as the voluntary swap of grassroots bonds, including credit lines, loans, sale of debt, forward contracts, op- tions, and escrow-based instruments, and that classical liquidity ratios are applicable just as well to grassroots bonds. Grassroots bonds may thus allow local digital economies to form and grow without initial capital or e xternal credit, harnessing mutual trust within communities into liquidity . The formal specication pr esented here was used by AI to derive a working implementation of grassroots b onds in GLP, a concurrent logic programming language implemented in Dart for smartphone deployment. The implementation is illustrated by a running multi- agent village market scenario, also implemented in GLP by AI. 1 Introduction Grassroots currencies. Grassroots coins [ 50 ] are units of debt that can be issued and traded digitally by any person—natural or legal—including people, communities, cooperatives, corporations, banks, municipalities and governments. Grassr oots currencies are more similar to at currencies in that they are backed by goods and services oered by the issuer , who controls their scarcity , as well as to ‘inside money’ [ 10 , 11 ]—a medium of exchange backed by private credit—than to global crypto currencies such as Bitcoin [ 39 ] or Ethereum [ 7 ], which are unbacked and for which scarcity is controlled by the protocol. Grassroots currencies aimed to pro vide a foundation for grass- roots digital economies, allowing them to emerge without ini- tial capital or external credit, operating solely on the networked smartphones of their members, and gradually merge into a global digital economy . As such, grassroots currencies may empower economically-deprived communities worldwide , and by harnessing mutual trust within communities help ‘banking the unbanked’ [ 1 , 5 ]. These abilities may b e most relevant in places where capital and external credit are scarce but trust within families and communities is abundant. V alue and redemption. Grassr oots currencies are endowed with value by their issuer undertaking to redeem them against their oerings: Goods and ser vices for people and corp orations; interest and transaction fees for banks; taxes for cities and states; and at currencies for central banks. Critically , the oerings of each person must also include all the grassroots coins it holds, including coins issued by other persons. Upon request, a p erson must redeem any coin it has issued, 1-for-1, against any coin it holds. Coin redemption is key for a digital economy base d on grassroots currencies to function, as it ( i ) makes coins issued by the same person fungible; ( ii ) resolves doublespending [ 32 ]; ( iii ) allows the revocation of cr edit; ( iv ) allows chain payments across mutually- liquid currencies; and ( v ) pegs mutually-liquid grassroots currencies at a 1-for-1 exchange rate. Liquidity through mutual credit. As each person prices their goods and services in terms of their own currency , trade is impossi- ble if no person holds another person’s coins. This can be remedied by mutual credit lines, formed by the voluntary exchange of grass- roots coins among persons that know and trust each other—family members, friends, peers, and colleagues; a community bank and its members; a corporation and its owners, employees, suppliers, and customers. Liquidity arises from persons holding each other’s coins, and is correlated with the amount and distribution of coins in circulation. A grassroots coin in circulation is an outstanding obligation by its issuer to its holder , and the amount of grassroots coins in circulation in a digital economy is a measure of the trust among its members. The limitation of coins. Since grassroots coins can be rede emed 1-for-1, mutual credit must also be 1-for-1, lest closing it right after formation would leave the parties with undue prot or loss. Con- cretely , if 𝑝 opens a mutual line of credit with 𝑞 with an upside for 𝑝 , e.g. 100 𝑝 -coins against 110 𝑞 -coins, then coin r edemption would allow 𝑝 to immediately redeem the 100 𝑞 -coins it holds, leaving 𝑝 with 10 𝑞 -coins and 𝑞 with nothing; this is akin to a bank granting a loan with an upfront interest payment then immediately recall- ing the loan while keeping the interest. More generally , grassr oots currencies cannot associate interest with credit in an intrinsic way . Grassroots bonds. Here we present grassr oots bonds, which ex- tend grassroots coins with a maturity date, reframing grassroots coins—cash—as mature grassroots bonds. Coin-for-bond redemp- tion generalises coin-for-coin redemption, allowing the lending of liquid coins in exchange for interest-bearing future-maturity bonds, facilitating incentive-based liquidity . Implementation. The grassroots b onds specication presented here was used by AI to derive a working implementation in GLP [ 51 ], a multiagent concurrent logic programming language implemented 1 Ehud Shapiro in Dart for smartphone deplo yment. The implementation is demon- strated by a running six-agent village market scenario, also im- plemented in GLP by AI, that exercises symmetric mutual credit, asymmetric credit with inter est, payments, portfolio swaps, escrow , redemption, and sale of debt. Security . A secure grassroots payment system for grassroots coins has been presented in [ 32 ]. Its security is based on the issuer of each currency—its sovereign —guaranteeing the security of trans- actions in that currency: the sovereign approves or disapproves payments in their coins, and safety violations are detectable as signed cr yptographic evidence. No consensus is nee ded; a sover- eign that misb ehaves or fails to respond risks their coins being treated as bad debt. This model applies directly to unilateral bond transactions (mint, pay , redeem); voluntary swaps between two par- ties employ bilateral atomic commitment, with escro w (Section 4) as a non-blocking alternative. Integrating these mechanisms in a secure implementation of GLP is a subject of ongoing work. Contributions and paper structure. Section 2 presents grassroots bonds and their specication as a digital social contract with two transactions—mint and swap—fr om which all nancial instruments emerge. Section 3 develops the full gamut of nancial instruments as volitional bond swaps, including credit lines, loans, sale of debt, forward contracts, and options. Section 4 adds escrow-based in- struments: collateral, guarantees, options, insurance, credit default swaps, and letters of credit. Section 5 applies classical liquidity ratios—cash, quick, and current—to grassroots bonds. Se ction 6 de- velops a community bank scenario tying the instruments together . Section 7 implements the bonds so cial contract in GLP [ 51 ], a mul- tiagent concurrent logic programming language , demonstrated in a six-agent village market scenario . Section 8 compares with global cryptocurrencies, DeFi and classical nance. Section 9 concludes. Appendix A provides mathematical foundations for the work pr e- sented here . Appendix B pr esents the bond agent GLP sour ce code. 2 Grassroots Bonds W e assume a global present time 𝑡 ∗ ∈ N and a p otentially innite set of agents Π , but consider only nite subsets of it, so when we refer to a particular set of agents 𝑃 ⊂ Π we assume 𝑃 to be nonempty and nite. Denition 2.1 (Grassroots Bonds). A 𝑝 -bond with maturity date 𝑡 , denoted ¢ 𝑝 ,𝑡 , is a unit of debt issued by 𝑝 ∈ Π maturing at time 𝑡 ∈ N ; it is mature if 𝑡 ≤ 𝑡 ∗ , in which case it is also referred to as a 𝑝 -coin and denoted ¢ 𝑝 . In particular , a b ond minted with 𝑡 = 0 is a grassroots coin (cf. [ 50 ]) from the outset. W e let B ( 𝑃 ) = { ¢ 𝑝 ,𝑡 : 𝑝 ∈ 𝑃 , 𝑡 ∈ N } denote the set of all grassroots bonds by agents 𝑃 ⊂ Π , and write ¢ 𝑘 𝑝 ,𝑡 for a multiset of 𝑘 bonds ¢ 𝑝 ,𝑡 . In a practical implementation, each 𝑝 -bond will have a serial number and value and b e signed by 𝑝 . For simplicity of exposition the bonds (and coins) employed here can form multisets and are implicitly with denomination 1 . As discussed in [ 50 ], coins are backed by goods and ser vices oered by the coin’s issuer and priced in their coins, with bond values derived from expectation on the coin value. Coin r edemp- tion ensures that coins issued by mutually-liquid p ersons are of equal value, namely traded at a 1-for-1 rate. A consequence of the redemption rule is that all coins held by an issuer of a coin are necessarily part of the goods oered by the issuer , priced 1-for-1. Thus, the holder of a 𝑞 -coin that loses trust in 𝑞 may rede em it against any bond held by 𝑞 . A holder of an immature 𝑞 -bond who loses trust in 𝑞 may sell the debt in the free market, as describe d in Section 3. 2.1 A Digital Social Contract for Grassroots Bonds A digital social contract [ 9 ] is a voluntary agreement among per- sons, specied, fullle d, and enforced digitally . It is the grassroots counterpart of smart contracts [ 48 ], executed not by third-parties but by the parties to the contract, and may b e consensus-based [ 27 ] or consensus-free. Here, w e specify the digital social contract that governs grassroots bonds using volitional multiagent atomic trans- actions, dened below , and demonstrate their implementation in Section 7. V olitional transactions extend multiagent atomic transactions [ 52 ] by assuming that each agent participating in a transaction consists of a person operating a machine (e.g., smartphone), and encoding the persons that need to consent to a transaction. This requires a correct implementation of a volitional transaction to obtain such consent, for example using the p erson-machine interface . Note that personal consent is in addition to the basic requirement that all machines participating in an atomic transaction agree to it [ 20 ], even in transactions that the consent of the p erson operating them is not needed. W e use 𝑆 𝑃 to denote the set 𝑆 indexed by 𝑃 , with 𝑐 𝑝 the compo- nent indexed by 𝑝 . Denition 2.2 (Conguration, Transaction, V olitional Transaction). A conguration over agents 𝑃 ⊂ Π and a set of local states 𝑆 is a member 𝑐 ∈ 𝑆 𝑃 . A transaction over 𝑃 and 𝑆 is a pair 𝑡 = 𝑐 → 𝑐 ′ of distinct congurations, each over 𝑃 and 𝑆 ; agent 𝑝 is an active participant in 𝑡 if 𝑐 𝑝 ≠ 𝑐 ′ 𝑝 , stationary other wise. A volitional trans- action is a pair ( 𝑡 , 𝑉 ) where 𝑡 is such a transaction and 𝑉 ⊆ 𝑃 is the set of volitional participants —those whose person must consent for the transaction to execute. In such a case we say that the transition 𝑡 is guarded by 𝑉 . Appendix A provides mathematical background, in particular how a set of multiagent atomic transactions induces a family of multiagent transition systems [ 52 ] and the conditions under which they are grassroots [48]. The grassroots bonds so cial contract is specie d by two voli- tional transactions: Mint , guarded by its sole participating agent, by which the agent mints new bonds; and Swap , by which its two participating agents 𝑝 and 𝑞 swap bonds. The latter has three sub- cases: V oluntar y swap , by which the two agents agree to swap two sets of bonds, guarded by both 𝑝 and 𝑞 ; Pay , by which 𝑝 unilat- erally pays 𝑞 with 𝑞 -coins, guarded by 𝑝 ; and Redeem , by which 𝑝 unilaterally transfers to 𝑞 a 𝑞 -coin in exchange for a bond held by 𝑞 , guarded by 𝑝 . Only coins—that is, mature b onds—may b e paid or redeemed; coin-for-bond r edemption generalises the coin-for-coin redemption of grassroots currencies [ 50 ] by allowing the holder of a coin to choose any bond held by the issuer of the coin. The holder of an 2 Grassroots Bonds immature bond may sell the debt to a third party , as shown in Section 3. Denition 2.3 (Grassroots Bonds V olitional Transactions). For agents 𝑃 ⊂ Π , the set of states 𝑆 ( 𝑃 ) consists of all multisets of memb ers of B ( 𝑃 ) , with initial state 𝑠 0 = ∅ . The grassroots bonds volitional transactions over 𝑃 and 𝑆 ( 𝑃 ) are all transactions such that: (1) Mint : A unary 𝑝 -transaction 𝑠 → 𝑠 ′ , 𝑝 ∈ 𝑃 , guarded by 𝑝 , 𝑠 ′ : = 𝑠 ∪ { ¢ 𝑘 𝑝 ,𝑡 } , 𝑘 , 𝑡 ∈ N . (2) Swap : A binary { 𝑝 , 𝑞 } -transaction, 𝑐 → 𝑐 ′ , { 𝑝 , 𝑞 } ⊆ 𝑃 , 𝑐 ′ 𝑝 : = ( 𝑐 𝑝 ∪ 𝑦 ) \ 𝑥 , 𝑐 ′ 𝑞 : = ( 𝑐 𝑞 ∪ 𝑥 ) \ 𝑦 for any 𝑥 , 𝑦 for which one of the following holds: (a) V oluntary swap : 𝑥 ⊆ 𝑐 𝑝 , 𝑦 ⊆ 𝑐 𝑞 . Guarded by { 𝑝 , 𝑞 } . (b) Pay : 𝑥 ⊆ 𝑐 𝑝 is a set of 𝑞 -coins, 𝑦 = ∅ . Guarded by 𝑝 . (c) Redeem : 𝑥 = { ¢ 𝑞 } ⊆ 𝑐 𝑝 , 𝑦 = { ¢ 𝑟 ,𝑡 } ⊆ 𝑐 𝑞 , 𝑡 ∈ N . Guarded by 𝑝 . W e note four properties of grassroots bonds: (1) Conservation of Money: In a run of a grassroots bonds tran- sition system, the 𝑝 -bonds in any conguration 𝑐 in the run are exactly the 𝑝 -bonds minted by 𝑝 in the pr ex of the run ending in 𝑐 . (2) Chain redemption: Coin redemption generalises the chain re- demptions of grassroots coins [ 50 ]. If there is 1-liquidity from 𝑝 to 𝑞 , dened by the existence of a se quence of persons 𝑝 0 , . . . , 𝑝 𝑘 , 𝑝 0 = 𝑝 , 𝑝 𝑘 = 𝑞 , where each 𝑝 𝑖 , 0 ≤ 𝑖 < 𝑘 , holds a 𝑝 𝑖 + 1 -coin, then 𝑝 can initiate a chain of 𝑘 − 1 redemptions to obtain a 𝑞 -coin. Chain redemption enables long-range payments and arbitrage, and entails a 1:1 e xchange rate among coins within liquidity-connected components. (3) Insolvency: Insolvency is manifest in the inability of a per- son to satisfy redemption claims on coins they have issued. Holders of an insolvent person’s bonds may treat them as bad debt and sell them at a discount, ee ctively devaluating the insolvent person’s currency [ 50 ]. The instruments de veloped in this paper—collateral, escrow , and community-level risk man- agement (Sections 4–6)—provide measures to mitigate the con- sequences of insolvency . (4) Grassroots: The grassroots bonds protocol is grassroots [ 48 ] in the formal sense of [ 52 ]: multiple independent deployments can emerge without global resources and interoperate once interconnected. The proof is given in Appendix A. 3 Financial Instruments The full gamut of nancial instruments can be expressed via the voluntary swap of grassroots bonds. Each instrument below is a voluntary swap (Denition 2.3) between agents 𝑝 and 𝑞 , guarded by the two agents, spe cied by the b onds 𝑥 transferred from 𝑝 to 𝑞 and the bonds 𝑦 transferred from 𝑞 to 𝑝 . (1) Symmetric mutual credit. 𝑝 and 𝑞 each mint 𝑘 coins and exchange them: 𝑥 = ¢ 𝑘 𝑝 , 𝑦 = ¢ 𝑘 𝑞 . (2) Zero-coupon loan. Lender 𝑝 mints 𝑘 ′ < 𝑘 coins, borrower 𝑞 mints a bond maturing at 𝑡 : 𝑥 = ¢ 𝑘 ′ 𝑝 , 𝑦 = ¢ 𝑘 𝑞,𝑡 . (3) Balloon loan. Lender 𝑝 mints 𝑘 coins, borrower 𝑞 mints inter- est bonds ¢ 𝑘 𝑗 𝑞,𝑡 𝑗 for 𝑗 ∈ [ 1 . .𝑛 ] and a principal bond ¢ 𝑘 𝑞,𝑡 : 𝑥 = ¢ 𝑘 𝑝 , 𝑦 = Ð 𝑛 𝑗 = 1 ¢ 𝑘 𝑗 𝑞,𝑡 𝑗 ∪ ¢ 𝑘 𝑞,𝑡 . (4) Fixed-payment loan. Lender 𝑝 mints 𝑘 coins, borrower 𝑞 mints bonds with xed payments 𝑘 𝑗 at dates 𝑡 𝑗 : 𝑥 = ¢ 𝑘 𝑝 , 𝑦 = Ð 𝑛 𝑗 = 1 ¢ 𝑘 𝑗 𝑞,𝑡 𝑗 . (5) Revolving credit line. An asymmetric credit line from 𝑝 to 𝑞 with limit 𝑘 : 𝑥 = ¢ 𝑘 𝑝 , 𝑦 = ¢ 𝑘 𝑞,𝑡 . When 𝑞 repays (pays 𝑝 in 𝑝 -coins), 𝑞 may draw again: a new voluntary swap up to the remaining limit, consented to by 𝑝 . (6) Sale of debt. 𝑝 sells 𝑟 -bonds to 𝑞 for 𝑘 ′ < 𝑘 𝑞 -coins: 𝑥 = ¢ 𝑘 𝑟 , 𝑦 = ¢ 𝑘 ′ 𝑞 . The debtor 𝑟 is not a party . (7) Forward contract. 𝑝 and 𝑞 exchange bonds both maturing at 𝑡 : 𝑥 = ¢ 𝑘 𝑝 ,𝑡 , 𝑦 = ¢ 𝑘 ′ 𝑞,𝑡 . (8) Interest rate swap. 𝑝 and 𝑞 exchange two sets of bonds with diering maturity schedules: 𝑥 = Ð 𝑗 ¢ 𝑘 𝑗 𝑝 ,𝑡 𝑗 , 𝑦 = Ð 𝑗 ¢ 𝑘 ′ 𝑗 𝑞,𝑡 𝑗 , where 𝑝 pays xe d amounts 𝑘 𝑗 while 𝑞 pays amounts 𝑘 ′ 𝑗 that var y according to a reference rate. Periodic settlement swaps realise the net dierence at each date. The instruments cover mutual credit and loans (items 1–5), debt trading (item 6), derivatives (items 7–8). Currency swaps and repur- chase agreements (repos) are r ealised as sequences of two swaps; factoring (selling receivables at a discount) is an instance of sale of debt; a mortgage is a loan (items 2–4) combine d with collateral. Col- lateral, guarantees, options, insurance, and further escr ow-based instruments are developed next. 4 Escrow An escrow agent 𝑒 holds bonds on b ehalf of others and releases them according to agreed-upon conditions. No new transaction type is needed: dep osit, release, and return are all swaps, guarded by the parties to the swap. Mechanism. An escrow arrangement involves a depositor , a bene- ciary , and an escrow agent 𝑒 . The dep ositor transfers bonds to 𝑒 via a swap. Subsequently , 𝑒 either releases the bonds to the beneciary or returns them to the depositor , each via a swap. The conditions under which 𝑒 releases or r eturns are part of the agreement. (1) Collateral: T o collateralise a loan from lender 𝑝 to borrower 𝑞 : (a) Deposit. { ( 𝑞, 𝑥 ) , ( 𝑒 , ∅ ) } : borrower 𝑞 transfers bonds 𝑥 to escrow agent 𝑒 . (b) Release on default. { ( 𝑒 , 𝑥 ) , ( 𝑝 , ∅) } : 𝑒 transfers collateral to lender 𝑝 . (c) Return on fullment. { ( 𝑒 , 𝑥 ) , ( 𝑞, ∅ ) } : 𝑒 returns collat- eral to borrower 𝑞 . (2) Guarantee: Guarantor 𝑔 covers borrower 𝑞 ’s obligations to lender 𝑝 : (a) Deposit. { ( 𝑔, ¢ 𝑘 𝑔 ) , ( 𝑒 , ∅ ) } : 𝑔 deposits 𝑔 -bonds with escrow agent 𝑒 . (b) Invocation on default. { ( 𝑒 , ¢ 𝑘 𝑔 ) , ( 𝑝 , ∅ ) } : 𝑒 releases 𝑔 - bonds to lender 𝑝 . (c) Release on fullment. { ( 𝑒 , ¢ 𝑘 𝑔 ) , ( 𝑔, ∅ ) } : 𝑒 returns 𝑔 -bonds to 𝑔 . 3 Ehud Shapiro (3) Option: An option grants 𝑝 the right, but not the obligation, to execute a specied swap with 𝑞 at or before date 𝑡 . The option premium and the underlying assets are held in escro w: (a) Establishment. 𝑝 deposits the premium ¢ 𝑘 𝑝 with escrow agent 𝑒 : { ( 𝑝 , ¢ 𝑘 𝑝 ) , ( 𝑒 , ∅ ) } . 𝑞 deposits the underlying bonds 𝑦 with 𝑒 : { ( 𝑞, 𝑦 ) , ( 𝑒 , ∅) } . (b) Exercise. 𝑝 signals exercise. 𝑒 releases the underlying 𝑦 to 𝑝 : { ( 𝑒 , 𝑦 ) , ( 𝑝 , ∅ ) } , and releases the premium to 𝑞 : { ( 𝑒 , ¢ 𝑘 𝑝 ) , ( 𝑞 , ∅ ) } . (c) Expiry . If 𝑝 has not exercised by 𝑡 , 𝑒 returns the underly- ing to 𝑞 : { ( 𝑒 , 𝑦 ) , ( 𝑞, ∅ ) } , and transfers the premium to 𝑞 : { ( 𝑒 , ¢ 𝑘 𝑝 ) , ( 𝑞 , ∅ ) } . The above species a call option : 𝑝 acquires the right to buy the underlying 𝑦 from 𝑞 . A put option —the right to sell bonds to 𝑞 at a predetermined price—is symmetric: 𝑞 deposits the strike price with 𝑒 , and 𝑝 deposits the b onds it wishes to sell. The specication above uses A merican exercise: 𝑝 may exercise at or before 𝑡 . For European exercise, 𝑝 may exercise only at 𝑡 . A strike price can be incorp orated by having 𝑝 deposit additional bonds ¢ 𝑘 ′ 𝑝 with 𝑒 at establishment. On exer cise, 𝑒 transfers the strike price to 𝑞 along with the premium; on e xpiry , 𝑒 returns the strike price to 𝑝 along with the premium. (4) Insurance: Party 𝑝 (the insured) pays a premium to escrow agent 𝑒 , who disburses a payout if a specied event occurs, as attested by 𝑒 : (a) Premium. { ( 𝑝 , ¢ 𝑘 𝑝 ) , ( 𝑒 , ∅ ) } : 𝑝 deposits the premium with 𝑒 . (b) Claim (event occurs). { ( 𝑒 , ¢ 𝑘 ′ 𝑞 ) , ( 𝑝 , ∅ ) } : 𝑒 transfers the payout 𝑘 ′ ≫ 𝑘 to 𝑝 . The payout is funded by the insurer 𝑞 , who has deposited b onds with 𝑒 as reserves. (c) Expiry (no event). The premium is retained by 𝑒 on behalf of insurer 𝑞 . The escrow agent 𝑒 serves as the claims adjudicator . A mutual insurance arrangement among a group of participants can be realised by each member depositing premiums into a shared escrow reserve. (5) Credit default swap (CDS): Party 𝑝 pays periodic premiums to 𝑞 (the protection seller), and 𝑞 compensates 𝑝 if a reference entity 𝑟 defaults. Escrow agent 𝑒 adjudicates: (a) Premium payments. Perio dic swaps { ( 𝑝 , ¢ 𝑘 𝑗 𝑝 ,𝑡 𝑗 ) , ( 𝑒 , ∅ ) } : 𝑝 deposits premium bonds with 𝑒 , forwarded to 𝑞 . (b) Credit event. { ( 𝑒 , ¢ 𝐾 𝑞 ) , ( 𝑝 , ∅) } : if 𝑒 determines that 𝑟 has defaulted, 𝑒 releases 𝑞 ’s reserve bonds to 𝑝 . (c) No credit event. Premium b onds are released to 𝑞 and reserve bonds returned to 𝑞 at maturity . (6) Letter of credit: A bank 𝑏 guarantees payment to seller 𝑝 on behalf of buyer 𝑞 , with escrow agent 𝑒 verifying that contractual conditions (e.g. deliv ery of goods) are met: (a) Issuance. { ( 𝑏 , ¢ 𝑘 𝑏 ) , ( 𝑒 , ∅) } : bank 𝑏 deposits 𝑏 -coins with 𝑒 . (b) Presentation. { ( 𝑒 , ¢ 𝑘 𝑏 ) , ( 𝑝 , ∅ ) } : upon 𝑒 verifying that 𝑝 has fullled the terms (e .g. delivery attestation), 𝑒 releases 𝑏 -coins to seller 𝑝 . (c) Reimbursement. { ( 𝑞, ¢ 𝑘 𝑞,𝑡 ) , ( 𝑏, ∅ ) } : buyer 𝑞 reimburses bank 𝑏 with 𝑞 -b onds. 5 Liquidity Measures The liquidity measures of cash, quick, and current ratios wer e de- veloped in corporate nance to assess the liquidity of corporations. They were adapted to grassroots cryptocurrencies in [ 50 ]. Here we extend them to grassr oots bonds, where maturity dates play a central role. Recall that 𝑡 ∗ denotes the current time. Let 𝜈 𝑝 ,𝑡 ( 𝑞 ) be the number of 𝑝 -bonds with maturity date ≤ 𝑡 held by 𝑞 at present, where 𝑝 ≠ 𝑞 (zero if 𝑝 = 𝑞 , as 𝑝 -bonds held by 𝑝 carry no value). In particular , 𝜈 𝑝 ,𝑡 ∗ ( 𝑞 ) is the number of mature 𝑝 -bonds held by 𝑞 , and 𝜈 𝑝 , ∞ ( 𝑞 ) is the total number of 𝑝 -bonds held by 𝑞 . Recall the redemption rule (Denition 2.3): a holder of a 𝑝 -coin can redeem it against any bond held by 𝑝 , chosen by the holder . Only coins—i.e., mature bonds—may be oered for redemption. Cash ratio. The cash ratio measures the resilience of 𝑝 against a “run on the bank”: all holders of 𝑝 -coins attempt to redeem at once. Under the redemption rule, each holder claims any bond from 𝑝 ’s holdings. Let Δ ( 𝑝 , 𝑞 ) : = min ( 𝜈 𝑝 ,𝑡 ∗ ( 𝑞 ) , 𝜈 𝑞,𝑡 ∗ ( 𝑝 ) ) . Thus Δ ( 𝑝 , 𝑞 ) is the num- ber of mature 𝑝 -bonds held by 𝑞 that 𝑞 can redeem with mature 𝑞 -bonds held by 𝑝 . Cash Ratio of 𝑝 = 1 − Í 𝑞 ∈ 𝑃 ( 𝜈 𝑝 ,𝑡 ∗ ( 𝑞 ) − Δ ( 𝑝 , 𝑞 ) ) Í 𝑞 ∈ 𝑃 𝜈 𝑝 ,𝑡 ∗ ( 𝑞 ) If 𝑝 holds enough mature foreign bonds to satisfy all redemption claims on its mature bonds, the cash ratio is 1. If 𝑝 holds no foreign bonds, the cash ratio is 0. Quick ratio. Since only coins may be redeemed, the quick ratio considers all 𝑝 -bonds in circulation as future liabilities that will become redeemable upon maturity , measured against all foreign bonds held by 𝑝 that will similarly mature into coins. Let Δ ∞ ( 𝑝 , 𝑞 ) : = min ( 𝜈 𝑝 , ∞ ( 𝑞 ) , 𝜈 𝑞, ∞ ( 𝑝 ) ) . Quick Ratio of 𝑝 = 1 − Í 𝑞 ∈ 𝑃 ( 𝜈 𝑝 , ∞ ( 𝑞 ) − Δ ∞ ( 𝑝 , 𝑞 ) ) Í 𝑞 ∈ 𝑃 𝜈 𝑝 , ∞ ( 𝑞 ) The quick ratio may be smaller than the cash ratio if 𝑝 has many immature b onds in circulation relative to its holdings of foreign bonds. Current ratio. The current ratio counts all foreign bonds held by 𝑝 as assets and all 𝑝 -bonds in circulation as liabilities, without regard to redeemability or maturity matching: Current Ratio of 𝑝 = Í 𝑞 ∈ 𝑃 𝜈 𝑞, ∞ ( 𝑝 ) Í 𝑞 ∈ 𝑃 𝜈 𝑝 , ∞ ( 𝑞 ) The current ratio admits assets that may not b e realisable: foreign bonds that cannot be redeemed, bonds by insolvent issuers, and fake assets issued by sybil persons to inate the balance sheet of 𝑝 . 6 Community Bank A community bank, or credit union, may streamline liquidity and simplify payments within a community that employs grassroots bonds. The bank would normally have a go verning body and sig- natories as authorise d by the community . The community bank 4 Grassroots Bonds issues its own grassroots currency and may open credit lines with community members at its discr etion ( e.g., emplo ying the objective measures for creditworthiness and liquidity discussed in Section 5), just as a private banker would do. A key characteristic of a community bank is that its members undertake to accept payments in the community currency , in ad- dition to their personal currency . Thus, transactions among liquid community members may include one-step payments in the com- munity currency . Presumably , community members will be happy to use the community currency , knowing that they own the bank. Note that a community bank does not (necessarily) need initial capital, and may employ standard measures to incr ease its capital such as charging interest on drawn credit and transaction fees. Community mutual credit scenario. Consider a village with a community of 501 people in which ev ery two villagers exchange 100 personal coins with each other . As a result, each villager will have 50,000 coins of other villagers, while issuing and transferring 50,000 of their own coins to others, with the village achieving a total liquidity of 25,000,000 coins in circulation, solely base d on mutual trust among villagers and without any e xternal capital or credit. Such liquidity may jumpstart the village’s local economy , with the exposure of each villager to any other initially limited to 0.2% of the total credit they have issued. Bank lending via bonds. The bank lends community coins to member 𝑝 in exchange for 𝑝 -bonds with maturity and interest. For example, the bank mints 10,000 community coins for 𝑝 , and 𝑝 mints 10,500 𝑝 -bonds maturing in six months—500 bonds as interest. The bank holds interest-bearing claims on 𝑝 ; 𝑝 holds liquid community coins accepted by all members. This is an instance of the loan instruments of Section 3 (items 2–4), with the bank as lender . Deposits. A member may dep osit community coins with the bank and receive community bonds maturing at 𝑡 with interest—for ex- ample, 10,000 community coins deposited, 10,200 community b onds maturing in six months returned. The bank’s income is the spread between lending and deposit rates. Collateral. Personal coins—those acquired by community members through bilateral mutual credit—serve as collateral for bank loans. The bank may require borrow er 𝑝 to deposit non- 𝑝 -coins it holds into escrow (Section 4) as security . If 𝑝 defaults, the escrowed bonds are released to the bank. If 𝑝 fulls the loan, the collateral is returned. The bank does not hold or manage personal coins directly; it holds 𝑝 -bonds and, when nee ded, escrowed collateral. Risk management. The bank manages risk through the maturity structure of its loan portfolio, collateral requirements at origination, the liquidity ratios of Section 5 applied to its borrowers, and the ability to sell debt at a discount (Section 3, item 6). A s in traditional banking, a xed-term loan cannot be recalle d before maturity; the bank must arrange protection at origination or sell the debt to a third party . Mutual currency recognition. An alternative to forming a com- munity bank is for community members to mutually recognise each other’s currencies: 𝑝 and 𝑞 agree to accept each other’s coins as payment, each up to a per-issuer limit. This is a bilateral standing agreement that builds exposure organically as payments o w , with- out the upfront coin exchange of a credit line. If all community members mutually recognise each other’s coins, the community forms a currency area without a community bank. Similarly , if two banks mutually recognise each other’s currencies, their customers can transact across banks dir ectly . This mechanism enables bottom- up formation of currency areas; its full treatment is deferred to the grassroots currencies paper [50]. 7 Implementation in GLP Grassroots Logic Programs (GLP) [ 51 ] is a multiagent, concurrent, logic programming language designed for programming digital social contracts. A social contract is realised as a GLP program, which people load and activate voluntarily on their devices. Here we implement the grassroots bonds transactions of Sec- tion 2—mint, swap, and redeem—as a GLP program, and demon- strate them through a simulated village e conomy involving six agents exercising the full gamut of nancial instruments. 7.1 Bond Agent The core of the implementation is the bond agent , a GLP process that manages each person’s holdings and executes transactions on their behalf. The agent maintains a list of bonds, a serial counter for minting, and communicates with other agents via typed message streams. A bond is represented as bond(Issuer, Maturity, Serial) . The core operations correspond directly to the formal specication of Section 2: Mint. The agent creates 𝑘 bonds with a given maturity and adds them to its holdings: agent(Id, [msg( ' _user ' , Id1, mint(K, Maturity))|UserIn], ...) :- create_bonds(Id?, Maturity?, K?, NextSerial?, NewBonds), append(Holdings?, NewBonds?, NewHoldings), agent(Id?, UserIn?, ..., NewHoldings?, ...). Swap. A swap is realised as a trade : the proposer sp ecies what they give and what they want as lists of lots lot(Issuer, Maturity, Count) . The agent selects matching bonds from its holdings; if successful, it sends the b onds and an unbound response variable to the counterparty . The counterparty either accepts ( binding the response to trade_accept(TheirBonds) ) or de clines (binding it to trade_decline(ReturnedBonds) ). This two-phase protocol— propose then accept/decline—implements the volitional multiagent atomic transaction of Section 2.1: both parties must consent for the swap to commit. The proposer side of the trade protocol: do_trade_result(ok, Id, Target, WantSpec, Selected, Remaining, UserIn, NetIn, Outs, NextSerial) :- lookup_send(friend(Target?), msg(Id?, Target?, trade_propose(WantSpec?, Selected?, TradeResp)), Outs?, Outs1), inject_trade_result(TradeResp?, Target?, UserIn?, UserIn1), agent(Id?, UserIn1?, NetIn?, Outs1?, Remaining?, NextSerial?). The agent sends its sele cted bonds along with an unbound response variable TradeResp to the counterparty via the friend channel. 5 Ehud Shapiro Concurrently , inject_trade_result monitors TradeResp —when the counterparty binds it (to accept or decline), the result is injected into the agent’s input stream. This is the volitional multiagent atomic transaction: the unbound variable is the pending consent, and binding it commits or aborts the swap. Note that the oered bonds are locked until the counterparty responds; if this is a risk that initiator of the swap does not wish to take, they can use a time-bound escrow agent instead. Unication. All nancial instruments—mutual credit, loans, pay , and redeem—are realised as combinations of mint and trade , with no dedicated commands or protocol machinery . Symmetric mutual credit is two mints followed by a trade; an asymmetric loan is a mint by the lender , a trade proposal, and a mint by the borrower who then accepts; pay is a trade with an empty want-specication. This unication simplies the agent: the only operations are mint, trade, and escrow . Trade classication. When the agent receives a trade proposal, it classies it into one of three categories: classify_trade(_, [], _, payment). classify_trade(Id, _, [bond(I, 0, _)], redemption) :- Id? =?= I? | true. classify_trade(_, _, _, normal) :- otherwise | true. Pay (no returned bonds) is auto-accepted—an agent cannot refuse accepting their own coins as payment. Redeem (exactly one of the agent’s own coins is oered) is also auto-accepted if the requested bond is available; otherwise the agent responds with a menu of available bonds—one per issuer , earliest maturity—so the proposer can retry an informed redemption request. Coin redemption. In the formal model, when 𝑝 redeems a 𝑞 -coin from 𝑞 it may specify any bond held by 𝑞 , in eect assuming that 𝑝 knows what b onds 𝑞 holds. W e approximate this in the GLP implementation as follows: if 𝑞 cannot respond with the requested bond, it reports to 𝑝 the type of bonds it holds (most mature of each type), allowing 𝑝 to choose from them. The caveat is that these bonds are not “locked” until 𝑝 decides what to do, allowing 𝑞 , as irl, to “conceal assets” , e.g. by transferring them to another person or even to a Sybil identity controlled by 𝑞 . While locking the reported assets until 𝑝 decides would av oid this pr oblem, it also exposes 𝑞 to the risk of 𝑝 not responding, and even to coordinated attack, hence we chose not to do this. Still, high-risk/high-stakes transactions can use an escrow agent. Escrow . The escrow mechanism is a concurrent race b etween two clauses: escrow(T, Bonds, _, escrow_bonds(Bonds?), escrow_expired) :- wait_until(T?) | true. escrow(_, Bonds, cancel, escrow_cancelled, escrow_bonds(Bonds?)). The rst clause suspends on a timer guard; the second suspends on the cancel signal. Whichever commits rst determines the outcome— time-release or cancellation—with the other alternative abandoned. This employs GLP’s committed-choice nondeterminism: two con- current alternatives race, and the rst to satisfy its guard wins. The complete bond agent, including all helper procedures for bond sele c- tion, trade dispatch, redemption, and friend-channel management, is approximately 740 lines of typed GLP code, shown in Appendix B. 7.2 Village Market Demonstration T o demonstrate that the instruments of Sections 3–4 compose into a functioning economy , w e implemented a simulated village market with six agents: Alice (baker), Bob (farmer), Charlie ( carpenter), Diana (doctor), Ev e (teacher), and Frank (sherman). The scenario unfolds over a simulated month and exercises seven distinct nan- cial operations: (1) Symmetric mutual credit. Alice and Bob each mint 15 coins and swap them 1-for-1, establishing mutual liquidity . Similarly for Alice–Charlie, Charlie–Eve , and Eve–Frank. (2) Asymmetric credit (loan). Diana lends Bob 20 diana-coins in exchange for 24 bob-bonds maturing on day 25—a 20% interest rate. Diana similarly lends Frank 15 coins for 18 bonds maturing day 28. (3) Pay . Bob pays Alice 5 alice-coins for bread; Eve pays Charlie 6 charlie-coins for a bookshelf; Frank pays Diana 3 diana-coins for a medical checkup. (4) Portfolio swap. Eve trades 5 frank-coins to Charlie for 5 alice- coins, acquiring the currency she needs to buy bread from Alice. (5) Escrow . Charlie hires Frank to build a dock and deposits 5 frank- coins in escrow for Frank with a 7-day cancellation window; Charlie does not cancel, the timer expires, and the coins are released to Frank as payment for building a dock. (6) Redeem. Frank redeems 5 diana-coins from Diana, reducing his exposure to Diana’s currency . (7) Sale of debt. Alice sells 10 bob-bonds to Eve for 4 frank-coins— a discounted sale reecting Alice ’s desire to reduce exposure to Bob’s debt. All six agents run concurrently as GLP processes, communicat- ing via typed message streams over a simulated 6-way network. Each agent emits a narrative trace describing its actions in natu- ral language, alongside the raw GLP command/notication trace. Figure 1 shows the narrative output of all six agents. 7.3 Implementation Summar y An intended smartphone deployment w ould include the bond agent (Appendix B, 740 lines of typed GLP code) and a UI; all other com- ponents are test infrastructure. The village market scenario of Sec- tion 7.2 is implemented by six scripted GLP actors totalling appro x- imately 870 lines, each in its o wn module. The implementation is open-source and available at https://github.com/EShapiro2/GLP- Bonds. The proof-of-concept represents each bond as a unit; a practi- cal deployment would use range-denominated bonds to compress holdings of the same issuer and maturity into a single term. 6 Grassroots Bonds Figure 1: Village Market: six-agent grassroots bond e conomy . Each panel shows one agent’s narrative trace. The scenario exercises symmetric mutual credit, asymmetric credit (loans with interest), pay , portfolio swap, escrow (time-release), redeem, and sale of debt. All agents run concurrently as GLP processes; the trace is produce d by a running GLP program, the key part of it shown in Appendix B. 8 Related W ork 8.1 Global Cr yptocurrencies Global cryptocurrencies such as Bitcoin [ 39 ] and Ethereum [ 7 ] are unbacked digital assets whose scarcity and transaction cost are controlled by the protocol. Grassroots coins [ 50 ] and the grass- roots bonds introduced here dier from global cr yptocurrencies in their foundations, architecture, and the nancial instruments they support. This section develops these contrasts along four axes: architectural design, source of value and liquidity , the nature of the nancial instruments each system supports, and the attack surfaces each design exposes. Architecture. Global cryptocurrencies maintain a single replicated ledger—a totally-ordered blockchain—via consensus among miners or validators. This architecture entails well-known costs: proof- of-work entails high-cost computing [ 39 ]; proof-of-stake requires capital lockup [ 55 ]; and all participants must obtain and maintain a copy of the global state. Transaction throughput is b ounded by block size and block interval, and transaction fees arise from competition for inclusion in the next block. Grassroots coins and b onds employ a fundamentally dierent architecture. T ransaction cost is limited to operating a networked device. The system is grassroots [ 49 ]: multiple independent deploy- ments can emerge without global resources and interoperate once interconnected. The comparison table in [ 32 ] details 18 dimensions along which the two architectures dier , including: one cryptocurrency per blockchain vs. one p er person, mutually p egged; competitive block creation vs. decentralised and co operative; global all-to-all dissemi- nation vs. local grassroots dissemination; probabilistic nality vs. denite nality; and a business model based on ICOs and miner remuneration vs. a public good. Source of value and liquidity . Global cryptocurrencies derive their value from speculative market demand; they are unbacked, and liquidity is obtained by mining or purchasing with external capital. Grassroots currencies are closer to ‘inside mone y’ [ 10 ]—a medium of exchange backed by private credit. Each person backs their coins and bonds with their oerings: goods and services for people and corporations; interest and transaction fees for banks; taxes for municipalities; and at currencies for central banks [ 50 ]. 7 Ehud Shapiro Liquidity arises not from capital injection but from mutual cr edit lines among persons that trust each other , and bond redemption— the obligation to redeem any coin one has issued against any b ond one holds—pegs mutually-liquid currencies at a 1:1 exchange rate. Grassroots bonds extend this foundation by allowing credit to carr y interest: lending liquid coins in exchange for future-maturity bonds, incentivising the provision of credit without requiring external capital. Financial instruments on blockchains. The programmability of blockchains via smart contracts [ 7 , 47 ] has given rise to Decen- tralised Finance (DeFi) [ 45 , 54 ], which re-implements traditional - nancial instruments on-chain. Lending protocols [ 22 , 31 ] oer over- collateralised loans with algorithmically-determined interest rates; decentralised exchanges provide token trading via automated mar- ket makers; and stablecoins oer price-stable media of exchange. These DeFi instruments have analogues among the grassroots bond instruments of Sections 3–4: loans, credit lines, sale of debt, and options are all expressible as volitional swaps of grassroots bonds, without requiring a blockchain or consensus. T w o dier- ences are noteworthy . First, DeFi instruments require overcollater- alisation enforced by smart contracts be cause counterparty identity is pseudonymous and trust is absent; grassroots instruments oper- ate among persons with mutual trust, and collateral (Section 4) is available but not mandatory . Second, DeFi instruments incur gas fees for every state transition; grassroots instruments incur no fees beyond bilateral communication. Crypto-native constructs. Three constructs are native to blockchain architecture and have no counterpart in grassroots bonds: ash loans, automated market makers ( AMMs), and maximal e xtractable value (MEV). All three arise from properties of global consensus that grassroots systems lack by design. A comprehensive systema- tisation identies 181 real-world DeFi attack incidents exploiting these properties [56]. Flash loans [ 44 ] are uncollateralised loans that exist within a sin- gle atomic blockchain transaction: a borrower takes a loan, uses the funds across arbitrarily many smart contracts, and repays within the same transaction; if repayment fails, the entire transaction re- verts. This is possible because blockchain transactions are atomic across the global state. Grassroots bonds have no global atomic transactions spanning multiple parties, and so ash loans cannot arise. This is a feature rather than a limitation: ash loans are the primary attack vector against DeFi protocols, with documented ex- ploits yielding returns e xceeding 500,000% [ 44 ]. Their impossibility eliminates that entire class of vulnerability . AMMs provide algorithmic price discovery via pooled liquidity and a bonding curve (e.g., the constant product formula 𝑥 · 𝑦 = 𝑘 ). They require globally-shared mutable state—the liquidity pool— maintained by consensus. Grassroots bonds have no pooled global state; price discovery is via bilateral negotiation. The trade-o is that grassroots bonds lack automated price discovery but avoid impermanent loss, sandwich attacks [ 13 ], and the concentration of value in pool contracts that creates targets for exploitation. MEV [ 13 ] is the prot that miners or validators can extract by reordering, inserting, or censoring transactions within a block. MEV manifests as frontrunning, backrunning, and sandwich attacks, and has been estimated to extract hundreds of millions of dollars annually from Ethereum users [ 43 ]. MEV is an artefact of global transaction ordering. Grassroots bonds have no global ordering of transactions—each person’s blocklace fragment is independent— and so MEV does not exist. Summary . Grassroots coins and bonds occupy a dierent point in the design space than global cr yptocurrencies and their DeFi instruments. Where global crypto currencies achieve trustless oper- ation thr ough consensus at the cost of high transaction fees, capital requirements, and exposure to ash-loan attacks, MEV e xtraction, and sandwich attacks, grassroots bonds achieve consensus-free operation through bilateral trust at the cost of requiring social rela- tionships for liquidity . The nancial instruments are comparable in expressiveness (Sections 3–4), but dier in their trust assumptions, cost structure, and attack surface . 8.2 Finance Here we survey additional related work: trust-based lending, infor- mal community nance, digital social contracts, nancial contract specication, credit networks, IOU-based currencies, mutual credit systems, tokenised bonds, o-chain payment protocols, and mone- tary theor y . Micronance and peer-to-pe er lending. The Grameen Bank model demonstrated that trust-based, collateral-free lending can work at scale via group liability [ 37 ]. Online peer-to-peer lending platforms extended this principle digitally: Lin et al. [ 33 ] showed that friendship networks on Prosper .com function as credible credit signals, incr easing funding probability and pr edicting lo wer default rates; Iyer et al. [ 26 ] found that peer lenders predict defaults 45% more accurately than credit scores. Grassr oots bonds formalise this trust infrastructur e into tradeable instruments: where micronance relies on group liability and P2P platforms on centralised match- ing, grassroots bonds encode bilateral trust directly as bond swaps, with creditworthiness assessable via the liquidity measures of Sec- tion 5. This is relevant to nancial inclusion: the W orld Bank Global Findex [ 15 ] estimates that 1.4 billion adults worldwide lack access to formal nancial ser vices, often in communities where mutual trust is abundant but capital is scarce—precisely the conditions under which grassroots bonds can b ootstrap a local digital economy [ 50 ]. Informal community nance. Rotating savings and credit asso- ciations (ROSCAs)—known as chit funds, tontines, or susus across cultures—are the dominant informal nancial instrument in devel- oping economies. Besley et al. [ 3 ] proved formally that both random and bidding ROSCAs yield higher utility than autarky by enabling earlier access to indivisible go ods through community-based mutual commitment, without formal institutions. Ar dener [ 2 ] pro vided the foundational cross-cultural survey documenting their global preva- lence. Hawala networks [ 17 ] transfer value across borders on pure trust, without formal banking infrastructur e. All thr ee—ROSCAs, hawala, and grassr oots bonds—share the same foundation: bilateral trust within a community substitutes for institutional intermedia- tion. Grassroots bonds can be vie wed as a digital formalisation that extends these informal mechanisms with the full expressiveness of a bond market. Digital social contracts. Szab o [ 53 ] introduced smart contracts as digitally-specied agreements with automated enforcement. Blo ckchain smart contracts realise this vision via consensus-bound execution. 8 Grassroots Bonds Cardelli et al. [ 9 ] introduced digital social contracts as an alter- native: transition systems with agents performing digital spee ch acts, sp ecied by a state-transducer language. Our denition r enes theirs: a digital social contract is a voluntary agreement among persons, specied, fullled, and enforced digitally . Each nancial in- strument in Se ction 3 is a digital social contract—a v olitional atomic transaction specifying conditions on the swap of grassroots b onds. Digital social contracts are thus the grassr oots analogue of smart contracts: they achiev e the same function ( automated agreement enforcement) without blockchain infrastructure. Financial contract specication. The foundational work on com- posable nancial contract specication predates blockchain: Peyton Jones et al. [ 41 ] introduced a combinator library for describing - nancial contracts declaratively , inspiring subse quent blockchain domain-specic languages. Marlowe [ 30 ], Cardano ’s nancial con- tract DSL, sp ecies instruments declaratively with exhaustiv e static analysis; Scilla [ 47 ] introduced automata-based contracts with for- mal safety guarantees. These languages demonstrate that nan- cial instruments can be specied declaratively , yet they compile to consensus-bound smart contracts. Grassroots bonds take the same declarative approach—each instrument is a volitional atomic transaction (Section 2.1)—but enforce it bilaterally rather than via consensus, with each sovereign guaranteeing the security of trans- actions in their currency [32]. Credit networks. Credit networks [ 14 ] study liquidity in networks of bilateral credit lines, with chain payments as the key instrument. Grassroots currencies inherit this structure: mutual credit lines formed via coin exchange, together with coin redemption, provide for chain payments as in credit networks [ 50 ]. Much of the body of knowledge regarding liquidity in credit networks carries over to grassroots bonds, with the caveat that lack of liquidity not only causes chain payment failures but also devalues the currencies of the liquidity-constrained parties involved. IOU credit networks and personal currencies. Fugger’s pro- posal that money can b e represented as IOUs in social trust net- works [ 19 ] is the earliest articulation of the idea underlying grass- roots currencies. Ripple [ 46 ] implemented IOU-based credit routing on a blockchain, but re-introduced global consensus. SilentWhis- pers [ 34 ] pr oposed a distribute d, privacy-pr eserving credit network that requires no ledger—the closest prior work to fully consensus- free nancial transactions—but it addresses only payment routing, not the richer nancial instruments that grassroots bonds sup- port. Grassroots currencies [ 50 ] implement Fugger’s vision without blockchain: personal coins are IOUs traded via bilateral transac- tions, with coin redemption pegging mutually-liquid currencies at 1:1. Grassroots bonds extend this by adding maturity dates, enabling interest-bearing credit. Mutual credit and community currencies. Mutual credit sys- tems are the closest precedent to grassroots bonds’ approach. Sardex, a mutual credit network in Sardinia, achieves signicant real-economy impact; its cyclic transaction structure has been analysed in Na- ture Human Behaviour [ 25 ]. The Sarafu community currency in Kenya [ 35 ], operated on blockchain, is an academically-studied dig- ital community currency deployment. Both systems cr eate liquidity from bilateral trust without external capital—the same principle underlying grassroots bonds—but Sardex relies on a centralise d operator and Sarafu on blockchain consensus. Circles UBI [ 12 ] implements blockchain-based personal curren- cies with a trust-network-mediated exchange rate , structurally sim- ilar to grassr oots coin r edemption among trusting parties; how ever , Circles enforces a uniform minting rate and relies on Ethereum miners for execution. The Trustlines Network [ 23 ] extends mutual credit (LETS) principles to Ethereum, resulting in mutual credit lines similar to those of grassroots currencies but re-introducing blockchain consensus. T okenised bonds on blockchain. On-chain bond issuance repre- sents the blockchain-native approach to the same pr oblem grass- roots bonds address. A Federal Reserve analysis [ 8 ] examines to- kenisation of real-world assets including the Santander (2019) and EIB (2021) bond issuances on Ethereum, identifying smart contract designs and nancial stability implications. Security token oerings (STOs) extend this trend to debt instruments more broadly [ 29 ]. These tokenised bonds and STOs dier from grassroots bonds in three respects: they require a public blockchain and its associated gas costs; they rely on custodians to bridge on-chain tokens with o-chain legal obligations; and they are issued by institutions rather than by any person. Traditional b ond instruments. The loan structures of Section 3— zero-coupon, balloon, and xed-payment loans—correspond to stan- dard xed-income instruments as classied by Fabozzi [ 18 ]. The escrow-based instruments of Section 4—collateral, guarantees, and options—likewise have standard counterparts. Grassroots bonds dier from traditional bonds not in their nancial structure but in three respects: they are issued by any person rather than by insti- tutions, traded bilaterally rather than on exchanges, and enforced bilaterally rather than by legal contract. The economic eect is to democratise access to the b ond market: any person can issue, hold, and trade bonds, with the community bank scenario of Section 6 illustrating how a village can achieve the nancial functionality of a bank using only grassroots bonds. Payment and state channels. Layer-2 scaling solutions reduce but do not eliminate reliance on blo ckchain consensus [ 21 ]. Pay- ment channels such as the Lightning Network [ 42 ] enable o-chain bilateral transactions but fall back to the blockchain for dispute resolution. State channels [ 16 ] generalise this to arbitrary state tran- sitions. Boyen et al. [ 4 ] proposed blockchain-free cr yptocurrencies using a D A G structure , a prior attempt at the same design goal as grassroots currencies. Grassroots bonds’ bilateral transactions re- semble state channel updates in structur e, but dier fundamentally: state channels derive their security from the ability to publish the latest state on-chain in case of dispute, while grassroots bonds de- rive theirs from bilateral enforcement with no blockchain fallback. The atomic swap mechanism underlying grassroots bond transac- tions is related to cross-chain atomic swaps [ 24 ], which achieve trustless exchange across blockchains; grassroots bonds achieve the same atomicity bilaterally , without any blo ckchain. Monetary theor y . Grassroots bonds create inside money [ 10 , 11 ]—a medium of exchange backed by private credit rather than sover- eign authority . Cavalcanti and W allace [ 11 ] studied a population of bankers and nonbankers: bankers’ nancial histories are public, enabling punishment for deviation, while nonbankers’ histories 9 Ehud Shapiro are private, making notes an essential me dium of exchange. In grassroots currencies, ev eryone is between a banker and a non- banker [ 50 ]: nancial records are not public, but the holder of another person’s coins can choose which coin or bond to redeem against it among those held by the other person, requiring the coin holder to have access to such knowledge. Kocherlakota’s result that “money is memory” [ 28 ] is directly relevant: grassroots bonds replace monetary tokens with crypto- graphic records of bilateral obligations, with agents holding the distributed memory that makes money possible. The Bank of Eng- land’s account of how commercial banks cr eate money through lending [ 36 ] describes a process structurally analogous to grass- roots bond issuance: in both cases, the act of lending simultaneously creates both an asset (the loan) and a liability (the deposit or bond). The theoretical foundation for such endogenous money creation through credit is established by Palley [ 40 ]. Brunnermeier et al. [ 6 ] provide a comprehensive framework conne cting inside/outside money , token/account forms, and digital currency competition, within which grassroots bonds occupy a distinctive position as peer-issued, record-based inside money operating without either sovereign backing or blockchain consensus. Finally , Mundell’s the- ory of optimum currency areas [ 38 ] is relevant to the regional bank and currency recognition me chanisms of Section 6, which allow grassroots currency ar eas to form and merge b ottom-up rather than top-down. 9 Conclusion Grassroots bonds extend grassroots coins [ 50 ] with maturity dates, reframing coins—cash—as mature bonds. The entire specication reduces to two volitional transactions—mint and swap—from which the full gamut of nancial instruments emerges as conditions on bond swaps, including credit lines, loans, sale of debt, for ward contracts, options, and escrow-based instruments. Classical liquid- ity ratios apply to grassroots bonds, and the protocol is formally grassroots (Appendix A): independent deployments can emerge and inter operate without global r esources. The formal specication was used by AI to derive a working implementation in GLP [ 51 ]. A secure grassroots implementation of grassroots coins has been presented previously [ 32 ]. It applies directly to unilateral b ond transactions (mint, pay , redeem); voluntary swaps between two parties employ bilateral atomic commitment, with escrow (Sec- tion 4) as a non-blocking alternativ e. Integrating these mechanisms in a secure implementation of GLP is a subject of ongoing work. References [1] Sumit Agarwal, Shashwat Alok, Pulak Ghosh, Soumya Ghosh, T omasz Piskorski, and Amit Seru. 2017. Banking the unbanked: What do 255 million new bank accounts reveal about nancial access? Columbia Business School Research Paper 17-12 (2017). [2] Shirley Ardener . 1964. The Comparative Study of Rotating Credit Associations. The Journal of the Royal A nthropological Institute of Great Britain and Ireland 94, 2 (1964), 201–229. doi:10.2307/2844382 [3] Timothy Besley , Stephen Coate, and Glenn Loury . 1993. The Economics of Rotating Savings and Credit Associations. A merican Economic Review 83, 4 (1993), 792–810. [4] Xavier Boyen, Christopher Carr , and Thomas Haines. 2016. Blo ckchain-Free Cryptocurrencies: A Frame work for Truly Decentralised Fast Transactions. Cryp- tology ePrint Archive, Rep ort 2016/871. Also publishe d as “Graphchain” at BCC@A siaCCS 2018. [5] Miriam Bruhn and Inessa Love. 2009. The economic impact of banking the unbanked: evidence from Mexico. W orld bank policy research working paper 4981 (2009). [6] Markus K. Brunnermeier, Harold James, and Jean-Pierre Landau. 2019. The Digitalization of Money . W orking Paper 26300. National Bureau of Economic Research. doi:10.3386/w26300 [7] Vitalik Buterin. 2014. A next-generation smart contract and decentralized appli- cation platform. white paper 3, 37 (2014). [8] Francesca Carapella, Grace Chuan, Jacob Gerszten, Chelsea Hunter , and Nathan Swem. 2023. T okenization: Overview and Financial Stability Implications . Finance and Economics Discussion Series 2023-060. Board of Governors of the Federal Reserve System. doi:10.17016/FEDS.2023.060r1 [9] Luca Cardelli, Liav Orgad, Gal Shahaf, Ehud Shapiro, and Nimrod T almon. 2020. Digital social contracts: A foundation for an egalitarian and just digital society . In CEUR Proceedings of the First International Forum on Digital and Democracy , V ol. 2781. CEUR-WS, 51–60. [10] Ricardo de O Cavalcanti and Neil W allace. 1999. Inside and outside money as alternative media of exchange. Journal of Money , Credit and Banking (1999), 443–457. [11] Ricardo de O Cavalcanti and Neil W allace. 1999. A model of private bank-note issue. Review of Economic Dynamics 2, 1 (1999), 104–136. [12] Circles. Retriev ed 2021 https://joincir cles.net/. Circles: A decentralised Universal Basic Income platform based on personal currencies. [13] Philip Daian, Steven Goldfeder , T yler Kell, Y unqi Li, Xueyuan Zhao, Iddo Ben- tov , Lorenz Breidenbach, and Ari Juels. 2020. Flash Boys 2.0: Frontrunning in De centralized Exchanges, Miner Extractable V alue , and Consensus Insta- bility . In 2020 IEEE Symposium on Se curity and Privacy (SP) . IEEE, 910–927. doi:10.1109/SP40000.2020.00040 [14] Pranav Dandekar , Ashish Goel, Ramesh Govindan, and Ian Post. 2011. Liquidity in credit networks: A little trust goes a long way . In Proceedings of the 12th ACM conference on Electronic commerce . 147–156. [15] Asli Demirgüç-Kunt, Leora Klapper, Dorothe Singer , and Saniya Ansar . 2022. The Global Findex Database 2021: Financial Inclusion, Digital Payments, and Resilience in the Age of CO VID-19 . W orld Bank. doi:10.1596/978- 1- 4648- 1897- 4 [16] Stefan Dziembowski, Lisa Eckey , Sebastian Faust, and Daniel Malinowski. 2018. General state channel networks. In Proceedings of the 2018 ACM SIGSAC Confer- ence on Computer and Communications Se curity . 949–966. [17] Mohammed El Qorchi, Samuel Munzele Maimbo, and John F. Wilson. 2003. Informal Funds Transfer Systems: An A nalysis of the Informal Hawala System . Number 222 in IMF Occasional Paper . International Monetary Fund. [18] Frank J. Fabozzi and Francesco A. Fab ozzi. 2021. Bond Markets, A nalysis, and Strategies (10th ed.). MIT Press. [19] Ryan Fugger . 2004. Money as IOUs in social trust networks & a proposal for a decentralized currency network protocol. Hypertext document. A vailable elec- tronically at http://ripple. sourceforge. net 106 (2004). [20] Jim Gray . 1981. The Transaction Concept: Virtues and Limitations. Proceedings of the 7th International Conference on V er y Large Data Bases (1981), 144–154. [21] Lewis Gudgeon, Pedro Moreno-Sanchez, Stefanie Roos, Patrick McCorry, and Arthur Gervais. 2020. SoK: Layer- T wo Blockchain Protocols. In Financial Cryp- tography and Data Security (FC 2020) (LNCS, V ol. 12059) . Springer, 201–226. doi:10.1007/978- 3- 030- 51280- 4_12 [22] Lewis Gudgeon, Sam M. W erner, Daniel Perez, and William J. Knottenbelt. 2020. DeFi Protocols for Loanable Funds: Interest Rates, Liquidity and Market Eciency . In Proceedings of the 2nd A CM Conference on Advances in Financial T e chnologies (AFT ’20) . ACM, 92–112. doi:10.1145/3419614.3423254 [23] Heiko Hees, Gustav Friis, Kristoer Naerland, Aleeza Howitt, T atu Kärki, and Andreas Fletcher . 2021, https://docs.trustlines.network/assets/pdf/Trustlines_Network_ Whitepaper_2021.pdf. Trustlines Network White Paper . [24] Maurice Herlihy . 2018. Atomic cross-chain swaps. In Proceedings of the 2018 ACM symposium on principles of distributed computing . 245–254. [25] George Iosidis, Y anick Charette , Edoardo Airoldi, Giuseppe Littera, Leandros T assiulas, and Nicholas Christakis. 2018. Cyclic Motifs in the Sardex Monetary Network. Nature Human Behaviour 2 (2018), 822–829. doi:10.1038/s41562- 018- 0450- 0 [26] Rajkamal Iyer , Asim Ijaz Khwaja, Erzo F . P. Luttmer , and Kelly Shue. 2016. Screen- ing Peers Softly: Inferring the Quality of Small Borrowers. Management Science 62, 6 (2016), 1554–1577. doi:10.1287/mnsc.2015.2181 [27] Idit Keidar , Andrew Lewis-Pye, and Ehud Shapiro. 2025. Constitutional Consen- sus. [28] Narayana R Kocherlakota. 1998. Money is memory. Journal of economic theor y 81, 2 (1998), 232–251. [29] Thomas Lambert, Daniel Liebau, and Peter Roosenboom. 2022. Se curity T oken Oerings. Small Business Economics 59 (2022), 299–325. doi:10.1007/s11187- 021- 00539- 9 [30] Pablo Lamela Seijas and Simon Thompson. 2018. Marlowe: Financial Contracts on Blockchain. In Leveraging A pplications of Formal Methods, V erication and V alidation (ISoLA 2018) (LNCS, V ol. 11247) . Springer , 356–375. doi:10.1007/978- 3- 030- 03427- 6_27 10 Grassroots Bonds [31] Robert Leshner . 2020. Compound Governance. Blog post, Compound Labs. https://medium.com/compound- nance/compound- governance- 5531f524cf68 [32] Andrew Lewis-Pye, Oded Naor, and Ehud Shapiro. 2023. Grassroots Flash: A Payment System for Grassroots Cryptocurrencies. arXiv preprint (2023). [33] Mingfeng Lin, Nagpurnanand R. Prabhala, and Siva Viswanathan. 2013. Judging Borrowers by the Company The y Keep: Friendship Netw orks and Information Asymmetry in Online Peer-to-Peer Lending. Management Science 59, 1 (2013), 17–35. doi:10.1287/mnsc.1120.1560 [34] Giulio Malavolta, Pedro Moreno-Sanchez, Aniket Kate, and Matteo Maei. 2017. SilentWhispers: Enforcing Security and Privacy in Decentralized Credit Net- works. In Proceedings of the Network and Distributed System Security Symposium (NDSS 2017) . Internet Society . [35] Carolina E. S. Mattsson, T eodoro Criscione, and William O. Ruddick. 2022. Sarafu Community Inclusion Currency 2020–2021. Scientic Data 9 (2022), 426. doi:10. 1038/s41597- 022- 01539- 4 [36] Michael McLeay , Amar Radia, and Ryland Thomas. 2014. Money Creation in the Modern Economy . Bank of England Quarterly Bulletin Q1 (2014), 14–27. [37] Jonathan Morduch. 1999. The Micronance Promise. Journal of Economic Literature 37, 4 (1999), 1569–1614. doi:10.1257/jel.37.4.1569 [38] Robert A Mundell. 1961. A theory of optimum currency areas. The A merican economic review 51, 4 (1961), 657–665. [39] Satoshi Nakamoto and A Bitcoin. 2008. A pe er-to-peer electronic cash system. Bitcoin.–URL: https://bitcoin. org/bitcoin. pdf 4 (2008). [40] Thomas I. Palley . 2002. Endogenous Money: What It Is and Why It Matters. Metroeconomica 53, 2 (2002), 152–180. [41] Simon Peyton Jones, Jean-Marc Eber , and Julian Seward. 2000. Comp osing Con- tracts: An Adventure in Financial Engineering (Functional Pearl). In Proceedings of the 5th ACM SIGPLAN International Conference on Functional Programming (ICFP ’00) . ACM, 280–292. doi:10.1145/351240.351267 [42] Joseph Poon and Thaddeus Dryja. 2016. The bitcoin lightning network: Scal- able o-chain instant payments. Draft version 0.5.9.2 (2016). https://lightning. network/lightning- network- paper .pdf [43] Kaihua Qin, Liyi Zhou, and Arthur Gervais. 2022. Quantifying Blockchain Extractable V alue: How Dark is the Forest? . In 2022 IEEE Symposium on Security and Privacy (SP) . IEEE, 198–214. doi:10.1109/SP46214.2022.9833734 [44] Kaihua Qin, Liyi Zhou, Benjamin Livshits, and Arthur Gervais. 2021. Attacking the DeFi Ecosystem with Flash Loans for Fun and Prot. In Financial Cryptogra- phy and Data Se curity – 25th International Conference, FC 2021 . Springer , 3–32. doi:10.1007/978- 3- 662- 64322- 8_1 [45] Fabian Schär . 2021. Decentralize d Finance: On Blockchain- and Smart Contract- Based Financial Markets. Federal Reserve Bank of St. Louis Review 103, 2 (2021), 153–174. doi:10.20955/r .103.153- 74 [46] David Schwartz, Noah Y oungs, and Arthur Britto. 2014. The Ripple protocol consensus algorithm. Ripple Labs White Paper (2014). [47] Ilya Sergey, Amrit Kumar , and Aquinas Hobor . 2019. Scilla: a smart contract intermediate-level language . In Pr oceedings of the 40th ACM SIGPLAN Conference on Programming Language Design and Implementation . ACM, 366–381. [48] Ehud Shapiro. 2023. Grassroots Distributed Systems: Concept, Examples, Imple- mentation and Applications (Brief Announcement). In 37th International Sympo- sium on Distributed Computing (DISC 2023). (Extende d version: arXiv:2301.04391) . LIPICS, Italy , 47:1, 47:7. [49] Ehud Shapiro. 2024. A Grassroots Architecture to Supplant Global Digital Plat- forms by a Global Digital Demo cracy . arXiv:2404.13468, Proceedings of DA W O’24 (2024). [50] Ehud Shapiro. 2024. Grassroots Currencies: Foundations for Grassroots Digital Economies. arXiv preprint arXiv:2202.05619 (2024). [51] Ehud Shapiro. 2025. GLP: A Grassroots, Multiagent, Concurrent, Logic Program- ming Language. arXiv preprint arXiv:2510.15747 (2025). [52] Ehud Shapiro. 2026. Grassroots Platforms with Atomic Transactions: Social Graphs, Cryptocurrencies, and Democratic Federations. In Proce edings of the 27th International Conference on Distributed Computing and Networking . 71–81. doi:10.1145/3772290.3772309 arXiv preprint [53] Nick Szabo. 1997. Formalizing and Securing Relationships on Public Networks. [54] Sam M. W erner , Daniel Perez, Lewis Gudgeon, Ariah Klages-Mundt, Dominik Harz, and William J. Knottenbelt. 2022. SoK: Decentralized Finance (DeFi). In Proceedings of the 4th ACM Conference on Advances in Financial Technologies (AFT ’22) . ACM, 446–461. doi:10.1145/3558535.3559780 [55] Gavin W oo d. 2014. Ethereum: A secure decentralised generalised transaction ledger . [56] Liyi Zhou, Xihan Xiong, Jens Ernstberger , Stefanos Chaliasos, Zhipeng W ang, Y e W ang, K aihua Qin, Roger W attenhofer, Dawn Song, and Arthur Gervais. 2023. SoK: Decentralized Finance (DeFi) Attacks. In 2023 IEEE Symposium on Security and Privacy (S&P) . IEEE. doi:10.1109/SP46215.2023.10179435 A Mathematical Foundations This appendix collects the formal denitions underlying the grass- roots framework. The denitions of congurations, transactions, ac- tive and stationary participants, and volitional transactions appear in Section 2.1; here we provide the additional machiner y neede d to dene grassroots protocols and state the main theorem that the grassroots bonds protocol is grassroots. A.1 Transition Systems Denition A.1 (Transition System, Computation, Run). A tran- sition system is a tuple 𝑇 𝑆 = ( 𝑆 , 𝑠 0 , 𝑇 ) , where 𝑆 is an arbitrary non-empty set of states , 𝑠 0 ∈ 𝑆 is the designated initial state , and 𝑇 ⊂ 𝑆 2 is a set of transitions , wher e each transition 𝑡 ∈ 𝑇 is a pair ( 𝑠 , 𝑠 ′ ) of non-identical states 𝑠 ≠ 𝑠 ′ ∈ 𝑆 , also written as 𝑡 = 𝑠 → 𝑠 ′ . A computation of 𝑇 𝑆 is a (nonempty , p otentially innite) sequence of states 𝑟 = 𝑠 1 , 𝑠 2 , · · · such that for every two consecutive states 𝑠 𝑖 , 𝑠 𝑖 + 1 ∈ 𝑟 , 𝑠 𝑖 → 𝑠 𝑖 + 1 ∈ 𝑇 . If 𝑠 1 = 𝑠 0 then the computation is called a run of 𝑇 𝑆 . Denition A.2 (Degree). The degree of a transaction 𝑡 (unary , binary , . . . , 𝑘 -ary) is the number of active participants in 𝑡 , and the degree of a set of transactions 𝑇 is the maximal degree of any 𝑡 ∈ 𝑇 . Denition A.3 (Multiagent Transition System). Given agents 𝑃 ⊂ Π and an arbitrar y set 𝑆 of local states with a designated initial local state 𝑠 0 ∈ 𝑆 , a multiagent transition system over 𝑃 and 𝑆 is a tran- sition system (Denition A.1) 𝑇 𝑆 = ( 𝐶, 𝑐 0 , 𝑇 ) with congurations 𝐶 : = 𝑆 𝑃 , initial conguration 𝑐 0 : = { 𝑠 0 } 𝑃 , and transitions 𝑇 ⊆ 𝐶 2 being a set of transactions over 𝑃 and 𝑆 . A.2 Transaction Closure and Transactions-Based Systems Denition A.4 (Transaction Closure). Let 𝑃 ⊂ Π , 𝑆 a set of local states, and 𝐶 : = 𝑆 𝑃 . For a transaction 𝑡 = ( 𝑐 → 𝑐 ′ ) over local states 𝑆 with participants 𝑄 ⊆ 𝑃 , the 𝑃 -closure of 𝑡 , 𝑡 ↑ 𝑃 , is the set of transitions over 𝑃 and 𝑆 dene d by: 𝑡 ↑ 𝑃 : = { 𝑡 ′ ∈ 𝐶 2 : ∀ 𝑞 ∈ 𝑄 . ( 𝑡 𝑞 = 𝑡 ′ 𝑞 ) ∧∀ 𝑝 ∈ 𝑃 \ 𝑄 . ( 𝑝 is stationary in 𝑡 ′ ) } If 𝑅 is a set of transactions, each 𝑡 ∈ 𝑅 over some 𝑄 ⊆ 𝑃 and 𝑆 , then the 𝑃 -closure of 𝑅 , 𝑅 ↑ 𝑃 : = Ð 𝑡 ∈ 𝑅 𝑡 ↑ 𝑃 . Denition A.5 (Transactions-Based Multiagent Transition System). Given agents 𝑃 ⊂ Π , local states 𝑆 with initial local state 𝑠 0 ∈ 𝑆 , and a set of transactions 𝑅 , each 𝑡 ∈ 𝑅 over some 𝑄 ⊆ 𝑃 and 𝑆 , the transactions-based multiagent transition system over 𝑃 , 𝑆 , and 𝑅 is the multiagent transition system 𝑇 𝑆 = ( 𝑆 𝑃 , { 𝑠 0 } 𝑃 , 𝑅 ↑ 𝑃 ) . A.3 Protocols and the Grassroots Property A protocol is a family of multiagent transition systems, one for each set of agents 𝑃 ⊂ Π , which share an underlying set of local states S with a designated initial state 𝑠 0 . Denition A.6 (Local-States Function). A local-states function 𝑆 : 2 Π → 2 S maps every set of agents 𝑃 ⊂ Π to a set of local states 𝑆 ( 𝑃 ) ⊂ S that includes 𝑠 0 and satises 𝑃 ⊂ 𝑃 ′ ⊂ Π = ⇒ 𝑆 ( 𝑃 ) ⊂ 𝑆 ( 𝑃 ′ ) . Given a local-states function 𝑆 , we use 𝐶 to denote congurations over 𝑆 , with 𝐶 ( 𝑃 ) : = 𝑆 ( 𝑃 ) 𝑃 and 𝑐 0 ( 𝑃 ) : = { 𝑠 0 } 𝑃 . 11 Ehud Shapiro Denition A.7 (Protocol). A protocol F over a local-states func- tion 𝑆 is a family of multiagent transition systems that has exactly one transition system F ( 𝑃 ) = ( 𝐶 ( 𝑃 ) , 𝑐 0 ( 𝑃 ) , 𝑇 ( 𝑃 ) ) for every 𝑃 ⊂ Π . Denition A.8 (Projection). Let ∅ ⊂ 𝑃 ⊂ 𝑃 ′ ⊂ Π . If 𝑐 ′ is a cong- uration over 𝑃 ′ then 𝑐 ′ / 𝑃 , the projection of 𝑐 ′ over 𝑃 , is the congu- ration 𝑐 over 𝑃 dened by 𝑐 𝑝 : = 𝑐 ′ 𝑝 for every 𝑝 ∈ 𝑃 . Note that 𝑐 𝑝 , the state of 𝑝 in 𝑐 , is in 𝑆 ( 𝑃 ′ ) , not in 𝑆 ( 𝑃 ) , and hence may include elements “alien” to 𝑃 , e.g., bonds issued by 𝑞 ∈ 𝑃 ′ \ 𝑃 . Denition A.9 (Oblivious, Interactive, Grassroots). A protocol F is: (1) oblivious if for every ∅ ⊂ 𝑃 ⊂ 𝑃 ′ ⊆ Π , 𝑇 ( 𝑃 )↑ 𝑃 ′ ⊆ 𝑇 ( 𝑃 ′ ) . (2) interactive if for every ∅ ⊂ 𝑃 ⊂ 𝑃 ′ ⊆ Π and every conguration 𝑐 ∈ 𝐶 ( 𝑃 ′ ) such that 𝑐 / 𝑃 ∈ 𝐶 ( 𝑃 ) , there is a computation 𝑐 ∗ − → 𝑐 ′ of F ( 𝑃 ′ ) for which 𝑐 ′ / 𝑃 ∉ 𝐶 ( 𝑃 ) . (3) grassroots if it is oblivious and interactive. Being oblivious implies that if a run of F ( 𝑃 ′ ) reaches some conguration 𝑐 ′ , then anything 𝑃 could do on their own in the conguration 𝑐 ′ / 𝑃 (with a transition from 𝑇 ( 𝑃 ) ), they can still do in the larger conguration 𝑐 ′ (with a transition from 𝑇 ( 𝑃 ′ ) ), eectively being oblivious to members of 𝑃 ′ \ 𝑃 . Being interactive is a weak liveness requirement: no matter what members of 𝑃 do, if they run within a larger set of agents it is always the case that they can eventually interact with non- 𝑃 ’s in a way that leaves “alien traces” in the local states of 𝑃 , so that the resulting conguration 𝑐 ′ / 𝑃 could not have been produced by 𝑃 running on their own. A.4 Transactions-Based Grassroots Protocols Denition A.10 (Transactions Over a Local-States Function). Let 𝑆 be a local-states function. A set of transactions 𝑅 is over 𝑆 if every transaction 𝑡 ∈ 𝑅 is a multiagent transition over 𝑄 and 𝑆 ( 𝑄 ′ ) for some 𝑄 ⊆ 𝑄 ′ ⊂ Π . Given such a set 𝑅 and 𝑃 ⊂ Π , 𝑅 ( 𝑃 ) : = { 𝑡 ∈ 𝑅 : 𝑡 is over 𝑄 and 𝑆 ( 𝑄 ′ ) , 𝑄 ⊆ 𝑄 ′ ⊆ 𝑃 } . Denition A.11 (Transactions-Based Protocol). Let 𝑆 be a local- states function and 𝑅 a set of transactions over 𝑆 . Then a protocol F over 𝑅 and 𝑆 includes for each set of agents 𝑃 ⊂ Π the transactions- based multiagent transition system F ( 𝑃 ) over 𝑃 , 𝑆 ( 𝑃 ) , and 𝑅 ( 𝑃 ) : F ( 𝑃 ) : = ( 𝑆 ( 𝑃 ) 𝑃 , { 𝑠 0 } 𝑃 , 𝑅 ( 𝑃 ) ↑ 𝑃 ) . Denition A.12 (Interactive Transactions). A set of transactions 𝑅 over a local-states function 𝑆 is interactive if for every ∅ ⊂ 𝑃 ⊂ 𝑃 ′ ⊂ Π and every conguration 𝑐 ∈ 𝐶 ( 𝑃 ′ ) such that 𝑐 / 𝑃 ∈ 𝐶 ( 𝑃 ) , there is a computation ( 𝑐 ∗ − → 𝑐 ′ ) ⊆ 𝑅 ( 𝑃 ′ ) ↑ 𝑃 ′ for which 𝑐 ′ / 𝑃 ∉ 𝐶 ( 𝑃 ) . Proposition A.13 ([ 52 , Proposition 1]). A transactions-base d protocol is oblivious. Theorem A.14 ([ 52 , Theorem 1]). A protocol over an interactive set of transactions is grassroots. A.5 Grassroots Bonds Are Grassroots Corollary A.15. The grassroots b onds protocol (Denition 2.3) is grassroots. The argument is straightforward: the grassroots bonds transac- tions are interactive . Given 𝑃 ⊂ 𝑃 ′ and a conguration 𝑐 in which all bonds held by members of 𝑃 are issued by members of 𝑃 , a voluntary swap between 𝑝 ∈ 𝑃 and 𝑞 ∈ 𝑃 ′ \ 𝑃 produces 𝑞 -bonds in 𝑝 ’s state—an alien trace that could not have been produced by 𝑃 running on their own. W e note that the GLP implementation (Section 7) extends the bonds transactions with the grassroots social graph [ 52 ] and direct messaging, as specied in [ 52 ] and implemented in [ 51 ]. These extensions preserve the grassroots property: the social graph is itself grassroots [ 52 ], and direct messaging between friends does not alter the local states used for the grassroots argument. B Bond Agent Source Code The bond agent implementation consists of two GLP mo dules: self.glp , which denes all shared typ es and helper procedures visible to all modules via ancestor scoping; and agent.glp , which denes the bond agent and its local procedures. T ogether the y com- prise approximately 740 lines of typed GLP code. The full source , including the UI mediator , twelve test scenarios, and the six village market actors, is available at https://github.com/EShapiro2/GLP- Bonds. Module 1: Shared T ypes and Help ers ( self.glp ) %% self.glp — Bonds V2 shared type vocabulary %% %% All protocol types for the Grassroots Bonds application. %% Defined once here, visible to all modules via ancestor scoping. -module(bonds). -mode(system). %% Stream(X) and Channel(In, Out) are predefined in prelude: %% Stream(X) ::= [] ; [X | Stream(X)]. %% Channel(In, Out) ::= ch(In, Out?). %% Bond representation: bond(Issuer, Maturity, Serial) Bond ::= bond(Constant, Constant, Constant). %% Trade types Lot ::= lot(Constant, Constant, Constant). TradeResponse ::= trade_accept(Stream(Bond)) ; trade_decline(Stream(Bond)) ; trade_decline_menu(Stream(Bond), Stream(Bond)). %% Escrow cancel signal EscrowCancel ::= cancel. %% Escrow results EscrowBenResult ::= escrow_bonds(Stream(Bond)) ; escrow_cancelled. EscrowDepResult ::= escrow_bonds(Stream(Bond)) ; escrow_expired. %% Friend messages (after connection established) FriendContent ::= response(Response) ; text(Constant) ; trade_propose(Stream(Lot), Stream(Bond), TradeResponse?) ; escrow_offer(Constant, EscrowBenResult). FriendMsg ::= msg(Constant, Constant, FriendContent). FriendChannel ::= ch(Stream(FriendMsg), 12 Grassroots Bonds Stream(FriendMsg)?). Response ::= accept(FriendChannel) ; no. Decision ::= yes ; no. %% Network content (2-arg cold-call) NetColdCall ::= intro(Constant, Response?). %% User-to-agent message content UserContent ::= mint(Constant, Constant) ; balance ; done ; connect(Constant) ; decision(Decision, Constant, PendingValue) ; response(Response) ; trade(Constant, Stream(Lot), Stream(Lot)) ; accept_trade(Constant, PendingValue) ; reject_trade(Constant, PendingValue) ; deposit_escrow(Constant, Stream(Lot), Constant) ; cancel_escrow(Constant, PendingValue). %% Pending values stored by mediator PendingValue ::= response(Response?) ; trade_pending(TradeResponse?, Stream(Lot), Stream(Bond)) ; escrow_pending(EscrowCancel?) ; error. %% Agent-to-user message content AgentContent ::= minted(Constant, Constant) ; balance_report(Stream(Bond)) ; befriend(Constant, Response?) ; connected(Constant) ; rejected ; rejected(Constant) ; trade_proposed(Constant, Stream(Lot), TradeResponse?, Stream(Bond)) ; trade_completed(Constant) ; trade_failed(Constant) ; trade_returned(Constant) ; escrow_deposited(Constant, Constant, EscrowCancel?) ; escrow_received(Constant, Constant) ; escrow_released(Constant) ; escrow_cancelled(Constant) ; escrow_expired(Constant) ; escrow_returned(Constant) ; escrow_failed(Constant) ; trade_returned_menu(Constant, Stream(Bond)). AgentToUserMsg ::= msg(Constant, Constant, AgentContent). MediatorToAgentMsg ::= msg(Constant, Constant, UserContent). %% Network input message NetInMsg ::= msg(Constant, NetColdCall) ; msg(Constant, Constant, FriendContent). %% Agent input stream (mediator + injected results) UserInMsg ::= msg(Constant, Constant, UserContent) ; trade_complete(Constant, Stream(Bond)) ; trade_returned_bonds(Constant, Stream(Bond)) ; escrow_ben_released(Constant, Stream(Bond)) ; escrow_ben_cancelled(Constant) ; escrow_dep_expired(Constant) ; escrow_dep_returned(Constant, Stream(Bond)) ; trade_returned_bonds_menu(Constant, Stream(Bond), Stream(Bond)). %% Output types (type union of agent + friend content) OutputContent ::= AgentContent ; FriendContent. OutputMsg ::= msg(Constant, Constant, OutputContent) ; msg(Constant, NetColdCall). OutputKey ::= ' _user ' ; ' _net ' ; friend(Constant). OutputEntry ::= output(OutputKey, Stream(OutputMsg)?). AgentChannel ::= ch(Stream(AgentToUserMsg), Stream(MediatorToAgentMsg)?). %% Shared helper procedures procedure merge(Stream(X)?, Stream(X)?, Stream(X)). merge([X|Xs], Ys, [X?|Zs?]) :- merge(Ys?, Xs?, Zs). merge(Xs, [Y|Ys], [Y?|Zs?]) :- merge(Xs?, Ys?, Zs). merge([], Ys, Ys?). merge(Xs, [], Xs?). procedure lookup_send(OutputKey?, OutputMsg?, Stream(OutputEntry)?, Stream(OutputEntry)). lookup_send(Key, Msg, Outs, Outs1?) :- ground(Key?) | lookup_send_step(Key?, Msg?, Outs?, Outs1). procedure lookup_send_step(OutputKey?, OutputMsg?, Stream(OutputEntry)?, Stream(OutputEntry)). lookup_send_step(Key, Msg, [output(K, [Msg?|Out1?])|Rest], [output(K?, Out1)|Rest?]) :- Key? =?= K? | true. lookup_send_step(Key, Msg, [output(K, Out?)|Rest], [output(K?, Out)|Rest1?]) :- otherwise | lookup_send_step(Key?, Msg?, Rest?, Rest1). lookup_send_step(_, _, [], []). procedure add_output(OutputKey?, Stream(OutputMsg), Stream(OutputEntry)?, Stream(OutputEntry)). add_output(Key, Out?, Outs, [output(Key?, Out)|Outs?]). procedure close_outputs(Stream(OutputEntry)?). close_outputs([output(_, [])|Outs]) :- close_outputs(Outs?). close_outputs([]). procedure inject_msg(Response?, Constant?, Constant?, Stream(UserInMsg)?, Stream(UserInMsg)). inject_msg(Resp, Target, Id, Ys, [msg(Target?, Id?, response(Resp?))|Ys?]) :- known(Resp?) | true. inject_msg(Resp, Target, Id, [Y|Ys], [Y?|Ys1?]) :- inject_msg(Resp?, Target?, Id?, Ys?, Ys1). 13 Ehud Shapiro procedure create_bonds(Constant?, Constant?, Constant?, Constant?, Stream(Bond)). create_bonds(Issuer, Maturity, K, Serial, [bond(Issuer?, Maturity?, Serial?)|Rest?]) :- K? > 0 | K1 := K? - 1, S1 := Serial? + 1, create_bonds(Issuer?, Maturity?, K1?, S1?, Rest). create_bonds(_, _, 0, _, []). procedure append(Stream(Bond)?, Stream(Bond)?, Stream(Bond)). append([X|Xs], Ys, [X?|Zs?]) :- append(Xs?, Ys?, Zs). append([], Ys, Ys?). procedure select_bonds_exact(Constant?, Constant?, Constant?, Stream(Bond)?, Constant, Stream(Bond), Stream(Bond)). select_bonds_exact(_, _, 0, Hs, ok, [], Hs?). select_bonds_exact(Issuer, Maturity, K, [bond(I, M, S)|Rest], Status?, [bond(I?, M?, S?)|Sel?], Rem?) :- K? > 0, Issuer? =?= I?, Maturity? =?= M? | K1 := K? - 1, select_bonds_exact(Issuer?, Maturity?, K1?, Rest?, Status, Sel, Rem). select_bonds_exact(Issuer, Maturity, K, [B|Rest], Status?, Sel?, [B?|Rem?]) :- otherwise | select_bonds_exact(Issuer?, Maturity?, K?, Rest?, Status, Sel, Rem). select_bonds_exact(_, _, K, [], fail, [], []) :- K? > 0 | true. procedure select_bonds_by_spec(Stream(Lot)?, Stream(Bond)?, Constant, Stream(Bond), Stream(Bond)). select_bonds_by_spec( [lot(Issuer, Maturity, Count)|Rest], Holdings, Status?, AllSel?, FinalRem?) :- ground(Issuer?), ground(Maturity?), ground(Count?) | select_bonds_exact(Issuer?, Maturity?, Count?, Holdings?, LotStatus, LotSel, LotRem), select_by_spec_continue(LotStatus?, Rest?, LotSel?, LotRem?, Status, AllSel, FinalRem). select_bonds_by_spec([], Holdings, ok, [], Holdings?). procedure select_by_spec_continue(Constant?, Stream(Lot)?, Stream(Bond)?, Stream(Bond)?, Constant, Stream(Bond), Stream(Bond)). select_by_spec_continue(ok, Rest, LotSel, LotRem, Status?, AllSel?, FinalRem?) :- select_bonds_by_spec(Rest?, LotRem?, Status, RestSel, FinalRem), append(LotSel?, RestSel?, AllSel). select_by_spec_continue(fail, _, LotSel, LotRem, fail, LotSel?, LotRem?). procedure bind_trade_accept(TradeResponse, Stream(Bond)?). bind_trade_accept(trade_accept(Bonds?), Bonds). procedure bind_trade_decline(TradeResponse, Stream(Bond)?). bind_trade_decline(trade_decline(Bonds?), Bonds). procedure inject_trade_result(TradeResponse?, Constant?, Stream(UserInMsg)?, Stream(UserInMsg)). inject_trade_result(trade_accept(TheirBonds), From, Ys, [trade_complete(From?, TheirBonds?)|Ys?]) :- ground(From?), ground(TheirBonds?) | true. inject_trade_result(trade_decline(OurBonds), From, Ys, [trade_returned_bonds(From?, OurBonds?)|Ys?]) :- ground(From?), ground(OurBonds?) | true. inject_trade_result( trade_decline_menu(OurBonds, Menu), From, Ys, [trade_returned_bonds_menu(From?, OurBonds?, Menu?)|Ys?]) :- ground(From?), ground(OurBonds?), ground(Menu?) | true. inject_trade_result(Resp, From, [Y|Ys], [Y?|Ys1?]) :- inject_trade_result(Resp?, From?, Ys?, Ys1). procedure classify_trade(Constant?, Stream(Lot)?, Stream(Bond)?, Constant). classify_trade(_, [], _, payment). classify_trade(Id, _, [bond(I, 0, _)], redemption) :- Id? =?= I? | true. classify_trade(_, _, _, normal) :- otherwise | true. procedure build_menu(Constant?, Stream(Bond)?, Stream(Bond)). build_menu(Id, Holdings, Menu?) :- build_menu_acc(Id?, Holdings?, [], Menu). procedure build_menu_acc(Constant?, Stream(Bond)?, Stream(Bond)?, Stream(Bond)). build_menu_acc(Id, [bond(I, _, _)|Rest], Acc, Menu?) :- Id? =?= I? | build_menu_acc(Id?, Rest?, Acc?, Menu). build_menu_acc(Id, [bond(I, M, S)|Rest], Acc, Menu?) :- otherwise | menu_update(I?, M?, S?, Acc?, Acc1), build_menu_acc(Id?, Rest?, Acc1?, Menu). build_menu_acc(_, [], Acc, Acc?). procedure menu_update(Constant?, Constant?, Constant?, Stream(Bond)?, Stream(Bond)). menu_update(I, M, S, [bond(I2, M2, _)|Rest], [bond(I2?, M?, S?)|Rest?]) :- I? =?= I2?, M? < M2? | true. menu_update(I, _, _, [bond(I2, M2, S2)|Rest], [bond(I2?, M2?, S2?)|Rest?]) :- I? =?= I2? | true. 14 Grassroots Bonds menu_update(I, M, S, [B|Rest], [B?|Rest1?]) :- otherwise | menu_update(I?, M?, S?, Rest?, Rest1). menu_update(I, M, S, [], [bond(I?, M?, S?)]). procedure escrow(Constant?, Stream(Bond)?, EscrowCancel?, EscrowBenResult, EscrowDepResult). escrow(T, Bonds, _, escrow_bonds(Bonds?), escrow_expired) :- wait_until(T?) | true. escrow(_, Bonds, cancel, escrow_cancelled, escrow_bonds(Bonds?)). procedure inject_escrow_ben_result(EscrowBenResult?, Constant?, Stream(UserInMsg)?, Stream(UserInMsg)). inject_escrow_ben_result(escrow_bonds(Bonds), From, Ys, [escrow_ben_released(From?, Bonds?)|Ys?]) :- ground(From?), ground(Bonds?) | true. inject_escrow_ben_result(escrow_cancelled, From, Ys, [escrow_ben_cancelled(From?)|Ys?]) :- ground(From?) | true. inject_escrow_ben_result(Resp, From, [Y|Ys], [Y?|Ys1?]) :- inject_escrow_ben_result(Resp?, From?, Ys?, Ys1). procedure inject_escrow_dep_result(EscrowDepResult?, Constant?, Stream(UserInMsg)?, Stream(UserInMsg)). inject_escrow_dep_result(escrow_bonds(Bonds), Target, Ys, [escrow_dep_returned(Target?, Bonds?)|Ys?]) :- ground(Target?), ground(Bonds?) | true. inject_escrow_dep_result(escrow_expired, Target, Ys, [escrow_dep_expired(Target?)|Ys?]) :- ground(Target?) | true. inject_escrow_dep_result(Resp, Target, [Y|Ys], [Y?|Ys1?]) :- inject_escrow_dep_result(Resp?, Target?, Ys?, Ys1). procedure bind_escrow_cancel(EscrowCancel). bind_escrow_cancel(cancel). procedure lookup_pending(ReqId?, PendingValue, Stream(PendingEntry)?, Stream(PendingEntry)). lookup_pending(ReqId, Val?, [pending(Id, Val) | Rest], Rest?) :- ReqId? =?= Id? | true. lookup_pending(ReqId, Val?, [P | Rest], [P? | Rest1?]) :- otherwise | lookup_pending(ReqId?, Val, Rest?, Rest1). lookup_pending(_, error, [], []). Module 2: Bond Agent ( agent.glp ) %% agent.glp — Bond agent module (v2) %% %% Exports: agent/6 %% Types and shared helpers: from self.glp -module(agent). -mode(system). %% Merge — local copy (Stream(X) subtyping limitation) procedure merge(Stream(X)?, Stream(X)?, Stream(X)). merge([X|Xs], Ys, [X?|Zs?]) :- merge(Ys?, Xs?, Zs). merge(Xs, [Y|Ys], [Y?|Zs?]) :- merge(Xs?, Ys?, Zs). merge([], Ys, Ys?). merge(Xs, [], Xs?). %% Response handling — local (calls merge) procedure bind_response(Decision?, Constant?, Response, Stream(OutputEntry)?, Stream(OutputEntry), Stream(NetInMsg)?, Stream(NetInMsg)). bind_response(yes, From, accept(RetCh?), Outs, Outs1?, In, In1?) :- new_channel(RetCh, LocalCh) | handle_response(accept(LocalCh?), From?, Outs?, Outs1, In?, In1). bind_response(no, _, no, Outs, Outs1?, In, In?) :- lookup_send( ' _user ' , msg(agent, ' _user ' , rejected), Outs?, Outs1). procedure handle_response(Response?, Constant?, Stream(OutputEntry)?, Stream(OutputEntry), Stream(NetInMsg)?, Stream(NetInMsg)). handle_response(accept(ch(FIn, FOut?)), From, Outs, Outs2?, In, In1?) :- ground(From?) | add_output(friend(From?), FOut, Outs?, Outs1), lookup_send( ' _user ' , msg(agent, ' _user ' , connected(From?)), Outs1?, Outs2), merge(In?, FIn?, In1). handle_response(no, From, Outs, Outs1?, In, In?) :- ground(From?) | lookup_send( ' _user ' , msg(agent, ' _user ' , rejected(From?)), Outs?, Outs1). %% Trade — select bonds then send or fail procedure do_trade(Constant?, Constant?, Stream(Lot)?, Stream(Lot)?, Stream(Bond)?, Stream(UserInMsg)?, Stream(NetInMsg)?, Stream(OutputEntry)?, Constant?). do_trade(Id, Target, GiveSpec, WantSpec, Holdings, UserIn, NetIn, Outs, NextSerial) :- select_bonds_by_spec(GiveSpec?, Holdings?, Status, Selected, Remaining), do_trade_result(Status?, Id?, Target?, WantSpec?, Selected?, Remaining?, UserIn?, NetIn?, Outs?, NextSerial?). procedure do_trade_result(Constant?, Constant?, Constant?, Stream(Lot)?, Stream(Bond)?, Stream(Bond)?, Stream(UserInMsg)?, Stream(NetInMsg)?, Stream(OutputEntry)?, Constant?). 15 Ehud Shapiro do_trade_result(ok, Id, Target, WantSpec, Selected, Remaining, UserIn, NetIn, Outs, NextSerial) :- lookup_send(friend(Target?), msg(Id?, Target?, trade_propose(WantSpec?, Selected?, TradeResp)), Outs?, Outs1), inject_trade_result(TradeResp?, Target?, UserIn?, UserIn1), agent(Id?, UserIn1?, NetIn?, Outs1?, Remaining?, NextSerial?). do_trade_result(fail, Id, Target, _, Selected, Remaining, UserIn, NetIn, Outs, NextSerial) :- append(Selected?, Remaining?, OrigHoldings), lookup_send( ' _user ' , msg(agent, ' _user ' , trade_failed(Target?)), Outs?, Outs1), agent(Id?, UserIn?, NetIn?, Outs1?, OrigHoldings?, NextSerial?). %% Fill trade or decline procedure handle_trade_fill(Constant?, Constant?, Constant?, TradeResponse, Stream(Bond)?, Stream(Bond)?, Stream(Bond)?, Stream(UserInMsg)?, Stream(NetInMsg)?, Stream(OutputEntry)?, Constant?). handle_trade_fill(ok, Id, From, trade_accept(Selected?), OfferedBonds, Selected, Remaining, UserIn, NetIn, Outs, NextSerial) :- append(Remaining?, OfferedBonds?, NewHoldings), lookup_send( ' _user ' , msg(agent, ' _user ' , trade_completed(From?)), Outs?, Outs1), agent(Id?, UserIn?, NetIn?, Outs1?, NewHoldings?, NextSerial?). handle_trade_fill(fail, Id, From, trade_decline(OfferedBonds?), OfferedBonds, Selected, Remaining, UserIn, NetIn, Outs, NextSerial) :- append(Selected?, Remaining?, OrigHoldings), lookup_send( ' _user ' , msg(agent, ' _user ' , trade_failed(From?)), Outs?, Outs1), agent(Id?, UserIn?, NetIn?, Outs1?, OrigHoldings?, NextSerial?). %% Trade dispatch — auto-accept vs. user decision procedure trade_dispatch(Constant?, Constant?, Constant?, Stream(Lot)?, Stream(Bond)?, TradeResponse, Stream(Bond)?, Stream(UserInMsg)?, Stream(NetInMsg)?, Stream(OutputEntry)?, Constant?). trade_dispatch(payment, Id, From, _, OfferedBonds, trade_accept([]), Holdings, UserIn, NetIn, Outs, NextSerial) :- append(Holdings?, OfferedBonds?, NewHoldings), lookup_send( ' _user ' , msg(agent, ' _user ' , trade_completed(From?)), Outs?, Outs1), agent(Id?, UserIn?, NetIn?, Outs1?, NewHoldings?, NextSerial?). trade_dispatch(redemption, Id, From, WantSpec, OfferedBonds, TradeResp?, Holdings, UserIn, NetIn, Outs, NextSerial) :- select_bonds_by_spec(WantSpec?, Holdings?, Status, Selected, Remaining), redemption_result(Status?, Id?, From?, TradeResp, OfferedBonds?, Selected?, Remaining?, UserIn?, NetIn?, Outs?, NextSerial?). trade_dispatch(normal, Id, From, WantSpec, OfferedBonds, TradeResp?, Holdings, UserIn, NetIn, Outs, NextSerial) :- lookup_send( ' _user ' , msg(agent, ' _user ' , trade_proposed(From?, WantSpec?, TradeResp, OfferedBonds?)), Outs?, Outs1), agent(Id?, UserIn?, NetIn?, Outs1?, Holdings?, NextSerial?). %% Redemption result procedure redemption_result(Constant?, Constant?, Constant?, TradeResponse, Stream(Bond)?, Stream(Bond)?, Stream(Bond)?, Stream(UserInMsg)?, Stream(NetInMsg)?, Stream(OutputEntry)?, Constant?). redemption_result(ok, Id, From, trade_accept(Selected?), OfferedBonds, Selected, Remaining, UserIn, NetIn, Outs, NextSerial) :- append(Remaining?, OfferedBonds?, NewHoldings), lookup_send( ' _user ' , msg(agent, ' _user ' , trade_completed(From?)), Outs?, Outs1), agent(Id?, UserIn?, NetIn?, Outs1?, NewHoldings?, NextSerial?). redemption_result(fail, Id, From, trade_decline_menu(OfferedBonds?, Menu?), OfferedBonds, Selected, Remaining, UserIn, NetIn, Outs, NextSerial) :- append(Selected?, Remaining?, OrigHoldings), redemption_reject(Id?, From?, OrigHoldings?, Menu, UserIn?, NetIn?, Outs?, NextSerial?). procedure redemption_reject(Constant?, Constant?, Stream(Bond)?, Stream(Bond), Stream(UserInMsg)?, Stream(NetInMsg)?, Stream(OutputEntry)?, Constant?). redemption_reject(Id, From, OrigHoldings, Menu?, UserIn, NetIn, Outs, NextSerial) :- ground(OrigHoldings?) | build_menu(Id?, OrigHoldings?, Menu), lookup_send( ' _user ' , msg(agent, ' _user ' , trade_failed(From?)), Outs?, Outs1), agent(Id?, UserIn?, NetIn?, Outs1?, OrigHoldings?, NextSerial?). %% Escrow — select bonds and create escrow or fail 16 Grassroots Bonds procedure do_deposit_escrow(Constant?, Constant?, Stream(Lot)?, Constant?, Stream(Bond)?, Stream(UserInMsg)?, Stream(NetInMsg)?, Stream(OutputEntry)?, Constant?). do_deposit_escrow(Id, Target, GiveSpec, ReleaseTime, Holdings, UserIn, NetIn, Outs, NextSerial) :- select_bonds_by_spec(GiveSpec?, Holdings?, Status, Selected, Remaining), do_deposit_escrow_result(Status?, Id?, Target?, ReleaseTime?, Selected?, Remaining?, UserIn?, NetIn?, Outs?, NextSerial?). procedure do_deposit_escrow_result(Constant?, Constant?, Constant?, Constant?, Stream(Bond)?, Stream(Bond)?, Stream(UserInMsg)?, Stream(NetInMsg)?, Stream(OutputEntry)?, Constant?). do_deposit_escrow_result(ok, Id, Target, ReleaseTime, Selected, Remaining, UserIn, NetIn, Outs, NextSerial) :- ground(Selected?) | escrow(ReleaseTime?, Selected?, CancelSignal?, BenResult, DepResult), inject_escrow_dep_result(DepResult?, Target?, UserIn?, UserIn1), lookup_send(friend(Target?), msg(Id?, Target?, escrow_offer(ReleaseTime?, BenResult?)), Outs?, Outs1), lookup_send( ' _user ' , msg(agent, ' _user ' , escrow_deposited(Target?, ReleaseTime?, CancelSignal)), Outs1?, Outs2), agent(Id?, UserIn1?, NetIn?, Outs2?, Remaining?, NextSerial?). do_deposit_escrow_result(fail, Id, Target, _, Selected, Remaining, UserIn, NetIn, Outs, NextSerial) :- append(Selected?, Remaining?, OrigHoldings), lookup_send( ' _user ' , msg(agent, ' _user ' , escrow_failed(Target?)), Outs?, Outs1), agent(Id?, UserIn?, NetIn?, Outs1?, OrigHoldings?, NextSerial?). %% Bond agent — exported entry point exported procedure agent(Constant?, Stream(UserInMsg)?, Stream(NetInMsg)?, Stream(OutputEntry)?, Stream(Bond)?, Constant?). %% Mint agent(Id, [msg( ' _user ' , Id1, mint(K, Maturity))|UserIn], NetIn, Outs, Holdings, NextSerial) :- Id? =?= Id1?, ground(K?), ground(Maturity?) | NewNextSerial := NextSerial? + K?, create_bonds(Id?, Maturity?, K?, NextSerial?, NewBonds), append(Holdings?, NewBonds?, NewHoldings), lookup_send( ' _user ' , msg(agent, ' _user ' , minted(K?, Maturity?)), Outs?, Outs1), agent(Id?, UserIn?, NetIn?, Outs1?, NewHoldings?, NewNextSerial?). %% Balance agent(Id, [msg( ' _user ' , Id1, balance)|UserIn], NetIn, Outs, Holdings, NextSerial) :- Id? =?= Id1?, ground(Holdings?) | lookup_send( ' _user ' , msg(agent, ' _user ' , balance_report(Holdings?)), Outs?, Outs1), agent(Id?, UserIn?, NetIn?, Outs1?, Holdings?, NextSerial?). %% Done agent(Id, [msg( ' _user ' , Id1, done)|_], _, Outs, _, _) :- Id? =?= Id1? | close_outputs(Outs?). %% Connect (cold call) agent(Id, [msg( ' _user ' , Id1, connect(Target))|UserIn], NetIn, Outs, Holdings, NextSerial) :- Id? =?= Id1?, ground(Target?) | lookup_send( ' _net ' , msg(Target?, intro(Id?, Resp)), Outs?, Outs1), inject_msg(Resp?, Target?, Id?, UserIn?, UserIn1), agent(Id?, UserIn1?, NetIn?, Outs1?, Holdings?, NextSerial?). %% Decision on cold-call agent(Id, [msg( ' _user ' , Id1, decision(Dec, From, response(Resp?)))|UserIn], NetIn, Outs, Holdings, NextSerial) :- Id? =?= Id1? | bind_response(Dec?, From?, Resp, Outs?, Outs1, NetIn?, NetIn1), agent(Id?, UserIn?, NetIn1?, Outs1?, Holdings?, NextSerial?). %% Cold-call response (injected) agent(Id, [msg(From, Id1, response(Resp))|UserIn], NetIn, Outs, Holdings, NextSerial) :- Id? =?= Id1? | handle_response(Resp?, From?, Outs?, Outs1, NetIn?, NetIn1), agent(Id?, UserIn?, NetIn1?, Outs1?, Holdings?, NextSerial?). %% Cold-call from network agent(Id, UserIn, [msg(Id1, intro(From, Resp?))|NetIn], Outs, Holdings, NextSerial) :- Id? =?= Id1? | lookup_send( ' _user ' , msg(agent, ' _user ' , befriend(From?, Resp)), Outs?, Outs1), agent(Id?, UserIn?, NetIn?, Outs1?, 17 Ehud Shapiro Holdings?, NextSerial?). %% Trade command agent(Id, [msg( ' _user ' , Id1, trade(Target, GiveSpec, WantSpec))|UserIn], NetIn, Outs, Holdings, NextSerial) :- Id? =?= Id1?, ground(Target?), ground(GiveSpec?), ground(WantSpec?) | do_trade(Id?, Target?, GiveSpec?, WantSpec?, Holdings?, UserIn?, NetIn?, Outs?, NextSerial?). %% Trade complete (injected — accept) agent(Id, [trade_complete(From, TheirBonds)|UserIn], NetIn, Outs, Holdings, NextSerial) :- ground(Id?), ground(From?), ground(TheirBonds?) | append(Holdings?, TheirBonds?, NewHoldings), lookup_send( ' _user ' , msg(agent, ' _user ' , trade_completed(From?)), Outs?, Outs1), agent(Id?, UserIn?, NetIn?, Outs1?, NewHoldings?, NextSerial?). %% Trade returned (injected — decline) agent(Id, [trade_returned_bonds(From, OurBonds)|UserIn], NetIn, Outs, Holdings, NextSerial) :- ground(Id?), ground(From?), ground(OurBonds?) | append(Holdings?, OurBonds?, NewHoldings), lookup_send( ' _user ' , msg(agent, ' _user ' , trade_returned(From?)), Outs?, Outs1), agent(Id?, UserIn?, NetIn?, Outs1?, NewHoldings?, NextSerial?). %% Trade returned with menu agent(Id, [trade_returned_bonds_menu(From, OurBonds, Menu)|UserIn], NetIn, Outs, Holdings, NextSerial) :- ground(Id?), ground(From?), ground(OurBonds?), ground(Menu?) | append(Holdings?, OurBonds?, NewHoldings), lookup_send( ' _user ' , msg(agent, ' _user ' , trade_returned_menu(From?, Menu?)), Outs?, Outs1), agent(Id?, UserIn?, NetIn?, Outs1?, NewHoldings?, NextSerial?). %% Incoming trade_propose agent(Id, UserIn, [msg(From, Id1, trade_propose(WantSpec, OfferedBonds, TradeResp?))|NetIn], Outs, Holdings, NextSerial) :- Id? =?= Id1?, ground(From?), ground(WantSpec?), ground(OfferedBonds?) | classify_trade(Id?, WantSpec?, OfferedBonds?, TradeClass), trade_dispatch(TradeClass?, Id?, From?, WantSpec?, OfferedBonds?, TradeResp, Holdings?, UserIn?, NetIn?, Outs?, NextSerial?). %% Accept trade agent(Id, [msg( ' _user ' , Id1, accept_trade(From, trade_pending(TradeResp?, WantSpec, OfferedBonds)))|UserIn], NetIn, Outs, Holdings, NextSerial) :- Id? =?= Id1?, ground(From?), ground(WantSpec?), ground(OfferedBonds?) | select_bonds_by_spec(WantSpec?, Holdings?, Status, Selected, Remaining), handle_trade_fill(Status?, Id?, From?, TradeResp, OfferedBonds?, Selected?, Remaining?, UserIn?, NetIn?, Outs?, NextSerial?). %% Reject trade agent(Id, [msg( ' _user ' , Id1, reject_trade(From, trade_pending(TradeResp?, _, OfferedBonds)))|UserIn], NetIn, Outs, Holdings, NextSerial) :- Id? =?= Id1?, ground(From?), ground(OfferedBonds?) | bind_trade_decline(TradeResp, OfferedBonds?), agent(Id?, UserIn?, NetIn?, Outs?, Holdings?, NextSerial?). %% Deposit escrow agent(Id, [msg( ' _user ' , Id1, deposit_escrow(Target, GiveSpec, ReleaseTime))|UserIn], NetIn, Outs, Holdings, NextSerial) :- Id? =?= Id1?, ground(Target?), ground(GiveSpec?), ground(ReleaseTime?) | do_deposit_escrow(Id?, Target?, GiveSpec?, ReleaseTime?, Holdings?, UserIn?, NetIn?, Outs?, NextSerial?). %% Escrow expired (injected) agent(Id, [escrow_dep_expired(Target)|UserIn], NetIn, Outs, Holdings, NextSerial) :- ground(Id?) | lookup_send( ' _user ' , msg(agent, ' _user ' , escrow_expired(Target?)), Outs?, Outs1), agent(Id?, UserIn?, NetIn?, Outs1?, Holdings?, NextSerial?). %% Escrow returned (injected) agent(Id, [escrow_dep_returned(Target, OurBonds)|UserIn], NetIn, Outs, Holdings, NextSerial) :- ground(Id?), ground(Target?), ground(OurBonds?) | append(Holdings?, OurBonds?, NewHoldings), lookup_send( ' _user ' , msg(agent, ' _user ' , 18 Grassroots Bonds escrow_returned(Target?)), Outs?, Outs1), agent(Id?, UserIn?, NetIn?, Outs1?, NewHoldings?, NextSerial?). %% Cancel escrow agent(Id, [msg( ' _user ' , Id1, cancel_escrow(Target, escrow_pending(CancelSignal?)))|UserIn], NetIn, Outs, Holdings, NextSerial) :- Id? =?= Id1?, ground(Target?) | bind_escrow_cancel(CancelSignal), agent(Id?, UserIn?, NetIn?, Outs?, Holdings?, NextSerial?). %% Incoming escrow offer agent(Id, UserIn, [msg(From, Id1, escrow_offer(ReleaseTime, BenResult))|NetIn], Outs, Holdings, NextSerial) :- Id? =?= Id1?, ground(From?), ground(ReleaseTime?) | inject_escrow_ben_result(BenResult?, From?, UserIn?, UserIn1), lookup_send( ' _user ' , msg(agent, ' _user ' , escrow_received(From?, ReleaseTime?)), Outs?, Outs1), agent(Id?, UserIn1?, NetIn?, Outs1?, Holdings?, NextSerial?). %% Escrow released (injected) agent(Id, [escrow_ben_released(From, Bonds)|UserIn], NetIn, Outs, Holdings, NextSerial) :- ground(Id?), ground(From?), ground(Bonds?) | append(Holdings?, Bonds?, NewHoldings), lookup_send( ' _user ' , msg(agent, ' _user ' , escrow_released(From?)), Outs?, Outs1), agent(Id?, UserIn?, NetIn?, Outs1?, NewHoldings?, NextSerial?). %% Escrow cancelled (injected) agent(Id, [escrow_ben_cancelled(From)|UserIn], NetIn, Outs, Holdings, NextSerial) :- ground(Id?) | lookup_send( ' _user ' , msg(agent, ' _user ' , escrow_cancelled(From?)), Outs?, Outs1), agent(Id?, UserIn?, NetIn?, Outs1?, Holdings?, NextSerial?). %% Termination agent(_, [], _, Outs, _, _) :- close_outputs(Outs?). 19