Hooked – What Are Hooks?

The XRP Ledger’s “HOOKS” feature is a fascinating new addition. In this article, we’ll look at where the idea came from, why it was considered a significant advancement for creative developers and businesses, the use cases and limitations of Hooks, and the current and future issues that such innovative technologies face in the Cryptosphere.

Hooks are XRPL-specific web construction modules that are compact and efficient. Most business logic and smart contract principles can be implemented in a Hook, which can be written in any language – anthologised to WebAssembly.

The XRP ledger is well-known and well-liked for its high transaction throughput, speed, and low transaction fees. The XRPL has a lot to offer businesses and (creative) developers when it comes to advanced transaction types like multi-sign, escrows, payment channels, and even a decentralised exchange-all on ledger, out of the box, without requiring smart contracts. While the XRP ledger already has a lot to offer, XRPL Labs understands that developers and businesses require a lot of freedom, allowing them to build not only what is possible today, but also what they can foresee tomorrow and what comes after tomorrow.

While planning several on-chain features for XRP, it became clear that the majority of them would be better-implemented on-chain, non-custodial, because XRP (and many other developers and businesses) don’t have (or want to gain) the necessary licenses for managing user funds, custody, and so forth. Consider what would happen if additional businesses, innovative developers, and use cases discovered a versatile way to integrate on-ledger business logic to XRP ledger transactions. Thus was born the “Hook”.

Hooks enable the storage of small, simple data objects in addition to executing efficient logic, for example: for incoming payment transactions, one can check if the sending account is in a list maintained by another Hook, and if present, reject the transaction if that is the desired action. As such, a SetHook transaction is used to add Hooks to an XRPL account. A Hook can do the following once it’s been installed on an account:

• Incoming and outgoing transactions on the account might be blocked or allowed.
• Modify and maintain the internal state and logic for that account’s Hook.
• Create new transactions on the account’s behalf.

XRPL Labs is currently pondering the situation and creating a plan for implementation. They are going to transform it into open source code and a proof of concept, then build the first version and test it on their (private, then public) XRPL test net. It’s their intention to concentrate on everything that’s needed to safeguard the XRP Ledger and its future: security, stability, performance, and usability in the broadest sense, for business cases, developers, and so on.

All Things Turing and Complete

Hooks aren’t Turing-Complete by design. While Turing-Completeness is sometimes hailed as the holy grail of smart contracts, it is really improper for smart contracts. On a Turing-Complete system, the Halting Problem describes the mathematical impossibility of predicting whether an arbitrary programme will halt or continue indefinitely.

Turing Complete refers to a machine that can solve any computational problem, no matter how difficult, given enough time and memory and the proper instructions. Because most modern programming languages are Turing Complete, the term is commonly used to characterize them, e.g. C++.

XRPL Hooks are Turing Incomplete because increased complexity could cause complications. The engineers can forecast with great accuracy how the ledger will react in the finite number of situations in which it is utilised by keeping it simple. We need to be able to predict when a smart contract will finish execution ahead of time. As a result, the Hook code must be protected against arbitrary run-time looping without limiting the basic range of computation available to Hooks.

The Present State of Affairs

The Hooks Amendment is being actively developed by XRPL Labs and the following releases were really what opened up the technology to the community of developers in 2021.

1. An upcoming Developer Preview release.
2. An Alpha Dev-Net in Q1 2021.

XRPL Labs also aims to make their Hooks repository and sample Hooks available for developers to test and execute in addition to these releases.

Hooks in Action Examples

Three example Hooks will be included in the Developer Preview.

Hook with a Carbon Offset

Outgoing transactions on your account cause an additional transaction worth 1% of the original transaction’s spend to be sent from your account. This emission transaction is sent to a carbon offset account managed by a non-profit organization, which will use the funds to plant trees. Imagine Green NFTs where 1% of each NFT variant sold goes to a carbon offset account or enables the adoption of sustainable energy through partnerships with companies like Melanin Solar that are incentivising the uptake of green energy among Indigenous Communities by using the Whive Protocol.

Hook for the Firewall

Small transactions involving notes or payments made to proven scam accounts are banned. A blacklist can be retrieved from another Hook installed on a different account using this Hook. This means that the user’s firewall does not need to be updated in order to stay protected. Furthermore, the user can set spending limitations to prevent withdrawals of more than 10,000 XRP each day, for example (i.e. every 21600 ledgers).

Hook for Lite Accounts

When you add this Hook to an account, it becomes a multi-user pool. The following are the internal Hook rules that govern the operation of this account:

• A public key is chosen by each lite user.
• They’ll need a friend to transfer a tiny initial balance to the Hook, using the nominated public key as the Invoice ID, to set up a lite account.
• The Hook then saves the public key and adds a Destination Tag to the user.
• That user is now uniquely identified by that Destination Tag.
• Any third party transferring money to the Hook using that tag will cause the Hook to credit the lite user’s account in the Hook’s state internally.
• The lite user signs a message with their private key to spend their balance.
• The Hook account receives this communication, which is added as a memo to a routine transaction.
• To preclude unauthorised withdrawals of pool monies, the master key on the Hook account should be disabled and the normal key black-holed, leaving the Hook in sole control of the account.

Hook Execution Fees

Gas costs are always a worry in the NFT world, and as we all know, running massive activities on blockchains takes a lot of energy, which results in fees. This is how HOOKs looked at resource use. To mitigate ledger spam and excessive validator resource consumption, Hook fees will be applied to ledger fees hinged on the maximum Hook execution duration. In the worst-case scenario, an ineffective Hook may be rejected. One of the reasons for having a native token (XRP) on the ledger is to prevent spam on the ledger, which is critical for its stability and usability.