| SYGON | |
| SYGON | |
| ERC20 | |
| 18 | |
| Fixed, 7500000000. This is the maximum amount that can be released ever. | |
| Total amount ever released from TIS. | |
| Fixed, 6750000000 (representing 90% of the total initial supply). | |
| Total amount of tokens burned so far. Burn applies to TRQ only. | |
| Total token supply that was released and was not burned yet. TCS=TRQ-TBQ | |
| Total remaining token supply that can still be distributed from initial supply. TRSR=TIS-TRQ |
The SYGON token implements the business model adopted by SynergyCrowds, with specific mechanisms for monetizing the contribution of sygons to producing knowledge in a decentralzied fashion.
Actors
There are five types of actor that interact with the SYGON token:
- Creator releases SYGON tokens to the Build Contributors, to reward their contribution to developing the SYGON technology.
- Build Contributor directly contributes to the development of the SYGON technology generally by working on different tasks of specific development projects. This role assimilates the build contribution type described in The Sygon token article, Utility design section.
- Alias Target Manager manages the target address of aliases and owns addrAliasTarget.
- Fee Manager manages the settings of the fee mechanism and owns the address that collects fees applied to token transfers (addrFees). The Fee Manager role is played by a software, decentralized mechanism that allows all sygons to decide on the fee policy based on algorithmic meritocracy.
- Other is played by any other users, holding and transferring SYGON tokens for any purpose.
The SYGON token is: fungible, fractionable and burnable.
As of ERC20, methods can be used by any user to transfer SYGON tokens.
The function checks in advance if the amount is transferred to an alias or a splitter and performs the transfer accordingly.
Aliases
Aliases are Ethereum addresses that receive a special treatment in relationship with the SYGON token. Any amount transferred to an alias address is forwarded automatically to a unique address (denoted addrAliasTarget).
More specifically, aliases are created by the operational entity (SynergyCrowds company) for all users of the SYGON technology products. The concept of alias can be found under the name of Feed address in the SynergyCrowds platform. This is a unique address that is allocated to every account after successfully upgrading to Level 2.
The SYGON tokens are put into circulation with this method, exclusively by the Creator. This special method of transfer is meant to release amounts of SYGON tokens directly to Build Contributors, so the token release is fully covered in contribution. The token is never released for investment or speculation purposes (with approaches like ICO / IEO etc.) but only to reward real contributions to building the SYGON technology and its products.
INPUT
-
Beneficiary
The address of the contributor to receive the Amount.
-
Amount
The amount of SYGON tokens to be released from TRSR.
-
Project ID
The identifier of the project being developed.
-
Installment ID
The installment ID of the current transfer for a particular Project ID. This is to provide transparency, by allowing anyone to track release transfers according to several milestones, along a roadmap of a project. For example, if the project targets the development of a software component, this approach matches with software development lifecycle, meaning that the contribution is rewarded gradually, for consecutive releases of the developed software.
There are five possible release destinations, from which three are predefined: [0] DEV (Project Development), [1] PRO (Promotion), [2] OPR (Operational). While the amount for DEV destination is explicit, the rest of the destinations have deduced amounts. This means that for a new release, the amount for DEV is explicitely stated when calling the function. Consequently, amounts for PRO and OPR destinations are calculated automatically by the function, based on their weights in the current Release Structure.
All release destinations together define the Release Structure (RS). For example, a structure like RS{0:20,1:30,2:50,3:0,4:0} means that when a transfer of 10000 SYGON tokens is performed to DEV, automatically a transfer of 15000 SYGONs to PRO and a transfer of 25000 SYGONs to OPR destinations respectively are performed by the function.
Also, there are destinations [3] RD3 and [4] RD4, with an initial weight of 0 (zero), left for future use.
Changing Destinations Only changing the address and weight of destinations [1-4] are possible and they are performed by the Creator only.
Reading the properties of any release destination can be done through a valid name ("DEV", "PRO", "OPR", "RD3", "RD4"). Properties are: destination ID, address and weight.
Currently the following release structure is used but this can be modified at any time in the future, based on several factors like: requests of contributors, market prices, operational costs etc.
| ID | Name | Address | Weight |
| 0 | DEV | Parameter for transfer as token release | 100 (unmutable) |
| 1 | PRO | At creation (mutable by Creator) | 150 (mutable by Creator) |
| 2 | OPR | At creation (mutable by Creator) | 250 (mutable by Creator) |
| 3 | RD3 | 0 (mutable by Creator) | 0 (mutable by Creator) |
| 4 | RD4 | 0 (mutable by Creator) | 0 (mutable by Creator) |
This is a special method of token transfer. The function is internal and it is called automatically, when
the target address of a transfer is detected to be a splitter.
For any address that is registered as splitter, this mechanism allows that any amount received as a transfer to it, is automatically "forwarded" to a few other addresses, according to a predefined split schema.
Splitters
A splitter associates an address with a split schema, which defines a set of transfer destinations with associated weights. This mechanism allows at least two contributors to receive rewards simultaneously.
Splitters are designed for automatically distributing the monetization of products among their contributors.
Any amount of tokens sent to a splitter is automatically distributed among the destinations defined in the split schema.
The contributor that creates the splitter is called Primary and the second one is called Secondary contributor. The secondary contributor can furhter configure the splitter by managing other 5 contributors at choice.
Split schema
| Entry type | Primary | Secondary | Managed1 | Managed2 | Managed3 | Managed4 | Managed5 |
| Index | 0 | 1 | 2 | 3 | 4 | 5 | 6 |
Use case example
If an application A generates a revenue of 100 tokens, then the contributors of application A get rewarded through a splitter. The splitter is created by user U1, with a secondary user U2. U2 further adds U3 and U4 (at entries 2 and 3 respectively) in the splitter. Split weights (WSplit) are: WSplit(U1)=30, WSplit(U2)=45, WSplit(U3)=35, WSplit(U4)=20. Any amount of SYGON tokens transferred to their splitter will lead to transfers to split destination addresses in the following amounts: U1=30, U2=31.5, U3=24.5 and U4=14.
All amounts collected at addrAliasTarget are sent to splitters. In this way, the monetization of the knowledge produced and delivered by the SYGON technology is transparently distributed among its contributors only. The SynergyCrowds company, as an operational entity of the products, has an absolutely equal position with any other contributors, in terms of cashing revenues. So the operational entity can distribute the realized revenues exclusively throught splitters, without any other possible option.
Any address in a split schema can be changed with a new one, by its actual owner.
Configuring a splitter
The primary contributor can change any destination address and weight in the splitter. The secondary contributor can change the address and weight of the 5 managed destinations.
Restriction: successfully transferring to a splitter requires that its weights are configured correctly, namely the sum of the weights of the last 6 destinations must be 100.
This is a special method of token transfer ensuring that all amounts received at addrAliasTarget are transferred to splitters only. No other destination is possible. This mechanism guarantees to the contributors that the entire monetization of the delivered knowledge is distributed among them and this process is completely transparent.
Transfers from addrAliasTarget can be performed either directly or delegated.
The SYGON token is fractionable. Having 18 decimals, the smallest transferrable amount is 0.000000000000000001 SYGON tokens.
SYGON tokens can be burned by any token holder, from own balance. Also, a fraction of the collected fees are periodicaly burned (see chapter 4 - Fees).
The burn operation can only be applied to the released quantity of SYGON tokens.
The burn operation is limited to a maximum quantity (TMBQ).
The burn operation is forbidden for the Creator, so that the total initial supply is not affectable by this operation.
Certain fees are applied to all token transfers.
Fees are calculated based on the amount of transferred tokens and a specific factor (defined in feeSettings).
| Amount interval | Fee |
| (0,1000] | 0.0015 |
| (4000,10000] | 0.0009 |
| >10000 | 0.000005 |
Fees are collected at addrFees and they are periodically distributed - partially to the operational entity and partially burned. The collected fees can be distributed only by using the distributeAndBurnFee function.
The proportion of token that is burned from the collected fees is established through open vote by sygons. Its value is stored in nBurnFromFeeQuota.
The overview of the SYGON token economy.
| Actor | Identifier | Entity |
| Creator | addrCreator | Co-founder, Mircea Moca |
| Fee Manager | addrFeeManager | Software controlled by all sygons |
| Alias Target Manager | addrAliasTarget | Operational entity |
| Other | Any user holding and transferring SYGON tokens |
The Creator is interested in building the SYGON technology. For this, he releases SYGON tokens to contributors that build the technology through specific development projects.
The collected fees can be distributed only to two destinations: burn and the operational entity. The ratio between the two destinations is decided by all willing sygons through vote and algorithmic meritocracy. Hence, the Fee Manager is a software mechanism used by sygons to decide in a decentralized manner.
The Fee Manager is also responsible for changing the fee settings (see Chapter 4 Fees). The Fee Manager is owned by Creator at creation and the ownership is transferred to the decentralized mechanism after its implementation, using the changeFeesAddr function (see UC19 Change Fee Manager).
The Alias Target Manager is owned by the operational entity, having the responsibility to distribute the entire monetization of the products to their contributors. The contributors to be rewarded are registered in splitters. The key aspect is that there is no other way to withdraw amounts from the realized monetization but only to contributors, through splitters. Regarding the distribution of the realized revenues, the operational entity plays an equal role to any builder contributor. There is no possible way for the operational entity to cash revenues for any particular product, without the rest of its contributors to cash as well. This is ensured by transferFromAliasTarget (see UC8 Transfer from alias target). Two types of contribution are rewarded with this mechanism: build and extend (for details on types of contribution, see The Sygon token article, Utility design section).
| Account | Identifier | Owner |
| OPR release destination | expDestinations["OPR"].addr | Operational entity |
| PRO release destination | expDestinations["PRO"].addr | Operational entity |
| RD3 release destination | expDestinations["RD3"].addr | Creator, initially not allocated |
| RD4 release destination | expDestinations["RD4"].addr | Creator, initially not allocated |
The operational entity owns the OPR and PRO release destinations. While the first one is used to support the operational activities required by the products of the SYGON technology, the second one is for promotional activities related to the respective products. The RD3 and RD4 destinations are desinged for future use. Once they are explicitly allocated, the related documentation will be provided in this repository, as for the others.