Commit Graph

3 Commits

Author SHA1 Message Date
pezkuwichain 80fb0544ed fix(pezkuwi): finish the Asset Hub cleanup and guard it against coming back (#69)
* fix(pezkuwi): finish the Asset Hub cleanup and guard it against coming back

Three things left half-done, and a check so they stay done.

## Assets that were never created on chain

chains.json and v22/android/chains_minimal.json still declared Pezkuwi Asset Hub
assetIds 1001, 1002 and 1003 as DOT, ETH and BTC. Queried against
wss://asset-hub-rpc.pezkuwichain.io on 2026-08-11, assets.asset() returns None for all
three; only 1 (PEZ) and 1000 (wUSDT) are Live. They were added from a template — the
icons pointed at Nova's own repo — and shown to users, where any transfer would fail.

This is the second removal. The first, on branch fix/remove-nonexistent-asset-hub-assets
(2026-07-09), cleaned 66 files across v10-v22 but never touched these two, and was never
opened as a PR. A third branch, feature/asset-level-balance-test-fixture, went the other
way and added all three to a regression fixture. Both branches sat for a month.

## Assets served from a working branch

252 references under chains/ fetched icons from pending/post-fix-release. Every file
they named is byte-identical on master, main and that branch, so the dependency bought
nothing — and would have broken silently the day the branch was tidied away, which
nearly happened during this cleanup. Repointed to master, the branch the apps read.

## A fixture nothing keeps in step

sync_from_nova.py publishes chains, xcm, icons and config from the overlay, but never
tests/. So tests/pezkuwi_assets_for_testBalance.json and its overlay source are kept
aligned by hand. They agree today; nothing would have said so if they stopped.

Rather than invent a publish step whose conventions I would be guessing at, the drift
is now asserted.

## The check

scripts/check_pezkuwi_integrity.py, wired into the Code Quality job. Four assertions,
one per regression above, each carrying why it exists. Two of the four have already
recurred once, and the Nova sync will keep proposing the first one back — the current
sync branch (f6c3ebb9) reverts the isSufficient declaration, which is why the second
assertion exists.

Mutation-tested: restoring a ghost asset, removing isSufficient, repointing one icon at
a working branch, and nudging the fixture each fail it; reverting each passes.

* fix(overlay): declare sufficiency at the source, not in the generated output

The isSufficient declaration was added to chains/ — which sync_from_nova.py regenerates
from nova-base plus pezkuwi-overlay on every run. So the fix had a shelf life of exactly
one sync, and the sync branch already waiting (sync/nova-base-f6c3ebb9, 2026-08-08)
reverts it: its output carries {"assetId": "1000"} with no sufficiency, because it was
generated from an overlay that does not declare any.

Editing generated files is how this repo keeps losing the same change. The phantom
Asset Hub assets were removed twice and came back twice for the same reason.

Verified rather than assumed: added the field to
pezkuwi-overlay/chains/pezkuwi-chains.json, ran scripts/sync_from_nova.py, and all three
generated files — chains.json, v22/android/chains.json, v22/android/chains_minimal.json
— came out carrying isSufficient: true. git reported no change to any of them, meaning
the sync now produces exactly what the manual edit produced, so the two agree instead of
fighting.

The phantom assets do not return either: the overlay lists only HEZ, PEZ and USDT, so
regeneration drops 1001/1002/1003 by construction rather than by anybody remembering.
2026-08-11 05:20:49 -07:00
pezkuwichain 28adea22bc fix(pezkuwi-asset-hub): declare PEZ and USDT as sufficient, matching Polkadot AH (#66)
* fix(pezkuwi-asset-hub): declare PEZ and USDT as sufficient assets

The wallet refused USDT.p transfers to any account holding no HEZ:

    Your transfer will fail since the destination account does not have
    enough HEZ to accept other token transfers

It is a false positive, and the chain disagrees with this config.

DeadRecipientValidation skips the whole check when the destination asset is
self-sufficient:

    skipIf = { assetSourceRegistry.isAssetSelfSufficient(destinationChainAsset) }

and StatemineAssetBalance reads that flag from HERE, not from the chain:

    chainAsset.requireStatemine().isSufficient   →  runCatching { … }.getOrDefault(false)

`isSufficient` was absent from typeExtras in every version of this config, so it
resolved to false, the validation ran, and every transfer to a fresh account was
warned against.

Measured on chain (asset-hub-rpc.pezkuwichain.io):

    asset 1    PEZ    sufficient=true   minBalance=1        18 accounts
    asset 1000 wUSDT  sufficient=true   minBalance=10000    21 accounts

Both are sufficient, so neither needs the recipient to hold native balance.

Proof it works in practice rather than only in theory: account
5E2yqgUVVNjU… holds 1750.00 USDT with free=0, providers=0, sufficients=1 and
nonce=0. Zero native balance, no provider reference, and it has never signed a
transaction — so it was brought into existence by the incoming USDT transfer
itself, which is exactly what the wallet was saying could not happen.

Applied to v22 (the version the app fetches, runtime/build.gradle CHAINS_URL) and
to the top-level chains.json.

Noted, not changed here: this config also declares assets 1001/1002/1003 on
Pezkuwi Asset Hub as DOT, ETH and BTC. None of the three exists on chain —
assets.asset() returns None for all of them. They are shown to users and any
transfer would fail.

* Revert "fix(pezkuwi-asset-hub): declare PEZ and USDT as sufficient assets"

This reverts commit af1a8a5468.

* fix(pezkuwi-asset-hub): declare PEZ and USDT as sufficient, matching Polkadot AH

Pezkuwi Asset Hub's two statemine assets carried only `assetId` in typeExtras. The
equivalent entries on Polkadot Asset Hub — USDT (1984) and USDC (1337) — carry
`isSufficient: true`. Same kind of asset, same file, two different declarations.

The omission is not inert. `LocalToDomainChainMapper` reads

    typeExtras["isSufficient"] as Boolean? ?: STATEMINE_IS_SUFFICIENT_DEFAULT   // false

so an absent field resolves to false, `StatemineAssetBalance.isSelfSufficient` returns
false, `DeadRecipientValidation`'s skipIf does not fire, and the validation runs — at
`validOrError`, which is DefaultFailureLevel.ERROR, so the transfer is blocked rather
than warned about.

The chain says otherwise. Measured on asset-hub-rpc.pezkuwichain.io, 2026-08-10:

    asset 1    PEZ    sufficient=true   minBalance=1        18 accounts
    asset 1000 wUSDT  sufficient=true   minBalance=10000    21 accounts

Neither needs the recipient to hold native HEZ, and one account demonstrates it:
5E2yqgUVVNjU… holds 1750.00 USDT with free=0, providers=0, sufficients=1 and nonce=0 —
no native balance, no provider reference, never signed a transaction. It exists because
the incoming USDT transfer created it, which is exactly what the wallet was reporting
could not happen.

43 of the 67 statemine assets in this config declare the field. The 24 that omit it are
genuinely non-sufficient on chain — the Polkadot AH meme tokens. Pezkuwi Asset Hub was
the only case where the declaration disagreed with the chain.

Applied to v22 (the version runtime/build.gradle CHAINS_URL fetches) and the top-level
chains.json, in the same shape as the Polkadot entries.
2026-08-11 02:24:36 -07:00
pezkuwichain de6a7c0492 Filter broken chains (DNS failures) from Nova config 2026-02-11 09:30:52 +03:00