Please note
Since this blog was published a lot has happened. The Hooks Amendment is now running on a public testnet and has a public "Builder" where you (devs) can code Hooks and deploy them to the testnet, straight from your browser.
(Cross post: this article was posted here on July 30th 2020. More blogs have been published since)
XRPL Labs is working on the transaction "HOOKS" amendment for the XRP Ledger. Supporting business logic integration for developers.
The XRP ledger is known and is being appreciated for its transaction throughput, speed and the low fees. Combined with available advanced transaction types like multi sign, escrows, payment channels and even a decentralized exchange (all on ledger, out of the box, without requiring smart contracts) the XRPL has a lot to offer businesses and (creative) developers.
At XRPL Labs we build XUMM (and other, smaller libs. and projects). While building a product & business leveraging just about all things the XRPL has to offer, we’re continuously looking at the XRP ledger from developer, consumer and business perspectives.
We realized that, while the XRP ledger already has a lot to offer, developers and businesses need a lot of flexibility, allowing them to not only build what is possible today, but to build what they can imagine tomorrow. For XUMM, we’re looking at tomorrow (and the day after, our three year roadmap and beyond)
Think about (just to name a few):
Auto saving on incoming transactions. Automatically park VAT, send a part of your received on ledger pay to your holiday savings account, …
An on ledger Tip / Gift platform (bot), to individuals, charities, opt in infrastructure (validator) rewards, etc. Using “Lite Accounts”, without account reserves.
“Lite Accounts” so businesses can assign & track loyalty points for all their customers, on ledger, without having to activate their account.
On ledger subscriptions to advisory lists like the XRPForensics list, to auto block incoming & outgoing transactions from and to scams, no matter the used XRP ledger client
Storing account based flags, like “did this user perform and passed KYC”
On ledger if/else (or more advanced) conditions on incoming or outgoing payments, based on your own logic, possibly using data provided by oracles
While envisioning multiple on ledger features (samples below) for XUMM, we quickly realized that most features would be best implemented on ledger, non custodial, as we (and many other developers and businesses) don’t have (or want to get) the appropriate licenses for handling user funds, custody, etc. And we were only talking about the features we could come up with. Imagine what would happen if other businesses, creative developers, use cases out there found their way to a flexible way to add on ledger business logic to transactions on the XRP ledger.
We decided to call our idea “Hooks”. Transaction Hooks. They are small, efficient pieces of code being defined on an XRPL account, allowing logic to be executed before and/or after XRPL transactions. These hooks can be really simple, like: “reject payments < 10 XRP”, or “for all outgoing payments, send 10% to my savings account” or more advanced. By allowing hooks to not only execute efficient logic but also to store small, simple data objects, one could define a hook like: “for incoming payments transactions, check if the sending account is in a list maintained by another hook, and if present: reject the transaction”.
We are currently thinking things through, drafting what an implementation would look like. We’re turning that into open source code and a proof of concept, then to develop a first version and run it on our own (private, after that: public) XRPL testnet. We’ll be focussing on everything required to protect the XRP ledger and its future: security, stability, performance & usability (in its broadest sense, for developers, business cases, …). There’s still much to think about and discuss before we will publish more details, like the fee model: how do we enable the Hooks feature without allowing Hooks to be abused to spam the XRPL? Or: what is the Hooks environment going to look like (WebAssembly?). Did we cover all edge cases we can think of, and does the solution & implementation we ended up with support all use cases we initially thought of? Does the solution we come up with scale?
While we will spend more time brain crunching, designing & coding, we’re really excited we get to work & collaborate with awesome people & technology, in a world where we’re all able to contribute & share ideas, improving & contributing to the open and decentralized XRP ledger. While we still need some time, we are already really excited about engaging with you, devs & businesses, testing, integrating, and hopefully: seeing validators vote for our “Hooks” amendment (to be), at some point in the future.
Top comments (0)