Subnet sale offer#2745
Conversation
🛡️ AI Review — Skeptic (security review)VERDICT: SAFE BASELINE scrutiny: l0r1s has write permission, an established 2018 account, substantial prior contribution history, no Gittensor allowlist match found, and commit authors match except the benchmark bot commit. Branch subnet-sale-offer -> devnet-ready. No FindingsNo findings. Prior-comment reconciliation
ConclusionI found no malicious indicators or security vulnerabilities in the current diff. The prior sale-offer weight findings remain addressed. 🔍 AI Review — Auditor (domain review)VERDICT: 👍 Gittensor: LIKELY by repo-history heuristic; author has write access and substantial recent subtensor contribution history, so review focused on runtime correctness and permission boundaries. PR body is substantive and matches the implementation. The current diff keeps No duplicate-work recommendation from the cached overlapping PR list. Auto-fix: no workspace changes. I attempted the devnet FindingsNo findings. Prior-comment reconciliation
ConclusionApproving: the previously blocking proxy boundary remains fixed, and the sale-offer state transitions have appropriate guard wiring, weights, and test coverage. No current domain blocker found. |
|
🔄 AI review updated — Skeptic: VULNERABLE |
|
🔄 AI review updated — Skeptic: VULNERABLE |
|
🔄 AI review updated — Skeptic: VULNERABLE |
|
🔄 AI review updated — Skeptic: SAFE Auditor: 👎 |
|
🔄 AI review updated — Skeptic: VULNERABLE |
|
🔄 AI review updated — Skeptic: VULNERABLE |
|
🔄 AI review updated — Skeptic: VULNERABLE |
|
🔄 AI review updated — Skeptic: SAFE Auditor: 👎 |
|
🔄 AI review updated — Skeptic: SAFE Auditor: 👍 |
|
🔄 AI review updated — Skeptic: SAFE Auditor: 👍 |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Summary
This PR adds subnet sale offers to the Subtensor pallet.
The goal is to let a subnet owner announce that a subnet is for sale, optionally
restricted to a specific buyer coldkey. Once an offer exists, a later crowdloan
lease flow can target that offer, pay the seller, and transform the subnet into a
lease atomically.
Creating an offer stores the sale terms by
netuidand freezes the seller coldkeyand current subnet owner hotkey while the offer is active. This prevents the seller
from mutating the relevant accounts during the sale. The seller or root can cancel
the offer, and sale-offer state is also cleaned up if the subnet is removed.
Sale offer identity
Each offer is assigned a unique, monotonically increasing
SaleOfferId. Offers arekeyed by
netuid, so the id lets a consumer (such as the future crowdloan leaseflow) bind to the exact offer it agreed to: if the seller cancels and recreates the
offer with different terms, the recreated offer carries a new id and the stale
binding no longer matches, rather than being silently satisfied by an offer with
modified terms.
Freeze enforcement
A
CheckSubnetSaledispatch extension rejects frozen sale accounts at dispatch time:Because this is a dispatch extension (not a transaction extension), the check fires
at every
call.dispatch(origin)site, including indirectly dispatched calls (e.g.proxy) with the resolved signer, so the freeze cannot be bypassed by wrapping a call
in another dispatch layer.
To keep the freeze consistent,
swap_hotkeyalso refuses to swap a hotkey that iscurrently frozen by a sale offer, which would otherwise move the subnet owner hotkey
out from under the offer (the owner hotkey can be owned by a coldkey other than the
frozen seller, so the coldkey freeze alone does not cover this).
Same-account owner
When the subnet owner coldkey and owner hotkey are the same account, only the coldkey
is frozen. Freezing the same account in the hotkey map as well would block
cancellation (a coldkey action) and permanently lock the seller out of their own
offer.
Other changes
SubnetSaleOffers,SubnetSaleFrozenColdkeys,SubnetSaleFrozenHotkeys, and theNextSubnetSaleOfferIdcounter.create_sale_offerandcancel_sale_offerextrinsics, with the associatedevents and errors.
CheckSubnetSaledispatchextension.
removal, the same-account case, the
swap_hotkeyinteraction, and thedispatch-extension guard (including proxied and nested-proxy dispatch).
Follow-up
The buyer/finalize side is intentionally not included yet. When it lands,
finalization should re-verify that the subnet owner coldkey and hotkey still match
the values snapshotted in the offer (alongside the
SaleOfferId) as a fail-safeagainst any owner-identity drift during the sale.