The 2key web3.0 core architecture generates a new micro-economy around each campaign smart contract. This is facilitated by the ARC (Activation Referral Contract) token — a new token distribution minted in dynamic balance for each campaign, and maintained in dynamic balance for each referrer -allowing to continuously optimise the topology of the referral graph as each campaign is being played out. The ARC tokens act as the means of referral, as well as the means of conversion. The balance of a specific campaign’s ARCs one has determines this participant’s allocation for inviting others to join/fulfill the campaign. Holding ARC tokens for a 2key campaign in your wallet only means you have the right to either fulfill this campaign’s required result, or refer this campaign onwards. As both referrer and converter, a participant is eligible for rewards and reputation for being proactive towards delivering the campaign’s target results.
ARCs are only potentially worth money and reputation (i.e. economic and social capital), and to fulfill their potential you must either use them to convert in the campaign or spread them onwards. ARCs can actually generate referral rewards and reputation only if you successfully pay them forward — either by referring them to someone who will convert, or referring them to someone who will refer them onwards to eventually find someone who will convert. Of-course, possessing ARCs for a 2key campaign means someone before you in the referral chain thought this campaign might be of interest to you you, and you can also utilise the ARCs to fulfill the campaign objective yourself, which would earn you discounts per your existing reputation and further your reputation as converter.
When someone who receives a specific campaign’s ARC tokens uses them to fulfill the campaign, once the conversion is verified, the underlying 2key campaign contract will automatically distribute the referral rewards in 2KEYs (2key Tokens) and update the reputation scores in the campaign’s category for the referrers in the converting chain.
Web2.0 Bridge Architecture
For anyone using a web3.0 wallet supporting ERC20 tokens, referring is as easy as passing along tokens. In our novel web2.0 bridge architecture, these ARCs and underlying 2key smart contracts are wired into the HTTP links via the 2key protocol, allowing links and link sharing to act as valid transactions in the supporting 2key smart contracts. Therefore, for anyone using web2.0 clients, referring is as easy as passing along links.
In terms of conversion tracking, the ARC itself is the means of conversion, and depending on the type of contract, the conversion tracking and validation (these are 2 distinct scopes) will work differently.
Generally speaking, a 2key HTTP link, once pressed, invokes a web2.0 client (internet browser) to become an ad-hoc, decentralised 2key node for interfacing with the campaign contract (receiving ARCs, referring ARCS and interacting with the underlying 2key campaign contract). The browser then becomes also a wallet and an ID proxy; The user can use this 2key browser node to generate a secure wallet with a private key stored in the local storage (similar to metamask, just with no plugin/extension install), or else connect the browser to an existing external wallet (e.g. metamask). In addition, explicit identification via federated or sovereign ID providers is enabled to make sure the 2key network is participated by actual humans identifying as themselves and thus also amassing social capital in their own name. This is crucial to maintain a secure network layout against a host of attack vectors, bot schemes, collusion networks etc..
One can also interface with the 2key network via the 2key mobile apps, which act as full 2key nodes and also function as a dedicated and secure 2key wallet and an ID proxy to the same types of ID providers mentioned above.
On the pure web 3.0 front, anyone using an ERC20 compliant client, should be able to refer ARCs onwards and fulfill (i.e. convert) campaign required results directly via the ARCs in the wallet, as these ARCs are smart tokens directly associated with the 2key campaign contract, and their balance allows for privileges to activate specific functionality in the contract. In this pure approach the web3 address of the participant is their client wallet address, but their social ID to be associated with their gained or lost reputation will still have to be explicitly extracted via some decentralised sovereign ID provider, not as a technical necessity, but from a Game Theory perspective of ensuring humanity of the players and derailing sybil attacks and the likes.
Conversion events differ depending on the type of contract, but in general, a conversion event requires either:
- Inputting information into the contract (text,media etc..)
- Inputting 2KEYs into the campaign contract to purchase a product, asset or service or to acquire the rights to such.
- Consuming content stored in IPFS nodes (e.g. HTML etc..) linked from the 2key campaign contract or consuming content stored in a web2.0 url.
- Installing an application via dedicated deep links accredited to the contract, accessed via the contract.
- Signing an agreement via a sub-contract to the 2key campaign (e.g. signing an employment agreement/gig-contract etc..
- 3rd party conversion event integration.
In most cases the conversion event is simply an interaction made with the 2key Campaign contract, facilitated by either the web2.0 interface supported by the 2key HTTP protocol using any HTTP compliant client (e.g. web browsers), or by the pure web3.0 interface supported by any ERC20/ERC721 compliant client, or by the 2key mobile nodes (2key iOS and Android apps) which act as a dedicated 2key wallet optimised for interfacing with ARCs.
Regarding validation of conversion events, this acts differently on different campaign types. A large portion of the 2key campaigns are projected to be acquisition campaigns. In such campaigns, converters purchase a product, service or asset, or the right to such, and the conversion event is self-validated by the actual transfer of payment in the form of 2key Tokens by the converter into the campaign contract. Other campaign types might require to utilise a moderator in the contract, either for validation of the conversion, or to act as a mediator in cases of dispute in campaigns where the validation is performed by a party of interest (e.g. Leads contract where the leads are qualified by the Contractor herself). In yet another class of campaigns, the conversion validation will be facilitated by a blockchain service provider which is integrated with the 2key campaign contract, and is serving the use case in a dedicated manner (e.g. a blockchain ticketing dapp whereby the purchase of tickets is validated).
2key Campaign Moderators
2key Contract Moderators are service providers selected by the contractor generating the 2key campaign. In principal, the moderator’s goal is to optimise and facilitate the campaign, usually filling up to 5 major role types in the campaign: (1) serve a proprietary incentive model (2) assist with dispute resolution (3) validation of converter/referrer ID conditions prior to joining/fulfilling a campaign (4) validation of conversion events (5) financial insurance of transactions (e.g. paying for txs via gas station, refunds in case of misshaps etc.) The 2key network economy is open and allows an open market for companies to offer their services as moderators in 2key campaigns. The moderators operate on a fee based model, and will have to offer competitive fees and high level of service in order to be selected by contractors.
In addition, part of the fee per conversion which the moderator receives, is utilised as a network tax, and is either back-propagated to the global reputation rewards pool, or is sent to the locked up future supply pool. This acts to either take a cut of the 2KEYs out of distribution or to ensure the replenishing supply of the global reputation rewards pool. Both options effectively spread the profit gained by network moderators to the network at large, effectively ensuring large scale market viability. This allows the business model of service providers in the network to be closely connected to the tokenomics of the 2key network.
Contractors are free to choose whether or not to utilise a moderator, and if so, which moderator to choose. It’s important to note that while a moderator has several oracle-like responsibilities and authorities in the contract, the contractor is free to choose which roles, if at all, a moderator plays in their contracts, and more so, mostly all contract types on the 2key network can be activated and played out with no moderator involved at all. 2key Ltd. will be serving as the first opt-out default moderator on contracts in the 2key network, by which it will serve its proprietary incentive model and in some cases also provide conversion/converter validation, gas station services for mitigating main-chain transaction costs and dispute resolution services.
Referer Validation and Converter Validation
Apart from the validation of actual conversion events, in some campaigns the contractor may specify conditions on the identity of referrers and converters. These are apriori conditions that must be met in order for a participant to qualify as a referrer or converter. These may include conditions on age, gender, location and other attributes. We aim to handle these types of validations in two main methodologies:
- Auto-Validation via decentralised sovereign ID solutions — for example anyone signing on a referral chain using their civic or uport IDs, can allow for the 2key campaign contract to automatically ascertain identity conditions, allowing for this validation process to run automatically by the 2key contract and in distributed fashion.
- Auto-Validation via a moderator service — a contractor may set up the required validation conditions in the 2key contract and then elect a moderator to automatically validate that these conditions are met before enabling new referrers and converters to join or fulfill the campaign.
Let’s now have a closer look at how conversion tracking and validation occurs in the main 2key campaign types:
Information Campaigns:
→ Required Result: information (text,media etc..) answering a question, or detailing/expanding some professional/subjective subject matter, or sharing personal experiences. This can be uploading a geo-tagged photo of a wanted person’s whereabouts for a police campaign, or sharing side effect experiences for a pharma company’s mass-scale clinical trial campaign, or explaining a subject matter in depth for a startup’s wiki bounty campaign, or providing clues in a social wisdom campaign
→ Conversion Tracking: information is inputted by the contractor directly into the contract, or via potential partnerships with other public ledger projects (e.g. Kauri) facilitating the conversion.
→ Conversion Validation: depending on the type of sub-contract, validation can be obtained by different means:
- Statistically Verifiable Info: In some cases (e.g. wanted person whereabouts), there can be statistical tests to verify the validity of the info inserted by converters. For example, if enough different people point to the same location, we can ascertain that the information provided is a valid conversion event. We project the majority of information contracts will be prone to statistical validation, performed online by the campaign contract.
- Private/Subjective Info: In some cases where the information being inputted is personal, it becomes more of an attestation of the participant. In these cases, there may be two general types of scenarios: (i) Self Signed Info: The converter self-signs the info, and it is considered valid so long as it doesn’t contradict previously inputted personally attested info. The self-contradiction can be handled algorithmically directly by transparent smart contract logic/models. (ii) Auto Signed Info: In the future of sovereign identity and personal information attestations on the blockchain (e.g. uport), we foresee easy integration with such projects for enabling on-chain decentralised verification of various user information attestations.
- Contractor Approved Info: In some cases, the campaign conversions will be pending approval from the contractor. In such cases the contractor may elect a trusted 3rd party moderator to handle information validation to improve trust and participation by other parties in the contract (i.e make the 2key campaign more appealing and less risky for referrers to join and converters to fulfill)
Lead Generation Campaigns:
→ Required Result: Converters sign their own contact info attesting their will to be contacted by the Contractor as prospective clients/ customers/ consumers of the Contractor’s services/products/offerings.
→ Conversion Tracking: There are generally two types of campaigns for Lead Generation:
- Simple word of mouth — where the personal recommendation from the referrer is the main delivery parcel of information, and any required content e..g HTML can be referenced form IPFS in a link from the 2key contract. In these contracts, the Lead Generation itself happens via a simple input of information into the 2key Contract. This scenario is handled similarly as in simple information contracts, since all is required is some form of contact info inserted into the contract (e.g. phone number, email, telegram account etc..). In cases where the converter has a login method to the web2.0 interfaces (webapp, mobile apps) — the converter can use their federated ID (facebook, google, linkedin) or sovereign ID (uport, civic) in order to both sign the conversion event, and in some cases (as in uport, civic), these can also serve to auto-validate the conversion.
- Graphic / Dynamic Lead Generation Page (LGP) — Currently, there’s an entire industry around Lead Generation, and it usually involves dynamic websites which also have a call to action to leave contact info for becoming leads. In such cases, 2key as moderator, and later other moderators, may offer services of hosting/mirroring/proxying such LGPs, and to handle the pixel and event streaming from the browsers of converters leaving their details. In these cases, the way the 2key moderator works is to host these pages and perform the tracking of events. So for these scenarios the 2key HTTP links will lead to the LGP, and the moderator will mediate the join function in the contract on top of it, graphically, so that someone landing on the page and not interested in the service/product described, can also elect to pay it forward as referrer. This type of solution will require these types of campaigns to be run only via the web2.0 interfaces.
→ Conversion Validation: In lead generation there are usually two parts to result validation: (i) Validating the converter left their own correct contact info (ii) Validating the true intent of the converter to consider purchasing or otherwise fulfilling the Contractor’s service/product/offering.
- Contact Info Validation: This can be auto-asserted in a decentralised manner if the user is using decentralised sovereign ID solutions e.g. uport,civic. In some other cases of using federated ID providers, this can also be auto-asserted but in a trusted manner vs a trusted ID provider (facebook,google,linkedin). In other cases It will have to be validated manually by the contractor. We foresee that with time, sovereign IDs will become widely adopted and enable decentralised automation of this portion of the validation.
- Lead Intent Verification: This is a fuzzy subject matter, and initially will require manual approval by the Contractor (although some projects are currently trying to provide automated lead qualification, e.g. Exceed.ai, and might prove ripe for integration into the 2key contracts at a later point in time). At this point, the final approval for a lead is manually signed by the Contractor into the 2key contract (via the various 2key interfaces). In such cases, most contractors would probably elect a moderator to function as a trusted mediator in dispute resolution, to increase adoption and trust and minimise risk to the referrers and converters in the campaign.
Acquisition Campaigns:
→ Required Result: In these types of campaigns the required result is for a converter to insert money in form of 2key Tokens into the campaign.
→ Conversion Tracking: In this case the conversion itself is automatically and trivially tracked by the transfer of 2key Tokens as payment by the converter.
→ Converter Validation: In such cases as a Token Presale campaigns, the contractor will usually set up KYC requirements for converters, and assign a moderator to fulfill the validation as prerequisite to any conversion event. (2key will also offer this moderation service right from the start)
→ Conversion Validation: Depending on the inventory being sold, the validation will take different routes.
- Fungible ERC20 Assets: any fungible asset sold, e.g. tokens, will hold as validation process only the availability of the inventory (this is taken care of by the 2key campaign contract itself).
- Non-Fungible ERC721 Assets: the validation process of conversion itself is a dedicated process meant to assert the intent to purchase the actual instance sold, and its availability, and will also be automatically performed by the contract.
- Ledger Supported 3rd Party Solutions: In some cases, 2key can integrate with other blockchain solutions enabling acquisitions of certain products over the blockchain. We’re seeing several of these projects being built currently over Ethereum, using uport as ID proxy. In such cases, 2key can easily offer acquisition referral campaigns that integrate with these services to conduct the validation of conversion via these online integrations.
→ Delivery Dispute Resolution: For anything being sold over the public ledger, the 2key campaign contract will usually either holds in escrow the inventory itself (e.g. ERC20 tokens being sold), or the right to transfer units of the inventory or the right to such from the possession of the seller to the buyer at time of purchase, or else the 2key contract holds the right to assign proof of ownership or proof of right to the service/product being sold. We foresee that with time more and more services and products will be enabled for purchase over public ledgers, enabling a very easy integration of both conversion tracking and delivery of goods and services. In certain cases however, the assets, services or products sold via the 2key campaign cannot be delivered online. For example, as opposed to tokens which can be delivered directly online, sits in an upcoming yoga course are delivered by the contractor offline. In such cases, the conversion occurs by purchasing the sit in the yoga class and having the public/defendable/legally binding right to a sit in the yoga course assigned to the converter via the public ledger. There still may be, however, cases where the actual offline asset/service/product wasn’t delivered, and in such cases, a moderator handling dispute resolution / purchase insurance will be sought by the prospective converters and referrers, and thus there’s a good projection of having a market for such services in the 2key network.
Content Campaigns :
→ Required Result: In these 2key contracts, the contractor is typically a publisher, desiring more people to consume a piece of content (usually some HTML). This HTML is stored in IPFS or directly linked from the contract, and conversion occurs under various conditions set up by the Contractor (time spent on page, click through to content etc..).
→ Conversion Tracking:
- Simple Linking — Auto Tracking: In case the required result is simply a click into the content, this can be automatically asserted by the 2key contract either by referencing access to the HTML over IPFS linking, requiring an explicit request for the content link from the converter, or by linking directly to the browser with the end link for the content on the publisher’s site.
- Custom Conversion Events — Moderator Hosting & Tracking: In case the conversion event is more complex, same as with LGPs, a moderator can host the content and track the conversion events.
- B2B Integrations: Since publishers tend to be big businesses with technical knowhow, we’re also considering producing a 2key share widget which can be easily embedded into the publishers’ existing webpages, to harness the social sourcing power from their existing traffic. In such a way, the 2key contracts’ interface will be served directly from within the publisher’s domain, one contract per article/piece of content..
- Conversion Validation: in case of simple linking, the validation is also automatic and trivial, while in custom conversion events, the moderator is the one to validate, and also the one to handle disputes.
Install Campaigns:
→ Required Result: install of an application, usually mobile.
→ Conversion Tracking & Validation: this is a future vertical, but we project this should be enabled by deep-linking from the 2key contract to the app stores, or by direct integration with the apps themselves.
HR Campaigns:
→ Required Result: acceptance of applicant into new job.
→ Conversion Tracking: In these cases, the conversion tracking can take place either by the Contractor/Converter signing online or via dedicated integration with other service providers (e.g. comeet)
→ Conversion Validation: In HR contracts, the validation can either occur through mutual agreement on state of agreement between converter and contractor, or by 3rd party moderator or integrations (e.g. with comeet)
