* Add pezkuwi-light: embedded PezkuwiChain light client binding
A JNI binding around the PezkuwiChain fork of smoldot (pezkuwichain/smoldot),
which verifies PezkuwiChain blocks under the chain's sovereign constants.
Upstream smoldot cannot.
The wallet reaches its chains through JSON-RPC WebSockets, so the light
client is served the same way: a WebSocket server bound to 127.0.0.1 on a
random port. Every path carries a random per-process token:
ws://127.0.0.1:<port>/<token>/<chain key>.
- A wrong token, a missing token or an unregistered chain is refused during
the handshake with 404.
- Each connection adds its own smoldot chain instance. smoldot shares the
sync between instances of the same chain.
- Each registered chain's finalized state is written to disk every minute,
through a temporary file and a rename. The next start resumes from it.
Kotlin surface: PezkuwiLight.start(dir), addChain(key, spec, relayKey),
chainUrl(base, key). The module is not yet a dependency of the app.
Tested against the live Zagros testnet, with the relay chain and People
specs:
- dks.kurd resolves through NavnisanApi_resolve to the same bytes the full
node returns.
- An unregistered name returns 0x00.
- The saved state lets a new client resolve.
- Reverting the token check turns the routing test red.
The library builds for arm, arm64, x86 and x86_64 with 16 KB aligned LOAD
segments (0x4000).
* pezkuwi-light: secure WebSockets and the app's resolver for peers
smoldot's DefaultPlatform cannot open wss connections and resolves names
through the system resolver. Where our domains are blocked, both fail: a
poisoned DNS answer decides where the client connects, and plain libp2p
TCP is recognisable on the wire.
PezkuwiPlatform replaces it:
- Opens /dns/<host>/tcp/<port>/wss over TLS, using rustls with the ring
provider and the Mozilla roots, so a connection looks like any HTTPS
WebSocket.
- Resolves every name through a Resolve trait. On Android this is the
app's HostResolver, called over JNI, so the light client follows the
same DNS policy as the rest of the app (EncryptedFirstDns: DoH first,
system resolver last).
- Tries IPv4 before IPv6, and gives up on an address after 10 s.
- With setSecureOnly(true) it opens nothing but secure WebSockets. Peers
found through the DHT advertise plain TCP too, and none of them is used.
The peer's identity is still checked end to end by libp2p Noise.
Tested against live Zagros with only the /wss boot nodes in the specs and
secure-only on: relay and People sync and dks.kurd resolves to the full
node's bytes. Nail: with secure-only on and the specs' plain TCP boot
nodes, nothing syncs and the test times out red.
* pezkuwi-light: measure a start from the saved database in its own process
An app launch resumes from the database in a fresh process. The in-process
warm measurement ran beside a client that was still syncing, so it did not
show that case.
The new ignored test resolves dks.kurd after a start from the database in
PEZKUWI_LIGHT_DB_DIR. On the first run, when no database exists yet, it
syncs and waits for a save.
The tests also log through env_logger, so RUST_LOG shows smoldot's own
timeline when a measurement needs explaining.
* Fall back to the embedded light client when every Zagros RPC node fails
ChainConnection stays on RPC first. A light client loads the peer-to-peer
nodes, and those nodes have a fixed number of light client slots, so RPC
is the default.
When every RPC node of a supported chain has failed in a row, the
connection moves to the light client, served at
ws://127.0.0.1:<port>/<token>/<genesis>. RPC is retried after one minute.
The wait doubles up to 15 minutes while RPC keeps failing. The connection
returns to RPC as soon as a retry connects. If the light client cannot
start, or its own connection fails, the connection stays on RPC.
LightFallbackPolicy holds these rules. Its tests cover each one, and five
mutations of the policy each turn a test red. ChainConnection handles RPC
node changes, socket states and a 15 s tick as one event stream, one event
at a time, so a node change and a fallback cannot race.
LightClients starts the client on first use. A wallet whose RPC answers
never runs it. LightClients registers Zagros and Zagros People, the
chains the fork can verify, from specifications bundled at build time
from pezkuwi-wallet-utils light-client/: the genesis state root, the /wss
boot nodes on 443 first, and the relay checkpoint. Peer names resolve
through EncryptedFirstDns, which CommonApi now exposes to the runtime
module.
* pezkuwi-light: strip in the cargo profile
The Android Gradle plugin packages a native library it cannot strip as it
is. With debug info, libpezkuwi_light.so is 147 MB per ABI. Stripped it is
8.6 MB.
The first CI build of this library ran out of disk: four targets with
debug info filled the runner. Stripping in the release profile, with debug
info off, fixes both:
- The library is 8.6 MB for arm64 and keeps its three JNI symbols.
- The build directory is 389 MB per target.
* Log the light client fallback's decisions
Each RPC failure the fallback sees, the light client URL it got, and each
RPC retry are logged under LightFallback. The first device run on a
blocked Zagros RPC showed no fallback and no trace of where it stopped.
* feat(network): fetch config from jsDelivr when raw.githubusercontent.com fails
Every config file the app reads -- chains, assets, DApps, XCM, banners, token
icons -- comes from raw.githubusercontent.com with no other source, so when that
host cannot be reached a fresh install has no chains at all.
ConfigMirrorInterceptor retries the same file on cdn.jsdelivr.net and then
fastly.jsdelivr.net when the primary fails to connect or answers 403, 429, 451
or 5xx. A 404 is an answer and is returned as is. A host that failed is skipped
for ten minutes so later requests do not each wait for its timeout. Mirror
requests revalidate, so a mirror's long max-age cannot pin a copy in the HTTP
cache after the primary is back.
The shared OkHttp client and Coil's image client both carry it.
* feat(runtime): start a first install from the chain list the APK was built with
A first install has no chains until chains.json is fetched, and the fetch
retries forever: with GitHub and its mirrors unreachable the wallet stays
empty.
The runtime module now bundles the live chains.json at build time
(bundleChainsConfig, run before preBuild, falling back to jsDelivr and
refusing anything that is not a non-empty JSON array). When the local
database is empty, ChainSyncService tries the network once and, if that
fails, applies the bundled list so the wallet opens; the fetched list then
replaces it through the usual diff as soon as it arrives.
* feat(dapps): show the bundled DApps catalog until one can be fetched
The DApps catalog lived only in memory and every read waited on first(), so
with the catalog URL unreachable the DApps screen waited forever.
feature-dapp-impl now bundles dapps_full.json at build time. On the first
sync the repository tries the network once and, if that fails, publishes the
bundled catalog so every read returns; the fetched catalog replaces it as
soon as it arrives.
The download task moves to scripts/bundled-config.gradle and serves both
the chain list and the DApps catalog. runtime and feature-dapp-impl unit
tests return defaults for android.util.Log, which the fallback calls.
* feat(network): resolve names over DNS-over-HTTPS first, system DNS as fallback
A network that answers plain DNS with a wrong address decides where the app
connects. The shared OkHttp client and Coil's client now resolve through
EncryptedFirstDns: Google, Cloudflare and Quad9 over HTTPS, each reached by
IP, then the system resolver if all of them fail, so no network is worse off.
- A resolver whose request failed is skipped for ten minutes, so a network
that blocks DoH pays the four-second timeout once. NXDOMAIN and SERVFAIL do
not count as failures.
- IPv4 addresses are returned first: DoH answers IPv6 whether or not the
network has it, and OkHttp tries addresses in order.
- IP literals and localhost never leave the device.
WebSocket RPC (nv-websocket) still resolves through the system.
* feat(config): verify signed config metadata, TUF style
The rules the app will apply to config it fetches, not wired yet:
- A root, signed by a threshold of root keys, names the keys that may sign
the targets list and how many must. The APK carries the first root.
- A new root is accepted one version at a time, signed by a threshold of the
old root's keys and of its own, so keys can be replaced without a release
and a lost targets key can be revoked.
- The targets list gives the sha256 of each config file; it cannot go back a
version, cannot jump more than 10,000 at once, and is refused once it or
its root has expired.
- Ed25519 over the payload bytes exactly as published (BouncyCastle, already
a dependency); a key signing twice counts once; a key must match its id.
* fix(config): parse metadata with the Gson API the app resolves
JsonParser.parseString is not in the Gson version on the app's classpath;
the instance parse method is, and behaves the same here.
* test(runtime): add the Log.e overload with a throwable to the test shim
The first-install fallback logs the failed fetch with its exception, and the
shim only had the two-argument form, so the test hit NoSuchMethodError.
* feat(config): refuse config files the signed list does not give
SignedConfigInterceptor checks every JSON file from pezkuwi-wallet-utils
against signed/targets.json, whichever host the mirrors got it from. A
file the list does not give, or one without a verified list behind it,
comes back as a 502, so callers keep the stored chains and bundled
lists as they do when the source is unreachable. Newer roots are
followed from signed/root.N.json; the targets version and the latest
time seen are stored, so an older list cannot be replayed.
Root keys may now be sr25519 wallet accounts: they sign through the
wallet's message signing, which wraps the bytes in <Bytes>, and the
SDK's schnorrkel verifies them. The APK carries root 1 as an asset,
trusted as the APK is.
wallet-utils master now has the coordinated Bitcoin/Tron/Solana chain
config content (its own compat-revert was reverted back and merged with
pending/post-fix-release now that this app version can parse it) - drop
the temporary pending/post-fix-release override used during development.
Bitcoin was branched off main independently instead of continuing on top
of the Tron send branch, which caused real divergence: both branches touch
the same shared signing/DI code (multiChainEncryptionFor, getMetaAccountKeypair,
NodeHealthStateTesterFactory, AssetsModule/TypeBasedAssetSourceRegistry,
CloudBackup schema, Fee model), and both need to ship together in one
coordinated release once wallet-util's master is unblocked. Merging now
reconciles that before it gets any harder, and gives one branch/versionCode
history for device testing instead of two that silently diverge.
Conflict resolutions of note:
- SecretStoreV2/SecretsSigner: getKeypair and multiChainEncryptionFor now
recognize Tron AND Bitcoin accounts (isTronBased/isBitcoinBased both
threaded through, checked before the Ethereum fallback).
- AccountDataSourceImpl: both address-backfill migrations now run
sequentially in one coroutine (Tron's fix for a race against the legacy
migration applies equally to Bitcoin's backfill).
- CloudBackup: kept Tron's forward-looking Solana schema reservation
alongside Tron's and Bitcoin's now-real fields.
- ChainRegistryModule/NodeHealthStateTesterFactory: adopted Tron's
self-contained short-lived OkHttpClient (simpler than threading the
shared app-wide client through RuntimeDependencies, which is reverted).
- RealSecretsMetaAccount: extended Tron's chain-account MultiChainEncryption
fix to also cover Bitcoin, for the same underlying reason.
- ChainExt.isValidAddress: Tron's branch independently closed the
pre-existing Tron validation gap; kept alongside Bitcoin's own check.
wallet-util's master lacks the Tron/Bitcoin chain config (reset to the last
Play-Store-compatible state, see wallet-util history around 2026-07-11) -
this mirrors the exact override feature/trc20-tron-send used, so a real
device build can see the Bitcoin chain entry. MUST be reverted to master
before this branch merges.
Complements the retryOn429 fix - having a key means requests are far less likely to hit
the rate limit at all, rather than just retrying transparently after they do. Wired the
same way as INFURA_API_KEY/DWELLIR_API_KEY: buildConfigField read from local.properties or
CI secret, added TRONGRID_API_KEY to android_build.yml's secret passthrough (every caller
already uses secrets: inherit, so no per-workflow changes needed beyond this).
wallet-util's master/main got reset to the last content the still-live
Play Store release can parse (see wallet-util repo history around
2026-07-11 - an unrelated production incident, not a regression on this
branch). master no longer serves Tron config/icons, so this branch's test
builds would silently regress to "no Tron" - not because of anything wrong
here, but because the shared config source moved out from under it.
pending/post-fix-release preserves exactly what master had before the
reset. MUST be reverted to "master" before this branch is merged - this
override should never ship.
Was HEZ-on-Asset-Hub-only. Now data-driven from wallet-utils' new
pezkuwi_assets_for_testBalance.json (TEST_ASSETS_URL), asserting every
asset - HEZ/PEZ/USDT/DOT/ETH/BTC across Pezkuwi's 3 chains - gets an
assets DB row written via a single shared BalancesUpdateSystem run, not
just one asset on one chain. Failure message lists exactly which assets
never synced, by name and chain.
SatoshiQaziMuhammed