This picture will be mintable soon

Introduction to DeFi Part 2 – Discover Hooks

Part 1 covered financial institutions, decentralised finance, financial sector technical issues, and some DeFi aspects like risk mitigation. Following that, we looked at various important technologies and innovations like staking, minting, wrapping, and of course Hooks. Part two will delve deeper into XRPL-specific technologies, with an emphasis on HOOKS, its origins, and the community challenges it wants to answer. The two-part approach’s overarching goal is to educate the community by starting broad and putting everyone on a level playing field with a basic comprehension of financial lingo.

Hooked – What Are Hooks?

The inclusion of the “HOOKS” feature within the XRP Ledger is a captivating and novel addition. Within the confines of this article, we shall delve into the origins of this concept, its noteworthy implications for inventive developers and enterprises, the diverse applications and constraints of Hooks, as well as the current and impending challenges that such groundbreaking technologies encounter in the realm of Cryptocurrency.

Hooks constitute specialized web construction modules exclusive to the XRPL (XRP Ledger), boasting a blend of compactness and efficiency. They have the capacity to encapsulate a vast array of business logic and principles of smart contracts, irrespective of the language employed, ultimately compiled into WebAssembly.

Renowned for its exceptional transaction throughput, rapidity, and nominal transaction fees, the XRP Ledger has garnered widespread acclaim. The XRPL encompasses an assortment of sophisticated transaction types, encompassing multi-signature protocols, escrows, payment channels, and even a decentralized exchange – all natively integrated within the ledger’s architecture, devoid of the need for smart contracts. While the XRPL already presents a formidable array of features, XRPL Labs has recognized that developers and enterprises necessitate a high degree of latitude, enabling them to construct not solely what is conceivable today, but also to anticipate future requisites and those that extend beyond.

The blueprint of several on-chain attributes for XRP highlighted the viability of implementing a majority of these in a non-custodial manner, directly on the blockchain. This direction stems from the pragmatic stance that many developers and enterprises, including XRP itself, lack the inclination (or requisite regulatory authorization) to oversee user funds and custody obligations. Envision the potential implications of diverse enterprises, inventive developers, and novel use cases unearthing a versatile avenue to integrate on-ledger business logic into XRP transactions. It was in response to this scenario that the concept of the “Hook” was conceived.

Hooks offer a two-fold functionality: they facilitate the execution of efficient logic and simultaneously enable the storage of succinct data objects. For instance, in the context of incoming payment transactions, one could scrutinize whether the sending account aligns with a predefined list maintained by another Hook, and if so, opt to either reject or permit the transaction based on the desired action. This is manifested through a “SetHook” transaction, utilized for attaching Hooks to an XRPL account. Following the installation of a Hook on an account, the ensuing capabilities are unlocked:

  • The authority to obstruct or authorize incoming and outgoing transactions associated with the account.
  • The capacity to alter and sustain the internal state and logic specific to the account’s Hook.
  • The autonomy to initiate fresh transactions on behalf of the account.

XRPL Labs is currently immersed in contemplation, formulating a strategic blueprint for actualizing this concept. The envisaged trajectory involves the transformation of this concept into open-source code and a proof-of-concept iteration. Subsequently, the initial version will be constructed, subject to rigorous testing on their private XRPL testnet before transitioning to the public network. The primary objective is to channel their efforts toward all endeavors necessary to fortify the resilience and integrity of the XRP Ledger.

All Things Turing and Complete

Hooks, by design, deliberately lack Turing completeness. Although Turing completeness is often celebrated as the ultimate aspiration for smart contracts, it proves to be unsuitable in their context. Within a Turing-complete framework, the Halting Problem underscores the inherent mathematical conundrum of determining whether an arbitrary program will terminate or perpetually persist.

Turing completeness denotes a mechanism capable of unraveling any computational enigma, regardless of its intricacy, provided ample time, memory, and accurate instructions. Given that the majority of contemporary programming languages adhere to Turing completeness, this term has become synonymous with their characterization – an example being C++.

XRPL Hooks intentionally embrace Turing incompleteness, as heightened intricacy could potentially breed perplexities. The adept engineers possess the ability to predict, with remarkable precision, the ledger’s response across the finite spectrum of scenarios in which it is employed by upholding simplicity. It is imperative that we possess the capability to anticipate the culmination of smart contract execution in advance. Consequently, the Hook code must be fortified against arbitrary runtime looping, while concurrently preserving the fundamental gamut of computational capabilities inherent 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.

Illustrations of Hooks in Action

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.


Although hooks cannot call other hooks, developers are able to chain hooks together (with a maximum of 4) on 1 account and have them executed in a sequence. Custom Hooks allow developers to also use Javascript functions and share logic such as HOCs and Render prop (a methodology for sharing code).

The community has embraced the technology and is putting it to good use in a variety of ways (some discussed above, others have ideas boiling in their minds). Splitting payments to numerous wallet addresses and restricting payments to specific accounts from certain wallet addresses are two instances of popular features that have been well received by the community.

  • Because the functionality is complete and the code is already in WebAssembly, Test Net 2 will be released soon.
  • The built-in feature of rejected inefficient Hooks ensures resource usage may be minimised, permitting Hooks to continue to work quickly and cheaply.
  • Sophisticated multisign scenarios are anticipated to gain in popularity.
  • Although the prospect of applying functional business logic has piqued the community’s interest, we are still in a stage of development that requires attention.
  • The price of Hooks is one area where there is some unpredictability. Hooks are now deployed on a developer-controlled account rather than being applied to your personal wallet address, and the cost is comparable to a Trustline. Therefore, we may see the design and implementation of more elaborate and formidable Hooks in the near future, raising the cost foundation for this technology.

XRPL Labs believes that there is a collection of factors to consider and discuss, such as the price model: how can they activate the Hooks feature without allowing Hooks to be used to spam the XRPL? Alternatively, what will the Hooks environment look like (WebAssembly?). Did they think of all possible edge cases, and do the solutions and implementations they came up with supporting all of the use cases they had in mind? Does the ensuing solution have the potential to scale?

According to XRPL Labs, while they’ll be spending more time crunching numbers, designing, and coding, they are ecstatic to be able to work and cooperate with amazing people and technology in a world where we can all contribute and share ideas, enhancing and adding to the transparent and decentralised XRP ledger. It’s a delicate balance between time and execution. Needing some time, XRPL Labs remains thrilled about interacting with community members, developers, and businesses, testing, integrating, and, potentially, launching.

Jack Dunam
Jack Dunam