Share the love
Want to stay updated? Subscribe below to keep in touch.
Intro to Custom Signature Hooks on Portal
Integrate internal business logic into a transaction signing flow to keep users secure.
October 16, 2023
Portal is excited to introduce custom signature hooks, a new way of keeping users and your business secure. To execute most transactions on a blockchain, users have to sign, or approve, the transaction. This signature verifies that the user consents to their account being involved in the action, whether it is sending an NFT, connecting a wallet to an app, or conducting a swap. With custom signature hooks, the business providing the wallet can set up a custom hook that allows them to perform internal business logic before approving or rejecting the request from the end user to sign the transaction.
What are custom signature hooks?
Custom signature hooks allow companies to trigger approval business logic based on parameters including transaction value, transaction volume, types of signature, and more. The business logic can be anything that helps the company and/or end user make good decisions during the signing request process. A couple examples are auto-approvals (eg, auto-approving transactions below a certain value or volume) and two-factor authentication (eg, requiring approval for transactions above a certain limit). Another option is performing security checks, either internal or external, to prevent malicious activity.
Why use custom signature hooks?
There are a few common reasons developers use custom signature hooks. For example:
- Approving transactions - Most developers will prompt a user for approval before signing a message from a dApp or Wallet Connect
- Adding additional authentication - Developers can add extra authentication steps such as MFA to riskier transactions
- Checking transaction sizes - Developers can perform checks on transaction sizes to trigger specific authentication steps
Custom signature hooks can be passive, invisible to the user, or active, designed into the frontend UX with which customers engage.
A passive flow will generally be used to facilitate company goals, such as ensuring a user isn’t on a deny list. As such, the company can create a custom security check that is activated when a customer signs a transaction without them knowing. Transactions will continue as normal unless the user is found to be denied use of the app, at which time it will be rejected.
An active flow is visible to the user and can be used to offer a superior user experience. For example, companies can trigger MFA for transactions above a certain size, an example we will dive into next.
A common use case: MFA for large transactions
We show you how custom signature hooks can combine steps as mentioned above into a common use case: implementing multi-factor authentication (MFA) for large transactions.
As you can see, the developer prompts a user for a first approval to approve the swap taking place from the dApp Uniswap, before triggering a second approval based on SMS verification from the user due to the size of the swap. This extra layer of caution ensures a secure user experience because it prevents both errors in putting in numbers as well as potential malicious behavior.
This example shows MFA based on SMS verification, but you can use any form of verification such as biometrics or passkeys for example.
The best thing is the developer can only implement 2FA for large value transactions but keep it to a single approval for low value transactions, such as what is shown below, providing for a user experience that balances usability and security.
How developers implement custom signature hooks
The Portal signing approval flow is driven by a series of event hooks that take place throughout the lifecycle of a transaction. These hooks are as follows:
- portal_signingRequested - Emitted by the Portal Web3 Provider when a new signing request is received by the Provider
- portal_signingApproved - Emitted by you when signing a given request is approved
- portal_signingRejected - Emitted by you when signing a given request is rejected
The additional code binds to portal_signingRequested in the following pattern:
A company can implement any business logic they desire as long as the final output is portal_signingApproved or portal_signingRejected.
Test out custom signature hooks for yourself today! Book a demo today to see this feature live.