BWG Loonshots

A holds 100 units of an asset and has authorized S to spend up to 30 of them. S wants to use that permission to send 20 to B. After the transaction, A should have 80, B should have 20, and S's remaining allowance should be 10.

In nigo-protocol's Native Program path, the party constructing the transaction prepares these proposed changes first. The program checks whether the proposal satisfies the spending conditions. Preparing Direct Cell transactions examined how explicit inputs and outputs can be assembled and signed outside the ledger. Here, we add a spending approval condition to that way of constructing proposals and look inside Native Program validation.

Is it enough for the program to reply, “Allowed”? If the answer does not identify which of A's asset inputs may be used, or which approval record may be changed into what, the ledger cannot establish which inputs and state changes that authorization covers. This post asks how to connect a decision that spending conditions are satisfied to the records that actually change.

A wants to send B 20 out of an asset holding of 100. B plans to send 5 of that to C. A also plans to send D 10 out of the remaining 80.

Must they wait for each preceding transaction to enter a block before preparing the next one? And must the people constructing a transaction, signing it, and checking its contents all work in the same place?

In nigo-protocol, Direct Cell transactions explicitly carry the records to consume and the records to create. One Ledger, Three Ways to Execute Transactions compared this request with Native Program and EVM requests. Here, we explore how an explicit Direct Cell proposal can separate the places and roles involved in preparing a transaction.

Understanding that possibility requires keeping two facts in view: being able to specify a proposed result in advance is different from having that proposal finalized on the ledger.

A wants to send 20 of their 100 asset units to B. After the transaction, A will have 80 and B will have 20. The goal is simple, but the request sent to the ledger depends on the execution model.

The request could specify the intended result: “Consume this record and create records for A's 80 and B's 20.” Or it could say, “Execute this contract's transfer function,” leaving the code to compute the result. If someone else spends A's asset on A's behalf, there must also be a way to check that permission and its conditions.

nigo-protocol addresses these differences through three execution models: Direct Cell, Native Program, and EVM. This post follows one transfer example to examine what each request contains, who constructs the next state, and how the results are applied to the same ledger.

You ask a ledger, “Did this asset exist then?” The answer comes back: the record cannot be found. Does that mean it really did not exist at that point? Or does the node answering the question lack the data from that time?

The distinction is easy to overlook when checking a current balance. But it matters when establishing past ownership or auditing a transaction's outcome. If we interpret unavailable data as evidence of absence, the facts of the ledger depend on the storage circumstances of whichever node we ask.

The StateCell ownership article explored how ownership relates to permission to change state, and why a ledger records the path of those changes. This article turns to preserving and verifying that history. Once time has passed, can we still establish what the ledger contained then?

A has authorized S to spend up to 30 units of A's asset. S wants to send 20 of those units to B. S signs this transaction. But the asset being spent belongs to A.

If the ledger only checks whether the asset's owner signed the transaction, it cannot process this request. It cannot simply accept S's claim to be spending A's asset, either. It must also consider what A approved and whether S's request falls within that approval.

Whose state is it, and who can change it under what conditions? Introducing ownership into StateCell meant addressing both questions together.

A StateCell is a small unit of recorded state in the ledger. Part 1 explained why assets and smart contract state share this common unit. Part 2 explored how to describe the structure of the values it holds. This post follows the spending approval example to explain ownership, permission to change state, and the roles of programs and the ledger.

Suppose we store an address and the number 30 as a sequence of bytes. The reader needs to know where the address ends and the integer begins. If more fields are added, or the same record is repeated in an array, we also need an agreed way to interpret that combination.

In Part 1, I explained why nigo-protocol represents asset outputs and smart contract state in a common unit called StateCell. Once that unit was defined, the next question was how to describe the structure of the values it would contain. It needed to accommodate structs, arrays, and mappings as well as individual integers.

nigo-protocol separates a value from its structure and identifies that structure with a schema hash. This post starts with a small spending-limit record and explains how primitive types combine into composite structures, and how those structures connect to state stored in cells.

Calculating rights based on how long someone has held a token requires more than a current balance. It also requires a record of the past. In the review of the time-weighted ownership contract, I explored a design that recorded the block number and resulting balance whenever a balance changed. Deploying a smart contract on an existing blockchain was enough to experiment with revenue distributions that accounted for holding periods.

But what if several assets need the same kind of record? Each asset needs a way to preserve its history, define how to query it, and read those records again. If the ledger understood asset ownership and state changes through a common structure, how much of that work could it support directly?

That question was one of the reasons I began designing nigo-protocol as its own blockchain. Building a ledger meant making an early choice: what should count as a unit of stored state, and how should a change to that state be expressed?

This first post in the StateCell series explains the starting point for that choice. It is about bringing the explicit state transitions of UTXO and the development experience made possible by smart contracts onto the same ledger.

You send a transaction, but no RPC response arrives. If another node is available, can you simply switch the connection to it?

The other node can handle the next request. But switching nodes does not erase the transaction you already sent. Changing the connection target and checking the transaction's execution result concern different kinds of state.

In transfer request timeouts and retries, we examined what happens when the same business operation runs again. This time, we move down to the connection layer. Let's compare how BXB selects nodes, rechecks nodes marked as unhealthy, and retries a query through another node in its mirror module.

A server needs to sign a transaction with a private key to send a customer's tokens. If that key stays inside an HSM and the server does not read its value, who builds the transaction, and how does the server obtain the signature?

An HSM, or Hardware Security Module, is a device that protects cryptographic keys and performs cryptographic operations. In a blockchain integration, it signs with a key held inside the device and returns the result. The server still has to construct the transaction, convert the signature into the chain's required format, and check the submission result.

Connecting customer accounts to blockchain signatures examined how customer identifiers, wallets, and key selection fit together. This article follows BXB's HSM integration from selecting a key to producing the actual transaction.

You register a new Solana token. Balance queries work, and the response says A holds 100 tokens. But when you try to send 10 from A to B, there is no transfer API. If the balance can be read, should the token not be transferable too?

Reading a token and building a transaction that follows its rules require different information. Token-2022 makes this distinction particularly clear. Even tokens using the same program can have different transfer conditions because of their extensions.

What to unify and what to keep distinct in a multichain API examined the conditions that must remain specific to each chain. Here, we narrow the scope to Solana and follow how BXB decides which commands to expose for each token. The discussion covers queries and standard write commands in the token proxy. It does not describe the support boundaries of every resource management API.