The system is a network that focuses on decentralized reputation. Participants are pseudo-anonymous, self-sovereign entities that wish to establish a reputation. In this context, “reputation” refers to commercial relationships and transaction success, generally. “Transaction success” can refer to lending and borrowing or satisfaction with products and services and their inverse, satisfaction with the customer or client.
Pseudo-anonymous participants are represented as self-sovereign identities that are known by a blockchain address such as an Ethereum address. The system facilitates intentional de-anonymization for individuals and commercial entities that wish to unmask metadata such as their name, location, principles, etc., as well as the injection of formal analysis reports by Reporting Agencies.
The data structure is a network graph where the nodes are the identities and the edges are relationships between the entities. All such relationships are signed by both parties and evolve through specific lifecycle stages. Bi-lateral signing is an anti-spam defense and it provides a strong foundation in that the existence of a relationship is inarguable when both parties have cryptographically signed that it does, indeed, exist.
The architecture consists of a web-based user interface, smart contracts on a blockchain, relayer nodes that are paid in FACT tokens for the service of submitting transactions, a web server, and an API. Android and IOs apps can be added in the future. The web-based user interface will be mobile-friendly and responsive.
Participants will be incentivized to seek out others who will be willing to attest, on-chain, that a commercial relationship exists. Participation is a win-win for both parties because each relationship is an opportunity to gather evidence of reputation. Examples include credit extended and repaid, a satisfactory product or service delivery, and even client performance. Participants will be encouraged to “invite others” to join the network and this will be facilitated with simple URLs that lead to the creation of new accounts.
Participants may also wish to provide evidence of their reputation to prospects. A simple URL will reveal a summary of past relationships that are known to the network. URLs can be encoded in QR codes which means physical items such as decals for place-of-business can be created and distributed.
These website “hits” are opportunities to convert observers into clients. Conversion will be encouraged at the user experience level, e.g. call to action.
The network is primarily focused on the collection of raw data and financial/accounting concerns. Compute-intensive operations (e.g. statistics), interfaces with external systems (i.e. other ratings agencies), and verifying the identities of accounts that wish to de-anonymize are off-chain, external concerns and revenue opportunities. Each agency, including Factiv, is free to design in-house processes for such things as verifying identity and issuing “scores” based on interpretation of collected network information and, optionally, information from other sources.
Rating Agencies will sign attestations that further enrich the on-chain information available for a given identity. To protect the privacy of participating individuals, minimal proofs of authenticity will be committed to the chain. The proofs indicate the signer that committed the hash and the hash of the document.
On-chain attestations are quite simple, by design:
BlockNumber and address are added as breadcrumbs that facilitate quick and efficient lookup of other metadata about the attestation, such as when signed, transaction id (listen to logs at exact blockNumber) and the identity of the signer and standing in the system.
The actual document may or may not be available from a server operated by the Rating Agency. In case the human-readable document is available to download (with user consent), the attestation can contain a url to inspect. In case the document is confidential, the use can distribute the document at their own discretion. The browser application should be able to generate a hash from an arbitrary file, such as PDF, and then inspect the contract to confirm existence (it is a genuine file) and retrieve metadata about the Attestation.
This arrangement affords the Rating Agency flexibility in the delivery of their service and their user agreement. For example the method of delivery could be selected by the user - generate a public url or simply download the report. Additionally, it allows for a “verified” stamp (a unique typeKey) as an alternative to on-chain identity data.
In case the foregoing is unclear, the system supports three levels of user identification:
The default condition is users are known by Ethereum addresses.
The user’s identity has been confirmed by a Rating Agency, but has not been publicly revealed.
The user’s identity has been confirmed by a Rating Agency and metadata has been written as (separate) attestations:
A metadata table normalizes the allowable typeKeys. Only the system governance can admit new typeKeys and no one can sign an Attestation citing an unknown typeKey. It is worth noting that interpretation of the typeKey/value pairs is a user-interface concern and does not affect the internal logic of the contracts. Contracts are concerned with the construction of the persistent data, not what it means. Therefore, a means to extend the typeKeys is a means of avoiding premature obsolescence since new quasi “fields” can be added for arbitrary purposes as the system evolves.
This arrangement affords the user the opportunity to share the report (pdf or url) if they want to and to prove the authenticity of the report that was shared. More precisely, the receiver proves it to themselves.
Commercial entities will be enticed, but not forced to reveal their legal name and basic information, i.e. voluntary unmask. This is encouraged because doing so enriches reports for all entities by unmasking trading partner information at the network level - changing 0x234… to ACME Inc. makes Alice’s report more readable. Since this is a benefit to the entire network, an incentive is appropriate. Care should be taken to:
Since identity verification can only be performed by reliable agents with trustworthy processes, signing such attestations is a privileged function extended only to authorized Reporting Agencies that are admitted in the network via governance.
As a reminder, there is no requirement for an account to unmask if they prefer to remain known by only a blockchain address. If they do unmask (by way of a report signed by an authorized Reporting Agency), then the information exists in plain text on the blockchain and appears where the address would appear in the user interface
A token, FACT, is the in-app settlement currency. Additionally, with the right user interface and network infrastructure (which is assumed and proposed), the token will offer the following utility:
The economic design is formulated in a way that will encourage mass adoption and incentivize early adopters while keeping the mechanics as simple as possible.
* Step 3.a.ii is an unreturned value-add to the network itself and a justification for an issuance event. However, issuance is not possible in a fixed-supply setting such as this. Therefore:
This method gives more control (more concentration of power) to governance than a hard-coded, immutable formula but it allows adjustment for market conditions and relieves the design team of the need to optimize the calibration of this concern.
A burn rate is linked to network transactions. Burn rate prescribed at deployment time, can be raised by governance but it cannot be lowered. Burn limit is 50% at deployment time and can be raised but not lowered.
Relayers (see below) will collect fees in tokens to compensate for paying network fees. Those fees are forwarded from the contracts. The burn is extracted at this level.
A significant portion of the initial supply should be allocated to network growth and used to cover the gas cost for early adopters so there is no cost to sign up. This will remove a barrier to entry. This will be funded by pre-allocated in-app rewards.
Generally speaking, the value of the network token will be a function of the available supply and demand. Available supply for a fixed-supply token can be managed by:
Given an initial supply, allocate specific amounts for specific purposes, such as:
Using a token as a gas substitute means that transaction costs paid for in tokens dictate the token requirement for a given transaction. In case that is unclear, consider a transaction with a real cost of US $1 that must ultimately be paid for in BNB, Binance smart Chain’s native currency. The FACT tokens required to pay for this depends on the value of the FACT tokens at that moment. It is therefore incumbent on the team to maintain a high value for FACT or else large quantities will be required to cover transaction costs in the early days.
Having established budget items (such as above) and creating a reasonable spending plan it is recommended to deposit the majority of the tokens in time-locks that release vested founder shares and operating budgets on a schedule. It is further suggested that any large investors or vendors agree to a vesting schedule. Publicizing the financial plan, with the vesting schedules can communicate the implicit reduction in circulating supply and reassure the market that “whales” are not in a position to dump large orders on any exchange. It is better to have fewer tokens in circulation than the network activity requires rather than too many.
Reserves that are time-locked should be managed in a multi-signature wallet such as Gnosis Safe.
An entire plan could be written around concerns that external to the design of the system itself. Interest-paying staking pool, automated market-markers, listings on centralized exchanges, public relations and brand promotion, etc., are important activities that support the price of the tokens and help take supply off the market. While the token and the system are intrinsically linked, activities that are independent of the application design are outside the scope of this design.
Users can encourage acceptance of their invitations by staking their own funds (with expiry date) in the invitations they create. These funds are released to the invitee upon acceptance.
When ACME invites BETA to participate and confirm that a relationship exists between them, ACME can further encourage BETA to agree by posting a bounty/prize for Bob to collect when he clicks. The same process is possible at every stage in the relationship lifecycle - ACME can incentivize BETA to leave a review, a rating, etc., and if it is important to ACME, she can consider leaving a “thank you” in the form of tokens for BETA. Such incentives should be linked to the type of feedback, i.e. incentives should not influence the rating and a negative review should pay the same reward, if any, as a positive review.
When a user unmasks, they receive an incentive from the incentive pool at a rate controlled by governance.
When a new user joins, the invitation (JOIN) the user is responding to is known to the contracts. The contracts will record the referring user for later.
When a user converts by revealing their identity publicly on the chain, the referring user receives a reward from the rewards pool at a rate controlled by Governance.
These rewards are passed upwards in a hierarchy of referrers at a rate controlled by governance. For example, possibly 10% of referral rewards received are passed to the referring node. Importantly, this is not processed entirely and immediately for the whole hierarchy since that would be prohibitively costly for Ethereum.
This process is amortized, with each sub-node passing their accumulated upstream rewards to the node above whenever their in-app balance changes. Funds held in lower “leaves” of the tree can be “poked” by anyone at any time since execution of the deferred processing is harmless to participants and helps the nodes proceed toward eventual settlement of accounts. Each node will be able enumerate the leaves below, inspect the rewards owed and “poke” (shake the tree) if they want to pay the gas for immediate account settlement - to collect their reward.
The web-based user interface will support desktop and mobile apps and will not require the installation of a third-party wallet. As such, it will include rudimentary wallet features.
This is not a full-function wallet, by design. The app will not be designed to interact with other contracts, hold a basket of assets or send assets to other users in an ad-hoc manner (this is not infeasible aspirationally, but it is not trivial to replicate the features of a “real” wallet).
It will be possible to receive FACT or any other compatible, on-chain asset in this wallet address but the in-app functionality will be limited to spending FACT on a narrow band of in-app purposes. The seed phrase will be loadable in other wallets that support the mnemonic standard which will enable normal operations with any asset and interactions with other contracts.
In this context, Relayers are always-on servers that forward signed transactions to the blockchain. This middle layer enables the payment of network fees (that are unavoidable) using the FACT token rather than requiring users to acquire a network token as well as FACT. Relayer support is implemented at the contract level. The flow is approximately as follows:
More info on this design pattern:https://medium.com/@austin_48503/ethereum-meta-transactions-90ccf0859e84
In a simplistic implementation, the Relayer could re-introduce unwanted centralization. The financial arrangement described above creates a business model that encourages external operators to operate relayers for profit. While it is probable that the first relayer will be owned and operated by Factiv, the business model is a path to decentralizing this function. Factiv would approve new Relayer operators and aim to retreat from control of this function over time.
The role of contracts is to enforce the rules of the system and safeguard the integrity of the system including the critical processes and persistent information. Contracts will oversee the creation of new nodes, the evolution of the graph that connects them, the accounting, and governance.
And API layer stands between the user interface and the blockchain. The blockchain is the system of record but an API can improve performance, preprocess information (statistics) and provide a common interface for web and mobile apps (in the future).
Privileged roles will exist to control access to sensitive functions. Examples would be the inclusion of a new Relayer and admitting new Rating Agencies. Role holders are represented by addresses (a whitelist) and those addresses can be single wallets but it is recommended to plan to migrate these roles to multi-signature wallets and eventually to distributed governance. No change to the contracts is needed to migrate a role to a new signer.
Privileged functions that control governance concerns always raise the question, Who decides. Initially, governance will be controlled by a multi-signature wallet using n of m +1, where +1 means a recovery key is stored with a trusted custodian. Any transactions from governance will have already passed a multi-signature process.
This is still a concentration of power since Factiv will control non-trivial aspects of the network. Governance will be transferable to other entities. A candidate for full decentralization would be a dedicated governance system such as Aragon which would put the community in charge of previously-centralized functions. It is not recommended to reach for this at the start because the design of actual distributed governance is a major undertaking. However, it is safe to say that the long-term plans include moving in that direction.
The data structure is a network graph of nodes that represent identities, joins that represent relationships, and histories of those relationships. The design follows the principle of minimalism, generalizing the multitude of possible future associations that may be useful into a simple, flexible structure that accommodates variation. JSON object notation is approximate, for discussion purposes.
Identifies are generated in the browser and are transferable by transporting the 12-word mnemonic to another device.
A simple mapped struct of user information to support the described processes, e.g. referrer (if any), tokens allocated to referrer, Interable Set of Attestations.
Joins have normalized fields that are present in all cases, and a general-purpose dynamic length bytes array that can be used to store arbitrary, type-specific metadata. The system support n join types and governance admits new join types and descriptors into the system. The type indicator assists with the interpretation of the arbitrary data in the stages history field which may itself contain information in any layout.
Each Join contains a list of stages that chronicle the lifecyle of the relationship. There are exactly zero or one Stage records for each Join. The first two steps are mandatory, meaning no one can leave a rating unless the relationship was first requested and accepted. Other steps are optional. For example, attestation can occur at any time and does not necessarily need to be requested.
The stages are:
Each such stage is represented by normalized fields:
The known goal-oriented use cases can be decomposed into one or more Joins and Stages. For example:
Joins evolve through Proposed and Accepted in a forward-only direction. Accepted comes after Proposed and an Accepted proposal cannot be un-Proposed. An not-Accepted proposal can be withdrawn.
Proposals must be Closed before Attestations are given.
Users may amend the Attestations they have signed.
Arbitrators (User Role) are similar to Ratings Agency (and may be same entities). Arbitrators can override a user-signed rating, in which case the Arbitratorâ€™s address is added to the Join.
Types are crucial for the correct interpretation of the arbitrary data in rating stages (4, 5). In this context, “arbitrary” means the application can use it for any worthwhile purpose but the exact content and layout of the data will still be consistent for each type. The arbitrary field can be used to hold a small amount of data such as a url, a hash or a few words that support the type. Interpretation is a client-side responsibility, meaning the user-interface or analytics engine will know what to expect based on the Join Type. Any departure from an established layout implies the creating of a new type by governance and corresponding user-interface upgrades to support it.
Example Join Types could include:
The existence of bi-lateral Joins persists. Proposals that are not accepted can be deleted from the present state by the Proposer but the fact that a Proposal was issued, then deleted persists. Comments and ratings can be amended by the signers.
On-chain data analytics is impractical owing to the limitations of blockchain technology. Instead, the structure is designed to form a system of record that can inform off-chain analytics. For any given entity, there is an inventory of relationships and outcomes with signatures at each step. This forms an inarguable record of what occurred with some subtleties to be aware of.
Some relationships may never be concluded, i.e. abandoned. Some nodes will be identities and others pseudo-anonymous. Typing of join types facilitates variety in the arbitrary data field. For example, in the case that the user requests unmasking from a Ratings agency:
A user interface can be built to simply reveal a users raw history as it has been collected, including revealing the identifies of trading partners when possible. This would be a fully decentralized application, and useful.
Ratings Agencies tasked with producing metrics such as overall scores and recommended lending limits can apply all manner of statistical interpretations to the raw data. Some examples:
It is expected that some forms of statistical analysis will be served by the API and presented in user-facing apps as built-in features of the system. APIs are a centralized component but a case can be made that they don’t represent a concentration of power because they rely entirely on decentralized data, don’t exercise outsized privileges and the possibility always exists that someone else will stand up their own API and user interface using the same contracts and data history (which should be encouraged).
Reporting Agencies can provide any manner of report using network data and possibly data from other sources. At the system level, there is no engineering requirement for a Reporting Agency to reveal their internal business process, i.e. how they do what they do. Reports can be brief or elaborate.
At the system level, the common requirements are:
QR codes that open reports create opportunities for interesting physical artifacts that could be ordered through the app. This is expected to be an area of ongoing innovation long after the on-chain design is finalized and deployed.