The Sashimono Daemon

  • HotPocket is a UNL consensus engine that converts Linux machines into mini-blockchains.
  • Coordinating the roll out of HotPocket dApp currently requires manual set up and is inherently centralising.
  • Sashimono is a daemon that enables the decentralised deployment and management of HotPocket clusters “in the wild” from any layer 1 infrastructure.

Today we are publishing our (short) white paper on the Sashimono daemon.

Sashimono makes it easier to launch decentralised HotPocket nodes.

In its current configuration, coordinating the rollout of a Hot Pocket smart contract currently requires manual server setup and configuration for every HotPocket node in the contract. Instead, it is desirable to dedicate a selection of servers for the collective purpose of running logical nodes from different HotPocket contracts from time to time, and then coordinate these from a unified and decentralised command point, or message board.


Sashimono would be configured so that any “layer 1” blockchain could be the message board. That is, all nodes would be listening to a single point of truth that could be any (decentralised) layer 1 blockchain. Sashimono is summarised diagrammatically in Figure 1.

Figure 1 -Sashimono


Without Sashimono, HotPocket is an inherently centralised smart contract solution. Generally, a single actor would be required to spin-up and configure the relevant nodes in a HotPocket cluster.

Sashimono overcomes this problem by making it as easy as possible to coordinate a HotPocket cluster through any layer 1 blockchain that supports smart-contracts. All that is needed is infrastructure that can function as a message board. It does not matter that the message board is public because all the messages will be encrypted.

In effect, Sashimono is a way of “nailing” a HotPocket cluster to a layer 1 public blockchain, providing a bolt-on smart contract functionality.

Next Steps – An XRPL Native Proof of Concept

Coding of Sashimono has begun. In its first test implementation, Sashimono would listen to a multi-sig XRPL Account as the message board and then an XRPL Hook when Hooks are on the public TestNet. The first proof of concept should be iXRPL Self-KYC running on a network of HotPocket Nodes using a multi-sig XRPL Account as the daemon’s message board.

Leave a Reply