Address & Identity

Win-Win Condition

The Win-Win condition represents the utilization strategy for each participant in OpenCohort. This requires mutual cooperation between participants, so that each participant can leverage OpenCohort to achieve their goals and maximize benefits. When the Win-Win condition is met, participants can create optimal incentive opportunities while fostering the activation of the community and ecosystem.

• Partner: Partners aim to boost community engagement by offering incentive opportunities through OpenCohort to their community members.

• Builder: Builders utilize OpenCohort to help scale their project by onboarding community members who are unfamiliar with blockchain to the Web3 project.

• User: The user does not wish to engage in additional activities to receive incentives and already feels fatigued by similar reward programs from various projects. If the achievements and activities the user has already accomplished can be recognized in Web3, it would bring greater satisfaction.

• Silicon Blockchain: Silicon aims to facilitate entry into Web3 by making it easy for participants to obtain incentives without complicated wallet creation procedures or transaction fees.

• Additionally, each participant seeks to minimize costs incurred in this process.

Solution

Through Address & Identity Mapping, the Win-Win condition of each participant can be achieved.

• Partner: When creating a Cohort, Partners can use the Identity format instead of an Address. When Partners offer memberships, they use Manager to provide a Normalized Identity instead of an Address, which is represented in the format specified by the Partner. Externally, the Identity may appear as an Address.

• Partner: When a member of a particular Identity creates a blockchain wallet, the partner can map the wallet Address to that Identity through the Manager API.

• Builder: By managing a Cohort with Identities, Builders can provide airdrop incentives to members who do not have wallets. Even without a wallet, members with a specific Identity can trustlessly confirm incentives on the blockchain, allowing Builders to manage airdrop incentives more efficiently.

• User: Users can receive incentives based on their previous contributions or community activity, without the need for complex wallet creation steps.

• This process may slightly increase computing costs within the Manager or Prover's Storage, but the overall impact is minimal compared to the total data size.

Principle: Merkle Leaf Component Expansion

In the OpenCohort protocol, the membership components that serve as leaves of the Merkle Tree are structured as follows. Each participant can modify this structure as needed, but OpenCohort’s default API is based on the structure below:

• [uint256 index, bytes20 address, uint256 weight]

In this structure, the ‘address’ or ‘weight’ fields are not strictly required to be used for their intended purposes. Each field’s data can be utilized flexibly based on the participant’s choice. This allows OpenCohort to expand the concept of an 'address' to encompass not only blockchain addresses but also a flexible usage of the 1.46e+48 Number space in the bytes20 format.

Principle: Identity Mapping Signature

To use Cohorts on-chain, membership proof for bytes20 Identity is required. OpenCohort provides a signing feature that allows Partners to prove the mapping between Identity and Address. This enables the verification of Cohort membership across various on-chain applications, including airdrops and governance.

Partners provide a single Identity Mapping for each case. Users can obtain mapping information through the Prover and utilize it on the blockchain.

In summary, on-chain code such as Airdrop uses Proof to prove Cohort membership, and the connection between Identity and Address can be verified through a Mapping Signature.

Signer

In most cases, the entity that provides the identity mapping for a Cohort is the Partner. The Partner has full authority over providing membership and can link the Identity to a blockchain address, and the Airdrop has full control over which recipients to offer the incentive to. Therefore, the party offering the airdrop has complete authority to choose the recipients from the published Cohort membership list. If necessary, they can create a separate Cohort for the airdrop. However, if the existing Cohort’s Identity is used, a potential issue arises where the Cohort Owner and the Identity Mapping Signature provider's addresses differ.

To address this issue, OpenCohort provides the ability to set up a separate identity mapping signature provider for the airdrop target cohort. In this setup, signer will be the signature provider.

OpenIdentityRegistry

The Identity Mapping Signature is a value managed solely by the Partner (Signer). In cases of wallet loss or hacking, the Signer can change the Address mapped to a specific Identity at any time. However, this creates a problem where the previous Signature value is constantly in circulation. To prevent this, OpenCohort offers the following features via the OpenIdentityRegistry:

• Signers can register Addresses that are no longer supported.

• Delegates can register revoked Addresses on behalf of the Signer, using the Signer’s signature.

• When using Identity Mapping Signatures for applications like airdrops, it is possible to check in the Registry whether an Address has been revoked by a specific Signer.

Precautions

• Partners should ensure that no personal information is included in the data disclosed via Provers. Due to the nature of blockchain, information cannot be deleted or modified once information is disclosed. Any legal liability related to personal information rests with Partners, in compliance with relevant laws and regulations, rather than with OpenCohort or the Silicon Network.

• Signers are responsible for managing Signatures for the same Identity. When the mapped Address changes and the previous Signature value is exposed, issues like duplicate receipt or Signature reuse may occur. Therefore, Signers should exercise particular caution in protecting their private keys.