Setup guide

Turn a Hyperliquid Wallet Into an iPhone Widget

The first ChartNothing onboarding path is designed to be teachable: paste a wallet, connect the feed, save the template, and use that feed for native beta surfaces.

By ChartNothing Product Team · Updated · 8 min read

A step-by-step guide to validating a public wallet, launching one read-only Account Suite feed, reviewing its dashboard, and preparing it for signed-in iPhone and Apple Watch sync.

Before you start

You need the public wallet address for the Hyperliquid account you want to view. A valid input uses the familiar 0x-prefixed, 40-hex-character address shape. This is public account identity, not a secret, but it can still expose financial activity and should be handled deliberately.

Do not provide a seed phrase, private key, exchange login, one-time code, or trading API credential. The ChartNothing Account Suite is designed around Hyperliquid's public read-only information path. If a screen asks for signing or trading permission, stop: that is outside this workflow.

Step 1: preview, paste, and validate

Start with the anonymous demo to see the intended dashboard and device hierarchy. Then paste the real public wallet. ChartNothing normalizes the address shape and blocks connector creation until validation succeeds. If sign-in is required, the wallet remains in the route so authentication does not make you repeat the first step.

The focused setup should show one Account Suite choice rather than separate current-state and history products. The suite represents one user outcome: understand the account now, see available performance history, and publish one feed to chosen surfaces.

Step 2: run the first read-only refresh

The backend provisions a server-owned connector draft restricted to the official Hyperliquid API host. One logical refresh makes a required clearinghouse-state request and a portfolio-history request. Response size, timeout, host, and method boundaries are enforced before the payload reaches the feed adapter.

On success, the adapter creates metrics, history series where available, an open-position table, compact widget copy, source metadata, and a captured timestamp. The raw response is not exposed as a public page and ChartNothing does not start a broad OHLC or market-history warehouse.

Step 3: review and publish

Review the web metrics first. Confirm currency and percentage units, signs, position symbols, leverage, entry and liquidation values, and the captured time. A chart should have enough points and a meaningful axis; a one-point response should become a metric rather than a flat line pretending to be a trend.

Publish to App validates the template, saves the recipe, activates it on the feed, and marks the owner feed ready for native account sync. This is the customer action. Scoped GET shares remain optional for terminal smokes and external integrations; customers should not have to copy bearer tokens into the app they just installed.

Step 4: choose freshness and verify devices

Manual refresh proves the source and template. Scheduled refresh is a separate budgeted capability. Choose a cadence that matches how the information is used and remember that WidgetKit and watchOS decide when cached content is displayed or refreshed on-device.

During native testing, sign in to the iPhone app with the same ChartNothing account, select the app-ready feed, confirm the App Group cache updates, then add the widget and watch complication. The displayed freshness time should match the selected feed, and stale/error states should remain readable without opening the website.

  • Web: full metrics, history, risk, and positions.
  • iPhone widget: primary, secondary, compact trend, freshness.
  • Watch: glanceable value, state, and reduced trend where supported.
  • App: feed selection, refresh status, account, and notification preferences.

Frequently asked questions

Can I use someone else's public wallet?

Technically the source is public, but you should respect privacy, local law, platform terms, and context. Never present a public account as your own.

Why does the widget show older data than the web page?

The backend feed, app cache, WidgetKit timeline, network state, and plan cadence can update at different times. The captured/freshness label is the authoritative clue.

Can I change which values appear on the watch?

The template and native preferences are intended to control the compact projection. Available fields still depend on the complication family and current native release.

Sources and further reading