Milestone 4: Mobile

Milestone 4

Budget	$45,000
Due	24 weeks from approval
Deliverable	A prototype Android app, as well as bindings for Rust, Kotlin and Swift
Acceptance	We will demonstrate that the libraries work in a fork of Zkool2 (developed by @Hanh)
Platforms	Android app; Kotlin and Swift bindings
Demonstration	Fork of the open-source Zkool2 wallet
Not promised	An iOS app or App Store release
Source	Official application

Milestone 4 brings Skyhook to mobile devices, where most users are. It ports the bridge’s cryptography to phones through Rust, Kotlin and Swift bindings, so that existing wallets can add shielded swaps as a feature instead of reimplementing the stack, and it delivers a prototype Android application to prove the bindings work. The demonstration takes place inside a fork of Zkool2, an established Zcash wallet.

Bindings first

The bindings matter more than the application. Users already have wallets they prefer, and integration through bindings is the fastest route to real use: a Kotlin binding lets an Android wallet add swaps, and a Swift binding does the same on iOS. All of them wrap one shared Rust core, so behavior proven on one platform holds on all three and the implementations can’t drift apart.

The prototype application exists to prove that the bindings work under real conditions. Any shortcoming it exposes is one an integrator would also have met, so the prototype acts as a forcing function for binding quality; it isn’t meant to compete with existing wallets.

Scope on iOS

The milestone promises Swift bindings but not an iOS application. Bindings let existing iOS wallets integrate swaps directly, which is the goal; building a competing iOS wallet would spend the milestone on distribution work the project doesn’t need. The Android prototype proves end-to-end mobile operation on one platform and the Swift bindings prove integrability on the other. No App Store submission, iOS user interface or second wallet product is promised.

Platform constraints

Mobile platforms impose constraints that desktop development never meets, and the milestone budgets for them from the start:

keys must live in platform keystores, which offer hardware-backed isolation that files can’t match;
background synchronization must respect power budgets that penalize the continuous network activity desktop wallets take for granted;
proving must fit within the thermal and CPU limits of phones, far tighter than the many-core servers used in development;
binary size has to respect app-store limits.

None of these is new to mobile engineering, but each needs deliberate work rather than a simple recompile.

The Zkool2 demonstration

The demonstration runs in a fork of Zkool2, an existing open-source Zcash wallet. Using it proves integration into a real codebase with real users and maintenance standards rather than a throwaway harness; it exercises the bindings against a wallet architecture the team didn’t design, which brings mismatched assumptions to light early; and it produces a public artifact that the community can inspect, run and evaluate independently. The demonstration moves real testnet funds on a real device through the forked wallet’s own interface, without special builds or developer modes.

Relationship to the WebAssembly work

Milestone 1 puts the cryptography in browsers through WebAssembly; this milestone puts it on devices through native bindings. Both share the Rust core, and therefore its audit surface. Work done once in the core (deterministic builds, constant-time discipline, memory hygiene) benefits both, while platform concerns such as keystores and background execution are handled per platform. The program thus gets two deployment targets for little more than the cost of one core and two thin adaptation layers.

Security review

Mobile deployment widens the audit surface in specific, reviewable ways. The integration with platform keystores must be reviewed for resistance to key extraction, since custody rests on hardware isolation working as documented. Data passed between the wallet and the binding layer must be checked for leaked secrets, including in logs, backups and screenshots. Network behavior must be reviewed against the privacy standard, because mobile radios expose traffic patterns that wired connections don’t. Targeting these areas keeps the security effort proportional to the milestone.

Maintenance

Bindings decay when the core changes, so the milestone includes a maintenance arrangement as well as the initial code. The Rust core versions its interfaces explicitly, bindings pin to interface versions rather than tracking the latest code, and the prototype application continuously exercises the current combination. Third-party integrators therefore build against documented, stable interfaces, and improvements flow back into the shared core, where they benefit every platform.

Status

Done

The portable core exists in Rust. Scanning, opening, witnessing, filling and broadcasting are all implemented as platform-independent library code, with JSON interfaces of exactly the shape the mobile bindings will wrap. The cryptography makes no desktop assumptions: the pure functions don’t touch the filesystem, and seeds and chain data arrive as arguments from the caller.

Remaining

Everything mobile-specific remains to be built: the Android prototype, the Kotlin bindings, the Swift bindings, and the demonstration inside the Zkool2 fork, which depends on all three. No mobile code exists yet. Acceptance is the bridge operating inside a real wallet on a real device.