Why We Build on Kaspa

UltraDAO is a research organization first. Most of what we do — building the PULSE hardware, writing firmware, running a study protocol — happens nowhere near a blockchain. But a few things we do are, at bottom, records: who holds the spending token, who owns a given piece of intellectual property, and where the organization's treasury sits. Records like that need a home that no single company administers and no single failure erases.

We chose Kaspa as that home. This post explains what we actually need from a settlement layer, what Kaspa is in plain terms, what UltraDAO runs on it, and why its design fits the shape of our work. It is a description of an engineering decision, not a commentary on any market.

What we need from a chain

Our requirements are unglamorous. We need a place to issue a token — $ULTRA, the spending token of the ecosystem. We need a durable, public record of ownership: IP-NFTs that tie a specific frequency program to a specific owner. And we need a treasury the organization can hold directly — ours is held in KAS, the network's native unit — without depending on a custodian's opinion of what a DAO is.

What we do not need is a venue for financial games. We were not shopping for yield mechanics, leverage, or a derivatives market on our own token, and a chain whose culture is organized around those things would be a poor fit for an organization whose culture is organized around protocols and lab notebooks.

We wanted a ledger, not a casino.

Kaspa, in plain terms

Kaspa is a proof-of-work network: blocks are produced by miners expending real computation, and anyone with hardware and electricity can participate. Where it departs from the classic design is in how blocks are organized. Most proof-of-work chains keep a single file — one block at a time — and when two miners find blocks in parallel, one is discarded. To keep those collisions rare, the network has to slow itself down, which is why confirmation on such chains tends to come in long, deliberate intervals.

Kaspa uses a protocol called GhostDAG. Instead of discarding parallel blocks, it keeps them, weaving them into a directed acyclic graph — a structure in which a block can reference several predecessors — and then computes a consistent ordering over the whole graph. The practical effect is that blocks can be produced in parallel and confirmed quickly, rather than queuing behind one another in a single chain. The network documents itself at kaspa.org; here we will stay at the level of description we actually rely on.

What UltraDAO runs on it

$ULTRA — deployed as a KRC-20 token, Kaspa's token standard. It is the spending token of the ecosystem, described by function on our token page.
The DAO treasury — held in KAS. UXDT, the voting stock certificate in UltraDAO LLC, is bought with KAS, so the treasury sits in the same unit the network itself settles in.
IP-NFT ownership records — the on-chain side of a frequency's ownership, so that the question of who owns a given program is answerable without asking us.

It is worth being equally clear about what does not touch the chain. Buying a frequency on the website today is an ordinary card checkout in dollars. Flashing a frequency to a device is an NFC transfer, signature-checked against UltraDAO-provisioned keys, with no chain involved at the moment of the tap. The chain holds records; the product does the work.

Why fast, cheap confirmation matters

Our unit of work is small. A paid frequency costs ten dollars. An ownership record covers one program and one owner. When the natural transactions of a system are that size, the settlement layer's fees and confirmation delays are not a rounding error — they decide whether small actions can be recorded directly or must be batched into something coarser.

A chain where each write costs meaningful money, or where confirmation is slow enough that a person notices the wait, quietly pushes builders toward custodial shortcuts: keep the real ledger in a private database, settle to the chain occasionally, and ask users to trust the gap in between. Kaspa's design lets small actions be first-class events, so the record-keeping can stay as unceremonious as the NFC tap it accompanies — brief enough not to think about.

A measured word on proof-of-work

Proof-of-work is sometimes discussed as if it were a legacy design. We chose it deliberately, for three properties. It is predictable: the rules for extending the ledger are mechanical, and the cost of rewriting history is physical rather than social. It is permissionless: participation requires hardware and electricity, not an application or an invitation. And it has no validator gatekeeping: there is no committee whose continued approval our records depend on, and no staked class that decides which organizations may transact.

None of that is a criticism of other designs. Different consensus mechanisms make different trade-offs, and many are well matched to what they were built for. For a small research DAO whose main asks are durable ownership records and a treasury that no gatekeeper can freeze by policy, the proof-of-work trade — spend energy, get neutrality — is the right one. Kaspa's contribution is showing that the trade does not have to come with slow confirmation attached.

The choice, plainly

That is the whole argument. We needed a neutral, durable, fast place to keep the records a research DAO generates — a token, a treasury, and a registry of who owns what — and Kaspa is the best fit we found. The tokens themselves are described by function on /token, and how the organization is governed — who votes, who owns — is on /dao. For the network itself, kaspa.org is the right starting point. As with the rest of this project, it is early, and we would rather describe the choice plainly than dress it up.