Changelog
what changed, when.

011.0.0 — first release

Current App 1.0.0+1

Entries carry no date until the version is published on the marketplace; from 1.0.1 onwards each heading states the date that version was released.

Included

• Non-custodial Hyperliquid perps terminal in Flutter for web, iOS and Android: wallet created or imported on the device, orders signed locally and sent straight to Hyperliquid.
• Markets table, trade screen with candle chart, order book, trade tape, positions blotter and docked order ticket; leverage, TP/SL, reduce-only, price alerts, calculator.
• Stock / commodity (xyz) markets behind their own switch.
• USDC deposit and withdrawal through the Hyperliquid bridge on Arbitrum.
• Operator builder fee (Hyperliquid builder codes) with separate perps and stock rates, the on-chain approval flow and the Earnings screen.
• Operator console in builds compiled with AXIS_OPERATOR_PASSCODE; end users get settings through a hosted config.json or optional Firebase.
• Mainnet by default; testnet by build setting or console.
• Risk disclosure before the first order; WalletConnect (Reown) sessions on the Apache-2.0 releases of the Reown packages; app lock.
• Safe defaults: perps off, builder fee off, no builder address, no bundled keys or Firebase project.

Known limitations

• Settings, onboarding, security centre, notifications, WalletConnect and QR screens keep the layout of the wallet engine AXIS grew from.
• Swap, bridge, buy and sell from that engine are not part of AXIS: the terminal does not read their settings and the operator console does not offer them (the keys AXIS reads).
• The operator console exists only in a build given an operator passcode, and changes only the device it is used on (details).
• The source still contains the wallet engine's Bitcoin, Solana, Sui and Tron code; the terminal does not use it on the trading path.
• The app icon is a simple geometric mark; replace it with your own.

Migration: none, first release.

02Upgrade notes

1.0.0 is the first published version of AXIS. There is no earlier AXIS release to upgrade from, so there are no environment settings, data structures or config keys to migrate.

Every future release adds an entry above with an Upgrade notes block that lists, when anything changed:

• Config keys: new keys and their defaults, renamed or removed keys, changed meanings, so you can update your published config.json or Firebase values.
• Build settings: new, renamed or removed --dart-define values.
• Stored data: anything that changes what the app keeps on users' devices (wallet vault, preferences), and whether it is migrated automatically on first start.
• Files you customised: changes to axis_identity.dart, app_config.dart, platform manifests or icons that you need to merge by hand.
• Minimum tool versions: Flutter, Dart, Android and iOS targets.

If an entry says "no upgrade steps", the merge below is all you need.

03How to update

Keep the original package and your changes apart from day one, so a new version is a merge, not a rewrite:

git init
git add .
git commit -m "AXIS 1.0.0 (original)"
git branch vendor            # untouched copy of the original

Before the first commit, check that your own android/key.properties, keystore, google-services.json and GoogleService-Info.plist are ignored (they are in the shipped .gitignore).

1. Back upCommit your work, and keep a copy of your published config.json.
2. Download the new versionFrom your CodeCanyon Downloads page.
3. Unpack it on the vendor branch

   git checkout vendor
   # delete the old files (not .git), unzip the new version here
   git add -A
   git commit -m "AXIS <new version> (original)"
   git checkout main
   git merge vendor

4. Resolve conflictsUsually only in files you rebranded: axis_identity.dart, app_config.dart, platform manifests, icons. Keep your values, take the new code.
5. Rebuild and check

   flutter pub get
   flutter gen-l10n
   flutter analyze
   flutter test

6. Read the entry aboveApply any migration steps and new config keys it lists, then release. For an important fix, publish min_app_version once the new version is live.

Versions follow major.minor.patch: a patch fixes bugs, a minor adds features with safe defaults, a major may need migration steps, which are always listed here.