Signature-based gating
By default, blockchains and smart contracts are permissionless, and a user can interact with a smart contract in a number of ways, such as:
- Using the protocol's user interface.
- Using the user interface from another protocol.
- Directly submitting transactions to the blockchain.
To prevent unauthorized access, as well as gating the front end of your application, you must restrict access to the smart contract itself. This is essential for regulated companies.
Once access is restricted at the level of the smart contracts themselves, unauthorized access is completely prevented.
If you use this approach with a traditional KYC provider, you will need to handle the smart contract gating with a custom solution that will cost you significant time and money to develop and run: you need to build an off-chain allowlist, an on-chain allowlist, and a mechanism for synchronizing the two. This solution has two key drawbacks: there is operational cost to updating the on-chain lists, and the on-chain and off-chain lists are not always synchronized. Also, because of the public nature of the blockchain, other users can see when a user attempts to access a contract, including when they are denied access.
ComPilot's solution
ComPilot's solution is based on the unified user profile that each customer has in the ComPilot Dashboard. Rather than having separate on-chain and off-chain lists, a customer is allowed (or denied) access to a smart contract based on their status in the ComPilot Dashboard. (See Header.)
There is no operational cost to updating a customer's status, and because there is only one source of truth, there is no risk of allowlists or denylists getting out of synchronization. If a customer is authorized, ComPilot signs the transaction and the smart contract can then verify the signature before allowing access. Only the signed transaction appears on the blockchain: if a customer is denied access, the transaction is not submitted, and their privacy is preserved.
The solution has three components:
- An API endpoint (
get-tx-auth-data-signature
) that provides signatures that allow to authenticate users on-chain. This is called by the front end of the application before a customer performs a transaction that needs to be authenticated. - A dependency smart contract (
TxAuthDataVerifier
) that verifies the transaction signature on-chain. This is connected to your smart contracts, allowing them to gate access. - The ComPilot Identity SDK that simplifies the interaction of the application with the API endpoint.
Once the user has gone through the ComPilot KYC process (and therefore has a profile on the ComPilot Dashboard) the flow proceeds as follows.
The user authenticates with their wallet (1) and prepares an action (2). Then the front end generates a transaction and requests a signature through the ComPilot API (3). The API checks with the ComPilot user profile (4), and if the user is approved, the API signs the transaction and returns it to the front end (5). The front end constructs the final transaction and presents it to the user for their signature (6). The user publishes the transaction which is sent to the signature verifier smart contract, TxAuthDataVerifier
(7). If the signature is valid, the transaction is sent to the gated smart contract.
Other than the final two steps, the flow happens off-chain, reducing operational costs and preserving the privacy of the customer during the verification process.
You can use ComPilot's solution by following these steps:
- Screen your customers using ComPilot KYC and the ComPilot Rules Engine. You can also manage your customers in the ComPilot dashboard.
- Update your smart contracts to connect them to
TxAuthDataVerifier
. - Update your front end to use the signature.
The Smart contract gating developer documentation describes how to perform steps 2 and 3.