Access Tokens and User Authentication

Only for users with >$1k in assets.

The process starts with a user verifying compliance associated with their address. The user then submits the certificate and an access token to the Hinkal server. The access token is created by hashing the user's shieldedPrivateKey and combining it with their PublicKey (which is itself a hash of the shieldedPrivateKey).

Hinkal's server communicates with the provider to verify the certificate's authenticity. To map an access token to a user's real-world identity, both the provider and the Hinkal server must cooperate, offering an additional layer of privacy. However, this privacy could be bypassed if regulatory authorities require both parties to reveal the stored information for compliance reasons. Even in such cases, users who comply with regulations remain unaffected.

Once the certificate is validated, the Hinkal server signs a message containing the access token, chain ID, the address of the Hinkal authentication contract, and a nonce to prevent replay attacks. The user can then interact with the CrossChainAccessToken contract by submitting this signed message along with signature data and the required minting fees. On-chain verification ensures that the signature is legitimate, and the access token is then added to the Merkle tree.

The CrossChainAccessToken contract supports cross-chain operations, allowing users to move their access tokens between different blockchains. If an access token is invalidated due to non-compliance, the contract owner can remove it from the Merkle tree.

After this setup, whenever a user wants to interact with Hinkal, they must generate a zero-knowledge proof (ZKP) proving ownership of the shieldedPrivateKey linked to an access token in the Merkle tree. Since only the Merkle tree's root hash is used as a public input, the specific access token involved in the ZKP remains hidden, maintaining the user's privacy.