Hooked #1: Smart Contracts on the XRP ledger
Tags: xrplhooks
Published: 2020-11-06 15:36:32

> ##### Please note
> Since this blog was published [a lot has happened](https://twitter.com/XRPLLabs/status/1545354585430171648). The Hooks Amendment is now running on a [public testnet](https://xumm.notion.site/Hooks-V2-staging-net-info-XLS20-518fa261c5cd49d2bcb89a5b9e7bef05) and has a [public "Builder" where you (devs) can code Hooks and deploy them to the testnet](http://hooks.xrpl.org/), straight from your browser.

## What are hooks?

Hooks are small, efficient web assembly modules designed specifically for the XRPL. Hooks can be written in any language (compilable to WebAssembly) and most business logic and most smart contract concepts can be implemented in a hook.

Hooks are *set* onto an XRPL account using a *SetHook* transaction. Once installed on an account, a hook can:

1. Block or allow incoming and outgoing transactions on the account.
2. Modify and maintain internal state and logic specific to the hook on that account.
3. Emit new transactions on behalf of the account.

Hooks are deliberately **not** Turing-Complete. While often touted as the *holy grail* of smart contracts, Turing-Completeness is actually inappropriate for smart contracts. The [Halting Problem](https://en.wikipedia.org/wiki/Halting_problem) describes the mathematical impossibility of predicting whether an arbitrary program will halt or run forever on a Turing-Complete system. Obviously this is undesirable, as we need to be able to determine ahead of time when a smart contract will complete execution. Therefore without restricting the general range of computation available to hooks, the hook code is required to be ***guarded*** against arbitrary run-time looping. This topic will be discussed at length in part 2 (to be published next week).

## Current state of development

The Hooks Amendment for *rippled* (to be *xrpld*) is being actively developed by **[XRPL Labs](http://xrpl-labs.com)** with the following planned releases:

1. An upcoming **Developer Preview** release in the form of a docker container within the next few weeks. 
2. An Alpha **Dev-Net** in Q1 2021

In addition to these releases we will be publishing our *rippled-hooks* repository and example hooks for developers to test and run.

## Working Examples

The Developer Preview will ship with three example hooks.

1. **Carbon-Offset Hook**

    Outgoing transactions on your account trigger an additional transaction to be emitted from your account for 1% of the spend of the original transaction. This emitted transaction is sent to a carbon offset account controlled by an NGO which will spend it planting trees.

2. **Firewall Hook**

    Malicious small transactions containing memos or outgoing payments to confirmed scam accounts are blocked. The hook has the ability to fetch a ***blacklist*** from another hook installed on a different account. This means the user does not need to update their firewall to remain safe. Additionally spending limits can be imposed by the user to prevent, for example, more than 10,000 XRP being withdrawn per day (i.e. every 21600 ledgers). 

3. **Lite Accounts Hook**

    Installing this hook on an account turns the account into a multi-user pool. The operation of this account is according to the internal rules of the hook as follows:

    Each **lite user** nominates a **public key**.

    To set up a lite account they need a friend to send a small opening balance to the hook, using the nominated public key as the **Invoice ID.**

    The hook then records the public key and assigns the user a **Destination Tag**.

    That destination tag now uniquely identifies that user.

    Any third party sending funds to the hook with that tag will call the hook to internally credit the lite user's account in the hook's state.

    To spend their balance, the lite user signs a message with their **private key.**

    This message is then attached as a memo to a regular transaction and sent to the hook account.

    Ideally the **master key** on the hook account would be disabled and the regular key black-holed to prevent unauthorised drawing of pool funds and leave the hook completely in control of the account.

## Tech stack

Hooks run on a three part stack:

1. **Rippled:** (C++)

    The Hooks Amendment is written in C++ as a modification the rippled source code.

2. **Hook Runtime:** [Wasmer.io](http://wasmer.io) (Rust)

    Wasmer is used as the Web Assembly run-time within Rippled.

3. **Hooks:** WebAssembly (C and Assembly Script)

    Hooks are written in C or Assembly Script (but can be written in any language that compiles to Web Assembly).

The Web Assembly runtime can be swapped out for another, however Wasmer is currently integrated and will be released with our first two releases.

---

Please check the [other blogs](https://dev.to/search?q=hooked%20xrpl&filters=class_name:Article), the [source & README's](https://github.com/XRPL-Labs/xrpld-hooks/tree/development/hook-api-examples) and ... just a **little** more patience as we're on track for a Q1 public testnet release :)

## Discussion

Discussions: [here »](https://github.com/XRPL-Labs/xrpld-hooks/discussions)