# Pillar Ownership Transfer via HTLC

**URL:** <http://forum.zenon.org/t/pillar-ownership-transfer-via-htlc/2370>\
**Category:** ╰  Funding  |  Submissions\
**Created:** [September 13, 2026, 11:54pm UTC](http://forum.zenon.org/t/pillar-ownership-transfer-via-htlc/2370 "2026-09-13T23:54:09Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![sol](http://forum.zenon.org/user_avatar/forum.zenon.org/sol/32/1636_2.png) [@sol](http://forum.zenon.org/u/sol)\
**Post date:** [September 13, 2026, 11:54pm UTC](http://forum.zenon.org/t/pillar-ownership-transfer-via-htlc/2370/1 "2026-09-13T23:54:09Z")

</div>

**Project Name:** Pillar Ownership Transfer via HTLC

**Description:**  **There is no way to transfer a Pillar today.** `PillarInfo.StakeAddress` is written once at registration and never changes, and the only exit is `Revoke`, which destroys the name permanently. As a result:

- Operators who want to liquidate must destroy the asset instead of passing it on. The name and delegation base are lost.
- The network loses Pillars it would otherwise keep, and each re-registration costs `150,000 + 10,000 × N` QSR.
- Off-chain handovers mean sharing keys, which transfers control but not ownership and leaves the buyer with no recourse.

This project specifies and implements the **smallest consensus change that makes a Pillar tradeable trustlessly:**

| Change | Caller | Effect |
| --- | --- | --- |
| `LockOwnership(name, buyer, duration, hashType, hashLock)` (new) | Current owner | An irrevocable, time-limited commitment: _the named buyer may take this Pillar by revealing the preimage before this height_ |
| `TakeOwnership(name, preimage)` (new) | Named buyer | Reveals the preimage and takes ownership |
| `Revoke` (modified) | Current owner | Fails while a lock is live, so a seller can’t revoke out from under a buyer |

The Pillar contract **never handles value**. Payment happens on the other leg of an atomic swap: on Bitcoin, or on NoM through the **existing** `embedded.htlc` contract, which already accepts any ZTS.

**Why it matters for Zenon:** it keeps Pillars, and their delegators, in the network when operators change, and it replaces key-sharing handovers with a trustless one.

**URL:** The ZIP will be published at [https://zenon.zip](https://zenon.zip) on submission. The on-chain project will link to this forum thread.

**Team:**

- **sol:** specification, adversarial review, implementation, testing. Also built Ferry, which already runs both legs of BTC⇄Zenon HTLC swaps.

* * *

**Phases**

**Phase 1: ZIP submitted and accepted**

High-level overview of main tasks:

- ✅ **Draft specification** (Standards Track, Consensus, BSD-3-Clause) written against `go-zenon` at `590f43c`, with every cited symbol re-checked against the source:
  - `ValidateSendBlock` and `ReceiveBlock` rules for each method
  - The state-record encoding, measured at 288 / 320 bytes and round-trip byte-identical
  - Constants and their one-way upgrade classes, errors, RPC, and spork gating

- ✅ **Four design iterations, each with a written adversarial review:** an escrowed bid/ask market, ask-only v1 and v2, and the HTLC-only primitive specified here. Every rejected alternative is recorded in the ZIP’s Rationale with the reason.
- ✅ **Consensus hazards found and closed in the draft:**
  - The spork diff must mutate the Pillar contract in place, or it discards the Accelerator spork’s `CollectReward` plasma override and halts nodes syncing from genesis.
  - The ABI re-pack must be the identity, or blocks fail on mainnet with `ErrABHashInvalid` while CI passes.
  - Lock checks must fail closed on storage errors.

- ✅ **The swap protocols specified normatively** (BTC for a Pillar, ZNN for a Pillar), including the required leg ordering: the owner generates the secret and locks first, with the longer timelock. Reversed, a failed take publishes the preimage and one party loses everything.
- Submit the ZIP under the [ZIP-0001](https://zenon.zip/1) process as a NIP-34 proposal against the canonical repository
- Answer public review from core developers and revise

Completion of Phase 1 will be measured by:

- The ZIP accepted by the ZIP maintainers into the canonical repository

**Phase 2: Implementation**

High-level overview of main tasks:

- **go-zenon:** `LockOwnership`, `TakeOwnership`, the `Revoke` guard, the `pillarOwnershipLock` state record, constants, errors and RPC, all gated behind `PillarOwnershipSpork` with a **placeholder id** , so the release does nothing on its own
- **Tests:** full per-method coverage plus the ZIP’s three required test classes:
  - a re-pack identity test at harness level
  - a plasma test across all 32 spork variants
  - a reward-attribution test

- **Devnet:** pre-activation through genesis, the full suite, and end-to-end swap smoke tests on both legs (BTC for a Pillar, and ZNN for a Pillar through `embedded.htlc`)
- **`znn_sdk_dart` bindings and the swap helper,** which owns secret generation, refuses the reversed ordering, and refuses to fund when the timelock margin is thin. The ZIP requires both before activation.
- **`znn_cli_dart` lock and take commands,** showing heights as approximate times, with the take-time warnings (revoke phase, `RewardWithdrawAddress`, give-percentages)

Completion of Phase 2 will be measured by:

- Pull requests opened against `zenon-network/go-zenon`, `znn_sdk_dart` and `znn_cli_dart`, with CI green
- Both swap flows settled end to end on a devnet with the spork pre-activated
- The swap helper refusing the reversed ordering and a thin margin, both demonstrated in tests

* * *

**Funding**

**Total Requested Funding** = 5,000 ZNN and 50,000 QSR  
**Project Duration** = 2 month

**How did you calculate your budget?**

- **Phase 1** covers specification work already done: four design iterations and four written adversarial reviews against the go-zenon source, plus the submission and review cycle still to come.
- **Phase 2** is a consensus change with a spork diff, a new state record, a modified method, three required test classes, devnet integration, and SDK and CLI tooling. It is comparable in scope to _Combined SDK and znn-cli updates_ (5,000 ZNN + 50,000 QSR, about 200 h), plus the consensus work.

**Project and Payment Milestones:**

**Phase 1**  
Funding Request: 40% (2,000 ZNN and 20,000 QSR)  
Duration: 1 month

**Phase 2**  
Funding Request: 60% (3,000 ZNN and 30,000 QSR)  
Duration: 1 month

* * *

**Other Information**

**Risks, Assumptions, Known Issues, Dependencies:**

- **Activation depends on a mechanism this project doesn’t control.** Like every consensus change, this one goes live through a spork, and **sporks are currently frozen**. The community spork key’s window closed on 2026-04-16, and the genesis key’s whereabouts are unknown. The network’s upgrade path is being worked out through the draft governance ZIP.
  - Phase 2 is defined so it can be delivered and verified without activation: merged code behind a placeholder spork, tested on devnet, with SDK and CLI tooling ready.
  - Mainnet activation happens whenever a working mechanism exists (a new spork key, the governance contract, or a coordinated hard fork).
  - **If Pillars would rather wait for that path before funding implementation, Phase 2 can be held while Phase 1 proceeds.** Say so in this thread.

- **Acceptance risk.** The ZIP maintainers may ask for changes, or decline. Phase 1 is paid only on acceptance.
- **Stated, not mitigated, in the ZIP:**
  - **Rewards go to the seller until the buyer calls `UpdatePillar`.** The seller’s `RewardWithdrawAddress` keeps collecting, and both simple fixes misattribute rewards in opposite directions. Clients must show it to the buyer at take time.
  - **Undecided Accelerator-Z votes transfer with the Pillar.**
  - **A mis-posted lock freezes a Pillar for up to 48 hours.**
  - **A reused hashlock** is the one mistake that loses the asset, which is why the SDK owns secret generation.

- **Open items the ZIP lists for before activation:** run the four-transaction same-chain flow end to end (covered by Phase 2), and check the non-Dart SDKs.

**Have you previously submitted a proposal (either in Accelerator-Z or Incubator)?**

- [SYRIUS v0.0.6 Improvements](https://zenonhub.io/accelerator-z/project/ada02c3217c8270e891e0d5cbfe8a3726cccd9a5af449527caf77b9eb85df550)

- [P2P Swaps in Syrius](https://zenonhub.io/accelerator-z/project/047a15a6228a18117ed924ce9bb973e2ef6d5b9576977865433e97af9526e2a9)

- In progress (submitted alongside this one)

**Follow-up work (not requested here):**

- Syrius and Syrius-extension lock and take screens
- Indexer and explorer support (`nom-indexer`, zenon.tools, zenonhub)
- A BTC-for-Pillar flow in Ferry
- The ZIP’s future work: an on-chain provenance record and a standing-offer layer, which would need a second spork

**On-chain filing.** One project with two phases, whose sum equals the project total exactly (the chain maximum per project):

| Project name | Project funds | Phases |
| --- | --- | --- |
| `Pillar Ownership via HTLC` | 5,000 ZNN / 50,000 QSR | Phase 1: 2,000 / 20,000  
Phase 2: 3,000 / 30,000 |

---

<div class="post-metadata">

**Author:** ![edgepillar](http://forum.zenon.org/user_avatar/forum.zenon.org/edgepillar/32/3026_2.png) [@edgepillar](http://forum.zenon.org/u/edgepillar)\
**Post date:** [September 15, 2026, 3:01pm UTC](http://forum.zenon.org/t/pillar-ownership-transfer-via-htlc/2370/2 "2026-09-15T15:01:53Z")

</div>

**Strong support.**

This feels like exactly the kind of narrowly scoped protocol improvement that makes sense for NoM. It solves a real problem without trying to embed an entire marketplace into consensus.

Being able to transfer a Pillar without destroying the name, losing the delegation base or handing somebody the original private key is a meaningful improvement for the network.

I also like that the Pillar contract only handles the ownership transition while payment remains on the other HTLC leg. Keeping those responsibilities separate makes the primitive much easier to reason about.

The main thing I would still like to see defined very clearly is what happens to governance state during a transfer. An unresolved Accelerator-Z vote shouldn’t accidentally become the buyer’s political intent. If clearing pending votes on `TakeOwnership` is practical, I think that deserves consideration.

The `RewardWithdrawAddress` behavior also needs to be very visible to the buyer. Even if changing it automatically would create accounting problems, the wallet/CLI should make it impossible to complete a purchase without understanding where rewards will continue going until `UpdatePillar` is called.

I also strongly agree with putting secret generation, hashlock safety and timelock ordering into SDK helpers rather than relying on users to get them right manually.

The frozen spork situation shouldn’t prevent the work from being funded. Having the spec, implementation and tooling reviewed and ready means the feature can be activated when Zenon’s upgrade path is solved.