Factiiv whitepaper

start reading

Rating Agencies

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:

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

Token

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.

Burn

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.

Bearing the cost of onboarding early adopters

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.

Financial Planning

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:

• Controlling the release of the tokens
• Ensuring there are network services that cannot be paid for in any other medium
• Encouraging lock-up in staking schemes
• Liquidity pools

Release Schedule

Given an initial supply, allocate specific amounts for specific purposes, such as:

• Private financing, usually sold at a discount for large investors
• Launch-related activities
• Network growth
• Affiliate and influencer compensation
• The team and advisors
• Bounties and in-app rewards
• Marketing
• Public sales (including in-app sales to network users)
• Exchange reserves
• Operational reserves
• Contingencies
• Staking incentives
• Liquidity pools

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.

Price Support

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.

In-App Bounties

User-to-User

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.

System Reward: Unmasking

When a user unmasks, they receive an incentive from the incentive pool at a rate controlled by governance.

System Reward: Referral

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.

User Interface

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.

1. Create an account and back up the seed phrase (BIP-39, Ethereum keypairs, and addresses).
2. Sign a transaction to a contract. This can include an incentive for the receiver using methods that are defined in advance at the application level.
3. Send the raw signed transaction to a relayer (https).

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.

Relayers

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:

1. ACME signs a transaction to the contract and forwards this signed package to the Relayer.
2. The Relayer sees that the package is addressed to a known, trusted contract that will pay it to send the transaction.
3. Seeing that the expected payment is >= gas price of submitting the transaction, the Relayer submits the already signed raw transaction to the blockchain.
4. The on-chain contracts recognize that a Relayer has forwarded a transaction that was signed by ACME, so it pays the Relayer from ACME’s balance.
5. The network burn function destroys a portion of the funds until 50% of the initial supply is destroyed.

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.

Contracts

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.

API

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).

Governance

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.

Users

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

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.

Stages

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:

Ordering

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.

Join Types

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:

1. Verify Identity Agency injects normalized name, city, state information into the datafield of the Stage 4 (rating) of the Verify Identity relationship.
2. Request Credit Rating Agency injects a normalized score into the datafield of the Stage 4 (rating) of the Request Credit Rating relationship.
3. Borrow Lender injects the amount of credit into the amountfield of the Borrow Proposal and can later rate the borrower in the datafield of the Stage 4 (rating) of the Borrow relationship.
4. Purchase Selling injects the product description and price into the description and amountfields of the Purchase proposal. Later, the buyer and seller inject normalized ratings into the datafields of the Stage 4 & 5 (ratings) of the Purchase relationship.

Immutability

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.

Interpretation

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:

• Requested by the user, type: Verify Identity
• Accepted by the Rating Agency
• Close by the Rating Agency
• Rating Agency, injects name, city, state into the data field of Stage 4 record which makes the name, city, and state of the address observable on the blockchain by anyone. The UI should always de-obfuscate addresses with the most recent verified identity information if any exists.

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:

1. Estimating profile strength based on the number of transactions and the number of unmasked trading partners.
2. Weighing user rating raw data by the profile strength of those leaving the ratings, where greater weight is given to ratings left by more credible profiles, e.g. verified identities versus mysterious unknown signers.
3. Unusual activity detection such as attempts to create rich profiles in short periods of time.

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).