Factiiv | Whitepaper V 1.01 Updated

Factiiv whitepaper

V 1.01 | Updated


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.

Blockchain contracts
Web Server
Web UI

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.

Viral Structure

Acme Corp.
Smart Contract
Web App
Beta Corp.
record signatures
review and accept

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.

A Factiiv business credit score sticker on the storefront window of a participating business.

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.

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.

Id: 1
Id: 2
Id: 3

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:

Bytes32: typeKey- is a doc hash, id field, etc
Bytes32: payload value- the hash, id metadata, etc
Bytes: URL
Address: signer
Uint: blocknumber

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:

1. Anonymous

The default condition is users are known by Ethereum addresses.

2. Verified

The user’s identity has been confirmed by a Rating Agency, but has not been publicly revealed.

3. Revealed

The user’s identity has been confirmed by a Rating Agency and metadata has been written as (separate) attestations:

City: Toronto
State: Ontario
Country: Canada
Incorporation Number: 1234

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:

a) Verify identities and prevents duplicates before accepting the data
b) Avoid personally identifiable information for individuals

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:

  1. Exclusive form of payment of network fees such that no browser plugin or third-party wallet is required using meta-transactions and relayers
  2. Value is derived from demand for committing “facts” to the blockchain because there is no other way to pay for that activity
  3. Payment for services such as in-app agency services
    1. verify identity:
      1. Add “verified” badge (verified by anonymous)
      2. Add metadata (unmasked, revealed) *
    2. produce credit report
    3. produce reputation report
  4. Name: Factiiv
  5. Symbol: FACT
  6. Supply: 2 trillion, fixed
  7. 50% burn from transaction fees
    1. Relayer paybacks
    2. Incentive pools

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:

  1. Rewards will be allocated from the total supply and irreversibly locked in the contract for automatic distribution later on triggering events.
  2. Since a finite supply of reward tokens cannot pay a fixed reward indefinitely, the rewards will be paid on a declining scale at a rate determined by governance from time to time.
  3. Governance can change the reward rates:
    1. Fee on Relayer compensation
    2. Incentives for unmasking
  4. Anyone can add FACT tokens to the reward pool
  5. No one can withdraw FACT tokens from the reward pool

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.

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


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.


  1. General design (ongoing) Explore business objectives, identify important goals, consider technical feasibility and tradeoffs of alternative approaches and select exactly one option for each concern. Document the design decisions. Confirm management understanding of the plan and the implications, especially future optionalities that are ruled out by present-day decisions.
  2. Pre-Sale Develop presentations and descriptions and seek early funding. This is a non-trivial step that will likely involve a mult-talented team. Describe the “invention” from step 1. A discount of 50% for angel investors is typical. It is recommended to subject tokens sold at a discount to a vesting schedule.
  3. Prototype Depending on the complexity of the project, developing an MVP or Proof-of-concept can be a time-consuming and expensive procedure. The aim of step 2 should be to raise sufficient funding for the prototype as well as promotion. In this case, a debut release on testnet is suggested into order to gather speculative support for the project even while the design is further refined (user feedback).
  4. Launch The system goes live on a main network. Many aspects of the design are immutable at this stage, hence step 3. Quality assurance is crucial before preceding with step 4. Step 3 should surface obvious defects, however testnets do not prove economic design because no real value is at stake. Those incentives change when the system is live and governs non-trivial sums of money. Therefore, no responsible project should go live without a formal, independent audit of the smart contracts. Time and money must be allocated for this purpose.
  5. Growth When step 3 is successful, the founding organization is able to sell reserve tokens into secondary markets in order to raise further funding for product and market development.


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.


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:

sends message
forwards message
pays relay
Blockchain contracts
burns tokens
Burn function
  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.


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.

Data Structure

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.

Join: {
type: TypeId
description: bytes array
amount: magnitude
from: address
to: address
history: [stages]
arbitrator: address


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:


  1. Proposed: The sender requests consent of the receiver to open a relationship
  2. Accepted: The receiver agrees that a relationship exists


  1. Closed: Either party declares the relationship concluded
  2. Sender Attestation: The sender rates the receiver
  3. Receiver Attestation: The receiver rates the sender

Each such stage is represented by normalized fields:

Stage: {
lifecycle: type 1-5
data: arbitrary metadata
description: bytes array (only used in Stage 4 & 5)
signature: Eliptic curve signature

The known goal-oriented use cases can be decomposed into one or more Joins and Stages. For example:

a credit/payment history can be:
  1. Proposed by the lender
  2. Accepted by the borrower
  3. Closed by the borrower
  4. Borrower rated by the lender
  5. Lender rated by the borrower
A commercial sale or product review can be:
  1. Proposed by the seller
  2. Accepted by the buyer
  3. Closed by the seller
  4. Product/Service rated by the buyer
  5. Buyer rated by the seller


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.


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:

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

Agency Reports

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:

  1. The form and layout of the data is consistent for all reports of a given Join Type. The datafield is never used for free-form text unless the data type itself defines its use for that purpose. More commonly, the expectation is that it will contain a JSON object or a string with a specific meaning.
  2. The on-chain data should be brief - a few words, a hash, a url, etc.Lengthy reports should be delivered by means other than recording the information on-chain. Many delivery processes are possible:
    1. A url (or QR code) that opens the report or certificate
    2. A downloadable PDF with a proof-of-authenticity (hash) recorded on-chain

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.