Rainbow Seeds feature exploration

The introductory Rainbow Seeds document describes a range of use cases for these Seeds-backed tokens. Additional use cases have surfaced in Discord and elsewhere. This document provides a space to discuss features in a concrete way which can guide those who are already designing contracts which implement Rainbow Seeds.

Below are two features on my mind; I welcome discussion of these and other features in replies.

Restricted Participation
For most local currency projects, “pilots” and “test beds”, it is desirable to limit possession of the currency to those who, respectively, live in the local area, are members of the pilot organization, or are registered as test participants. This is in contrast to a more general token contract (like token.seeds or eosio.token) which allows any account on the Telos blockchain to own and trade.
Restricted participation implies an authority empowered to accept and remove individual accounts from a whitelist. Defining how this authority is humanly managed should be an important consideration for any entity setting up a trial currency using Rainbow Seeds. In terms of a Telos smart contract, this feature can be represented by a “membership manager account” associated with each specific type of rainbow seed. This account has sole authority to open and close user access. (The account might, for example, be a multi-sig requiring several humans to sign off on membership actions.)

Fee Assessment
Traditional cryptocurrencies do not allow value to be withdrawn from an account without a signature by the account holder, and this rises to the level of ideological mantra among some. Nonetheless a token designed for experimentation should be flexible enough to support value withdrawal if the founding organization or test study researchers wish to do so. Some use cases would be

  • “perishable currency” (demurrage),
  • fines for violating community agreements, and
  • fees and taxation in general.

In terms of contract implementation, this calls for a “withdrawals manager account”, with fairly stringent controls. The contract implementation should support a way to confine withdrawal authority to an auxiliary contract embodying fixed policies.


An alternative to enabling whitelist management through an account-name specified at the time of token creation: specify a badge which enables transactions.

If the Rainbow Seeds tokens are being issued under the auspices of a SEEDS DHO (“multi-tenant DHO” software still under development) then badge issuance will be a built-in function. Otherwise, badge tokens could be issued by a more manual, less user-friendly process.

Continuation of feature exploration

Restricted Redemption
In some applications token holders are allowed to redeem their Rainbow tokens for the staked Seeds or dSeeds at will. Other applications will want a tighter “sandbox” and only the token creator is allowed to redeem.

Transaction Freeze

A token contract may designate an administrative account empowered to temporarily freeze all transaction activity. This is a common feature of mainstream markets in securities and commodities; it provides a “breathing space” to stabilize the market in special circumstances which are causing turbulence.

A token contract may additionally empower finer-grained transaction freezes. This might be applied temporarily to an account or group of accounts suspected of misbehavior, while investigation is under way.

Volume Limits
Programmable limits on transaction size, transaction count per day, or volume per day may provide damage containment in the event of a “hack”, compromised keys, or misbehavior. This idea needs further refinement regarding use cases and implementation details.

Orderly closure

Some Rainbow token pilot projects or experiments may be conceived with a fixed termination date, or others may anticipate the possibility of project closure without specifying a date certain. Provisions to support this lie largely in the off-chain agreements and bylaws defining the specific currency project, but will likely also require contract support, especially in regard to recovery of staked dSeeds. (Token contracts which have enabled transaction freeze and value withdrawal features may have all the tools they need for orderly closure, but this is a topic worthy of more analysis.)

These are the aspects I’d assume a solid proposal will explore:

The role of a local currency

  • the DHO structure should support the collective governance with a bootstrap process that needs to be owned and adapted by the local communities
  • bootstrapping a local economy is not easy so we should diminish barriers at entrance (rules, norms, …)
  • the bootstrap blueprint should define the “golden rules” of the currency. to establish this we should gather around one or two pilots before formalising any principles upfront (learn by doing should be at our core, we are not coming from a place of knowing but from a place of learning)
  • a minimal viable product should allow for people in a DHO to transact with the currency via the passport (including any kind of low tech no tech possibilities on the way)

The global currency:

  • the role of a global currency needs to be well established and the interconnectivity between local and global currencies should be experimented.
  • Virtues of a global currency could include: abundance, reciprocity, rewarding of good deeds, distribution of value across “economies” aggregation of local value (not the other way around) global circulation for every need a local economy can not serve (global trade) support optional liquidity pools and local trusts

Liquidity pools and local trusts

  • liquidity pools and local trusts are central bootstrap mechanisms. Frequently local currencies start with an ability to convert currency to satisfy local needs.
  • Local Liquidity pools should be established to gather multiple capital forms and flows
  • Trust principles are the fundamental constructs, pillars of the ecosystem (check the Samara base line)
  • a “central” implementation of “liquidity pools” seams to be the right path for the bridge between SEEDS and FIAT, evolving the idea of SEEDS selling or buying.

Please note that all of the above are tracks to explore…


Another possibility regarding connection between local and global currency.

Dynamically adjustable staking ratio
At the beginning of a local currency experiment the focus may be strictly local and the economic connection to Seeds may be nominal (very high staking ratio = very few dSeeds per Rainbow Token). As both the local and global currencies mature over time, the controlling organization may wish to strengthen this connection by changing the ratio and staking more dSeeds into the Rainbow contract – in proportion to the number of already minted Rainbow Tokens.

1 Like

Rainbow Seeds as "Regenerative Rewards Points"

Many programs worldwide are under way involving “rewards points” for ecologically or socially beneficial activities by individuals. Most of these are ledger systems where a central organization does the bookkeeping. I know of interest among a few Seeds-related groups in moving these rewards points onto the blockchain as tokens. At first glance, the rewards point (RP) application seems like a bad fit for Rainbow Seeds (RS), and would require development of a new and different RP contract. After all, the original RS concept is as a transferable representation of financial value, and RP are typically neither of those.
However, if the RS master bridge contract supports Transaction Freeze (mentioned earlier in this topic as an “emergency brake”), that feature could simply be configured as always on, meaning that tokens simply accumulate in individuals’ accounts. Only an authorized rewards management account could create and transfer tokens to users, presumably based on a locally-designed regeneration rulebook, as to who gets points for what activities. Likewise, the token creator may disable redemption to dSeeds or Seeds by the individual (this Restricted Redemption feature is also mentioned earlier in this topic), so that the form in which rewards points get recognized is completely within the domain of the managing organization.
On this basis, I think that we can consider Regenerative Rewards Points to be a valid use case for the Rainbow Seeds contract.

1 Like

Rainbow Seeds Token Naming and authenticity

On the Telos blockchain, a token symbol is 1 to 7 ALL CAPS letters. There is no official method to prevent “name collisions”, where two different organizations choose the same symbol. A token is issued under a token contract, and that contract has a unique Telos account; for example the SEEDS token is issued under the token.seeds contract. Another individual or organization could create an entirely different token called SEEDS, and the only way to tell them apart is by the contract’s account name. Token symbol duplication is an accepted fact of the blockchain world, and carries some risk of confusion.

We can anticipate that many bioregions and interest groups will form DHOs and each will host a master rainbow bridge contract under their own account name. Under its master contract, each DHO may issue a number of different Rainbow Seeds for different purposes. It would be convenient for each organization to embed a few characters into their token names identifying its region, allowing a knowledgeable user to distinguish them at a glance. However this is not enforceable, and there may be several different organizations using the same token symbol for different purposes. Seeds wallets should make the host contract name visible to users sending or receiving Rainbow Seeds.

I estimate the Rainbow Seeds contract may require 1-2MB of RAM on Telos, costing $40-80 at today’s prices. The cost of creating each new type of Rainbow Seeds under a DHO’s contract should be minimal. Issuing the Rainbow Seeds themselves will, of course, require staking the corresponding value in Seeds or dSeeds.

Note that it is not necessary to have a DHO in order to set up a token contract. Proto-bioregions and other groups with sufficient blockchain skills may set up their own Rainbow Seeds contracts, and this may be facilitated by the Seeds software, if desired. However this raises the possibility that a “rogue” organization might set up an inauthentic Rainbow Seed token with different (and possibly even malicious) behavior. It would be valuable for Seeds Light Wallet or Global Passport to verify Rainbow Seed authenticity (e.g. by verifying the on-chain hash values for the contract code and ABI).

1 Like

This sounds epic! However, I’d recommend that we have all this functionality as just a separate token. Once tokens can have this much variability in how people could expect them to behave (including dynamic staking rations) then I believe it just merits being it’s own token that can be launched and managed in any DHO (each community can just launch their own unique token).

May be something even more elaborate than “rainbow Seeds” and just have a general “community currency” portal for designing and launching them methinks…

Basically just yes to this! All “Rainbow Seeds” could operate under the same contract as long as they follow the simple rules of a Rainbow Seeds. Once more elaborate they would be issued by the DHO as a unique DHO token (as every DHO gets by default).

Experimental contract for rainbow-type tokens.