Web App Development

Web app integration with Abstraxion — guides, authentication modes, and xion.js demo references

Verona Meta Accounts and gasless flows are integrated into web apps through @burnt-labs/abstraxion (React provider and hooks). Lower-level signing and account types are shared with @burnt-labs/abstraxion-core.

Guides in this section

Pick a document by what you are building. For how to choose authentication.type (auto, signer, embedded, …), see Authentication and integration details below. For why teams combine auth modes with signing hooks (before you copy env tables), see Abstraxion modes and opportunities.

Account abstraction with gasless transactions

End-to-end React (Vite) app: Treasury, Counter contract, auto auth, native <button>, hooks, and transactions.

Abstraxion modes and opportunities

Explanation: start with auto / dashboard auth; then signer + session vs signer + requireAuth; multi-wallet UI as wiring only; passkey/backup as narrative last. Verify in demo-app.

Abstraxion signer mode

type: "signer": implement getSignerConfig; session vs requireAuth signing; vendor wiring examples (e.g. Turnkey) and env from demo-app/.env.example.

Custom UI and Abstraxion loading states

Hook-first UX: login, granular flags, session lifecycle (works across auto / popup / redirect).

Reference implementation: xion.js apps/demo-app (Next.js App Router—each route isolates one pattern). The main tutorial is Vite + React; use import.meta.env.VITE_* there vs NEXT_PUBLIC_* in the demo.

---

Authentication and integration details

Use this section when you need mode names, defaults, env vars, or signing behavior. The guides above walk through concrete projects; this part is the compact map.

Recommended default: auto

For most new apps, set:

authentication: {
  type: "auto",
  authAppUrl: process.env.NEXT_PUBLIC_AUTH_APP_URL,
},

Behavior: During configuration normalization, auto becomes either popup (desktop-style auth window) or redirect (full-page navigation on mobile / PWA). The SDK then runs the same code paths as those explicit modes. End users get an experience similar to common OAuth flows: the dApp stays mounted when a popup is used.

Backward compatibility: If you omit authentication entirely, the SDK defaults to redirect for the dashboard flow. That remains supported, but new integrations should set auto explicitly so intent is clear and desktop users get popups where appropriate.

Glossary (AuthenticationConfig.type)

These labels match the TypeScript union on AbstraxionProvider config (@burnt-labs/abstraxion).

type	What it does
auto	Resolved at runtime to popup or redirect (desktop vs mobile / standalone). Recommended default for dashboard auth.
popup	Auth UI opens in a separate window; parent dApp stays loaded.
redirect	Full-page navigation to the auth app and return (e.g. ?granted=true). Used implicitly when authentication is omitted, or as the mobile leg of auto.
signer	No dashboard redirect: you supply a getSignerConfig (MetaMask, Turnkey, etc.) and AA API / contract metadata. See Abstraxion signer mode.
embedded	Dashboard UI runs inside an iframe you host (iframeUrl). Use AbstraxionEmbed and authentication.type: "embedded". See demo routes /embedded-inline and /embedded-dynamic.

When to use which mode

Scenario	Prefer	Example in demo app	Key env / config
Standard Meta Account login (most dApps)	auto	/popup-demo	NEXT_PUBLIC_AUTH_APP_URL
You build all connection UI with hooks	auto (or popup / redirect if you pin one)	/loading-states	Same as above + treasury / chain
Legacy reference: pre-built modal + Burnt UI (not recommended for new apps)	auto or redirect	/abstraxion-ui	@burnt-labs/ui; prefer login() + your own UI (tutorial, /loading-states)
Wallet-led or programmatic signer (no dashboard)	signer	/signer-mode	Implement getSignerConfig; copy env from demo-app/.env.example (AA API, code id/checksum, optional indexer)
Session-key vs user-pays-gas signing (useAbstraxionSigningClient vs { requireAuth: true })	See demo (auth is signer in that route)	/direct-signing-demo	Same env family as signer mode; compare hooks and fee simulation in source
Inline or “button + modal” embedded dashboard	embedded	/embedded-inline, /embedded-dynamic	NEXT_PUBLIC_IFRAME_URL (demo)

Signing model (brief)

• Default gasless path: useAbstraxionSigningClient() — session-style signing (Treasury / grantee flow) as in the main tutorials.

• Direct / user-pays-gas: useAbstraxionSigningClient({ requireAuth: true }) — see the direct-signing demo for fee simulation vs "auto".

For combinations and product posture (not just hook names), see Abstraxion modes and opportunities. Details stay in the tutorial and the demo source so this hub stays stable for navigation.

React vs Next.js

New walkthroughs use React + Vite with VITE_* env vars and a provider at src/main.tsx. Next.js remains valid: mirror the same config in a client layout with NEXT_PUBLIC_*—see demo-app and the optional Next.js section in Account abstraction with gasless transactions.

Some Next demo layouts use export const dynamic = "force-dynamic" when server layouts read process.env at runtime (e.g. signer or embedded). Pure Vite client apps do not need that.