NIGO as One Asset Among Others: Why Direct Transfers and Program Execution Coexist
A wants to send 20 of their 100 asset units to B. A could send them directly, or authorize someone else to spend on their behalf within a limit. Even if both cases leave A with 80 and B with 20, the ledger must check different grounds for the transfer. In the first case it checks A's ownership; in the second, the spender's permission and remaining allowance.
Does an asset that supports both operations need to run a program for every transfer? And should NIGO, the network's native currency, remain in a separate structure from other assets?
In its September 27 redesign, nigo-protocol chose to treat NIGO as one asset within a common Native Asset model while retaining Direct Cell transfers permitted to the owner. The goal was to unify how assets are identified and how authority and quantity changes are validated. Based on the implementation as of October 19, this post looks back at why the same asset supports both direct transfers and program validation.
What it takes to send 20 units of your own asset
Consider an illustrative asset X. X permits direct transfers by its owner and is currently available for transfer.
The implementation represents these properties as OWNER_DIRECT and ACTIVE, respectively.
Assume A has 100 units of X, B has 0, and the total supply is also 100.
The numbers in this post illustrate the design. NIGO used for fees is accounted for separately from the quantity of X.
A Direct Cell transaction specifies the records to consume and the records to create. A signs a request to consume the cell holding their 100 units of X and create cells holding 80 for A and 20 for B. The ledger checks that the input is valid, that A has authority to spend it, and that the request follows X's current transfer rules. The input of 100 must also match the outputs of 80+20.
X's policy program does not run for this transfer. The ledger's explicit rules already determine whether the transfer is permitted, and this request has no delegated allowance or application-specific business conditions to interpret. On success, A=80, B=20, and supply=100.
The post on preparing Direct Cell transactions explained how requests with explicit outcomes can be constructed and signed outside the ledger. Preserving that structure meant asking whether having a program attached to an asset should require program execution for every transfer.
Reconsidering the move toward programs
An intermediate implementation restricted Direct transfers for all user-issued assets while moving business rules into Native Programs. The intent was to put each asset's approval conditions in its policy program instead of adding asset-specific branches to the execution engine. Ordinary NIGO transfers remained on a separate path.
This choice made the program's responsibility for asset rules clear. But it left two questions. Should an owner's transfer with no additional business conditions need to run policy code every time? And why should NIGO balances and delegated spending be managed in a different framework from other assets?
For example, even if X supports allowances, A does not use an allowance when sending their own asset. An asset having an associated program and a particular effect requiring that program's approval are separate facts.
The redesign therefore put assets in a common model and applied the appropriate authorization to each effect. An owner's direct transfer is checked against explicit transfer rules, while delegated spending and supply changes go through the relevant policy validation. The execution engine does not inspect policy code and automatically identify transfers that “look simple.”
Sending the same 20 can require different authorization
Now start from the same initial balances and suppose A has authorized spender S to use up to 30 units of X. S is an address different from A, and the policy identifies S as the actual caller. A has not given the policy program itself an allowance of 30.
Immediately after the approval is finalized, the balances are still A=100 and B=0. The allowance of 30 is not a balance moved elsewhere; it is the limit on how much of A's asset S may spend. When S subsequently sends 20 units of X to B, the policy checks S's identity and remaining allowance. The asset transfer and allowance reduction must be approved together to produce A=80, B=20, and remaining allowance=10.
The three scenarios below are not successive transactions. Each is a separate case starting from A=100 and B=0. For delegated spending, assume the approval shown in the table has already been finalized before the spending request.
| Scenario | Required grounds | State of X after the transaction |
|---|---|---|
| A directly sends 20 | Ownership, current Direct permission, and quantity conservation | A80, B20, supply100 |
| S spends 20 with an allowance of 30 | S's authority and allowance, checked by the policy | A80, B20, allowance10, supply100 |
| S requests 20 with an allowance of 10 | The policy rejects the request for insufficient allowance | A100, B0, allowance10, supply100 |
In the last case, the previously finalized allowance of 10 remains intact. A failed policy check does not let S use A's owner-transfer path instead. Direct does not grant S authority to take A's asset.
The current standard policy combines features such as delegated spending and issuance through several modules. The central distinction remains the same even if the details of that implementation change: the ledger's common checks are separated from the business conditions that the policy must interpret.
Why NIGO belongs in the same model
If NIGO remains in a separate structure, even the way to find “who holds how much of which asset” diverges within the same ledger. Where delegated authority is recorded, what authorizes a balance change, and how that change is explained all need separate treatment. Adding a few programs that can use NIGO would not remove this duplication.
In the current model, NIGO has a common asset identifier, control information, balance cells, and an associated asset policy. It can be discovered through the same asset listing mechanisms, and balance changes are checked together with their effects and authorization. Records of delegated NIGO spending are also treated as policy state for the NIGO asset.
NIGO still retains the fixed identifier established in the chain's initial state and its role as the native currency. Ordinary owner transfers follow the common Direct rules. Fee settlement and EVM currency transfers follow protocol authorization authenticated for their execution context.
The diagram shows how different grounds for authorization feed into common validation. It does not mean every asset has all three kinds of authority. Bringing NIGO into the common model does not let ordinary policies mint or burn NIGO at will. Delegated NIGO spending is currently supported through the Native path; this should not be read as opening it to the EVM as well.
Unlike the earlier X example, when NIGO itself is transferred and a fee applies, the amount sent and the actual fee must be accounted for together in the same NIGO balance calculation. The common model provides a foundation for validating these changes while keeping currency roles distinct from each policy's authority.
Direct also checks the asset's current rules
An owner's signature does not always permit a Direct transfer.
For example, a separate asset Y may use POLICY_REQUIRED, requiring policy validation for every transfer.
Even if A owns 100 units of Y and signs the request, a Direct transfer of 20 is rejected.
Y's balances remain A=100 and B=0; a transfer must satisfy the conditions required by Y's policy.
Even for X, which permits Direct transfers, the asset control information and policy binding referenced by the transaction must match the current values. If the relevant information changes after the transaction is prepared, the old conditions cannot be used to finalize it. Missing information or information that cannot be interpreted also prevents the transfer.
Conversely, if explicit Direct permission and valid asset information remain in place, validating the owner's transfer does not require running the policy program or checking whether it can execute. This distinction lets policy execution and basic owner transfers depend on different conditions. The current implementation includes regression checks for these transfers of NIGO and user-issued assets, as well as rejection of stale references and invalid control information.
When a common asset meets different execution models
The three transaction execution models examined the difference between directly submitting proposed changes, validating them with a program, and executing EVM code. This redesign reorganized the assets underneath those models. On the common asset model, including NIGO, owner transfers, delegated spending, and currency effects each require their appropriate authorization.
The next scenario is A granting spending permission through a Native transaction, then an EVM application contract using that permission to spend the same asset. For a single ledger to be meaningful, balances and approvals must remain usable across execution models. And if that application operation fails partway through, how much of the asset transfer and allowance change should roll back together?