Circles-based Zuitzerland Currency

Note: This was a paper made for a hackathon to provide ideas for building an economically sustainable permanent Zuzalu hub.

As we live more and more in specific communities, the emergence of a local, community-bound currency seems inevitable. It strengthens local commerce, pushes active participation and reinforces alignment between members. However it is difficult to design a local currency that goes beyond a simple token pegged to the already established currency of the host country. This local currency needs to have properties that make it more attractive than the dominant one, and that are closely linked to community attributes.

The Circles Protocol proposes interesting mechanics that are relevant to our goal of building a local currency. Firstly it ensures fair distribution between participants at the rate of 1 CRC per hour, and secondly restricts transferability of these minted tokens to the trust connections of each participant. In other words, anyone can mint their own CRCs, but can only spend them with people that trust them. These two rules make a lot of sense in the context of local economies that already have a certain baseline of trust (like curation in the case of Zuitzerland). Furthermore, the continuous (UBI-like) minting allows every member to participate in the local economy without having to use the dominant currency. The value of these tokens come from both highly-engaged participants that create products and services in the village (or might directly contribute financially to it) and less engaged members that consume these products and services.

Circles provides the base layer for interacting with the trust graph, minting of personal tokens, and the ability to create groups that have their own currencies backed by members’ personal tokens (or other collateral). In this paper we propose using the Circles Group functionality, with some modifications to suit Zuitzerland, as a way to build our currency. A group can trust users based on any custom logic we bake into it. By default, this trust means that the group accepts its trustees’ personal tokens as collateral for minting the group’s token. For our purposes we suggest modifying the default behavior in the following ways.

Design

Geofenced Group Trust Logic

Since Zuitzerland aims at building an in-person permanent hub, we think trust by the group should come from physical presence in the hub. This could be done in a number of ways but could simply be an NFC check-in at the entrance that residents do roughly every week. A weekly check-in makes sense because it’s long enough to account for outside-the-village errands and short travels while being short enough to not let non-residents get tokens.

This ensures that holders all have a reason to hold the tokens, avoiding outside interference that could lead to problems in the local economy. It also helps by providing some base analytics about population in the hub.

When a member stops checking-in (because they physically left the hub), the tokens they still hold start to decay faster (on top of the 7% Circles demurrage), to encourage spending in the hub while they’re in. We believe such a currency should mostly be used as a medium of exchange, encouraging people to spend and participate in the local economy.

Spending Restrictions

We distinguish between internal (in-village) and external transactions, The tokens can flow freely in the village with no restrictions, anyone can use them to buy and sell products and services to anyone else in the hub. However, external transactions, for instance when someone needs to buy something outside of the village (groceries) are more complicated and we think they require some restrictions. The group can set a liquidity pool of the local currency with a dominant currency used in the country (CHF or USD). This pool serves two purposes: backing for the community (a part of its “endowment”), and a way to exit when needing to do an external transaction. This pool does not necessarily need to be closed on the buy side because whoever buys these tokens needs to check-in to avoid decay, so at worst a non-resident can make a donation to the pool, and a resident might want to pay to have more tokens instead of waiting for minting.

However for the sell side, things get more complicated because a resident could accumulate a lot of tokens and brutally exit, hurting the local economy. While this probably wouldn’t destroy the economy (as long as long-term members stay), the fact that it could happen might be enough to reduce trust in the community. There’s also the risk that the token becomes a proxy for the dominant currency. A solution is to restrict selling to community-approved spending, in the same way that vouchers work. For example, there might be a need to buy 500 CHF worth of food, the people responsible for that can make an order to sell enough of the token to get 500 CHF. This makes it easier for liquidity providers to trust the community. There’s also the advantage of not being heavily subjected to CHF fluctuations.

By limiting external transactions, we also increase the velocity of internal transactions, which substantially helps the hub save money. This is because every product or service in the village has two cost components:

• Imported inputs (coffee beans, equipment, anything bought outside) which cost full price in the host country’s currency
• Local inputs (labor, rent, anything bought inside) which are paid with the community token

Because each token gets spent V times inside the village before getting redeemed outside, only 1/V of those local costs actually drain the pool, meaning that the real-world cost to villagers is Imported cost + (Local cost / V).

In other words, the community only needs a fraction of the money circulating in the village, drastically lowering the minimal amount the treasury needs to maintain in order to support external transactions.

Built-in Subsidy

Building on the previous idea, the higher velocity has the side-effect of creating a default “subsidy” for the community. If velocity of money is 3, then for every 100 CHF worth of economic activity in the village, only 33 actually leave the treasury, sparing 67 that get “recycled” in the village.

If we compared two similar villages, one using the default dominant currency (say CHF), and one using this system (and assuming an in-village velocity of money above 1), then the second village would most likely be better off every time. They would run an economy larger than their CHF treasury (close to CHF treasury * velocity), they would have a built-in subsidy that could build up a treasury for resilience and public goods funding and would have a lower effective cost of living for residents. Not to mention all the advantages surrounding better value-alignment that we touched on in the introduction.

Of course, such a system should be opt-in, therefore residents should decide at the entrance if they want to check-in to start receiving the token. Non-checked-in residents can still use the dominant currency (or another community one) in order to participate in the economy.

Technical

NFC Geofencing

We want our onchain Circles Group to have some way to verify that residents are inside. The challenge is to avoid trusting a central authority on who is here, and avoid doxxing residents.

Here’s the flow we propose:

1. Device check-in
   1. Reader issues nonce
   2. Resident taps NFC -> reader Secure Element signs leaf ℓᵢ = H(userAddr | nonce | readerID | date), to get signature σᵢ
2. Off-chain batch & Merkle tree
   1. Aggregator collects all (σᵢ, ℓᵢ) of the day (or the week)
   2. Builds Merkle tree over leaves ℓᵢ -> root Rₙ
3. Off-chain SNARK proof
   1. Prover runs circuit C that:
      1. Verifies each σᵢ against onchain registry of public keys
      2. Recomputes Merkle root over ℓᵢ
      3. Checks computed root = Rₙ
   2. Outputs (Rₙ, π)
4. On-chain root publication
   1. Contract verifies the proof
   2. If valid, pushes the new root
5. Any onchain service (like our Circles Group) can verify residents’ Merkle proofs to make sure they are in the village

We’ll then want two contracts, one managing the Circles Group, it will trust based on the above system; the second one just has the logic that actually verifies (and is thus linked to the first contract), in case we want to update membership conditions. The only function that really interests us is autonomousTrust that lets anyone ask for group trust.

Liquidity Pool & Token

As we said, we want the liquidity pool to be closed for selling. There is not much to do here, we could simply have a contract allowing for the purchase of these tokens, and a contract for placing a sell order that goes through according to some governance mechanism to be defined later. It could be a Safe of LPs and residents.

For the token itself, the reference is yet to be determined, but two main ways are possible:

• Use the native Circles (CRC) token, that gets wrapped into the group token
• Use a custom token contract and only have Circles for the group functionality

This post only proposes the initial design, but leaves the implementation open to more discussion.

Conclusion

In summary, a geofenced community currency helps transform a pop-up village into a self-sustaining economy and permanent hub. By issuing a simple, trust-minimized UBI only to checked-in participants and restricting transfers to trusted peers, we incentivize participation and spending in the local economy. That currency, accepted for every in-village product and service and redeemable via a transparent liquidity mechanism, increases resilience for the village and builds up the treasury.

Technically, NFC readers handle weekly check-ins, a smart contract mints tokens and enforces the rules (based on Circles), an AMM-style pool or bonding curve lets vendors convert tokens into the dominant currency for imported inputs (after governance checks). Economically, high velocity multiplies local trade, shaving 1 - 1/V of local costs from real-money outlay and building a growing dominant currency reserve to fund public goods and economic activity.

This model isn’t a gimmick in which “free money” magically appears, but a deliberate design that stretches each CHF (or others) of backing across multiple rounds of commerce. It lowers villagers’ effective cost of living, spurs new services, and accrues communal savings - laying the groundwork for richer, more resilient, value-aligned and defensive communities.