Reaching an Edge wallet's transaction and swap records

Every balance, transaction note and swap record in Edge is encrypted on the handset before it ever touches a sync server. Edge keeps that data in an encrypted repository identified by a syncKey for authentication and a dataKey for decryption — so without the user's credentials there is nothing legible to read on the server side. That single design fact decides the whole integration. The route is not a server query against an institution; it is a consented decrypt that runs with the account holder, then a structured read of what comes out.

For most buyers the practical goal is a clean, normalized feed of transactions, swaps and fiat on/off-ramp orders out of one or many Edge accounts — for bookkeeping, tax, portfolio tooling, or reconciliation. That feed is reachable. Below is where the data lives, the authorized paths to it, and the source we would hand over.

What sits inside an Edge account

The surfaces map closely to what a user sees in the app. Granularity is per-wallet and per-transaction, with user-entered metadata that does not exist on-chain.

Authorized paths to the data

Three routes genuinely apply to Edge. They are not interchangeable, and which one carries the weight depends on whether you need a live feed or a periodic pull.

1 · User-consented decrypt-and-read

The account holder supplies their username and password — or a recovery key — and the integration runs Edge's own login and decryption path in session, then reads the decrypted store. Everything the user can see in the app becomes reachable: wallets, balances, transactions with metadata, swap and ramp orders. Effort is low to moderate, and durability is high because the login system is stable and well-exercised. We arrange the consenting account or test login with you during onboarding; credentials are used in session and not retained.

2 · Protocol analysis of the login and sync layer

For an unattended or server-side sync, we map the login and the syncKey/dataKey repo protocol directly. Edge publishes its client implementation as open source (edge-core-js, per the EdgeApp GitHub), which documents the auth and sync behaviour and shortens this work considerably. Reachable scope matches route 1; the difference is that the read runs as a service rather than an interactive session.

3 · Native CSV / QuickBooks export

Edge exports a wallet's transaction history to CSV or QuickBooks for a chosen date range, per its support documentation. Parsing that file is the lightest path and needs no credentials at all, but it is coarse: it is a periodic snapshot, partner-order detail is thinner than the live store, and it is per-wallet rather than account-wide.

What we would actually build for a recurring feed is routes 1 and 2 together — the consented decrypt as the read, hardened into a repeatable sync via the protocol map — and we keep the CSV path wired in as a same-day bridge and an independent check on the numbers. If your need is a one-off accounting pull, the export alone may be all you pay for.

What a decrypt-and-read looks like

Illustrative pseudo-code for the consented path; field and method names follow the open-source client and are confirmed against the live login during the build.

# 1. Open a context (appId + apiKey arranged during onboarding)
ctx = edge_context(app_id="com.yourco.sync", api_key=API_KEY)

# 2. Consented login — credentials supplied by the account holder,
#    decryption happens locally, nothing is stored past the session
account = ctx.login_with_password(username, password)   # or recovery key

# 3. Walk every currency wallet in the account
records = []
for wallet in account.currency_wallets:
    for tx in wallet.get_transactions():
        records.append({
            "wallet":     wallet.currency_code,        # BTC, ETH, XMR, ...
            "txid":       tx.txid,
            "amount":     tx.native_amount,            # base units, signed
            "fee":        tx.network_fee,
            "date":       tx.date,                     # unix seconds
            "memo":       tx.metadata.notes,           # user-entered
            "category":   tx.metadata.category,
            "payee":      tx.metadata.name,
            "swap":       tx.swap_data,                # partner order, if any
        })

# 4. Errors worth handling explicitly:
#    OtpError            -> 2FA / device token required, prompt the user
#    PasswordError       -> wrong credentials, no retry storm
#    NetworkError        -> sync server unreachable, fall back to cached repo
      

A normalized shape for the feed

On-chain sends, partner swaps and fiat ramps arrive in different shapes; we flatten them to one record so downstream tooling sees a single contract.

{
  "account_ref": "edge:opaque-hash",
  "asset": "BTC",
  "type": "swap",                  // send | receive | swap | buy | sell
  "amount": "-0.01840000",
  "counter_asset": "ETH",
  "counter_amount": "+0.41200000",
  "provider": "letsexchange",      // null for plain on-chain
  "fiat_value": { "usd": "1182.40" },
  "ts": "2026-05-11T08:22:14Z",
  "memo": "rebalance",
  "source": "consented-decrypt"    // or csv-export
}
      

What you get back

Each deliverable is tied to a real Edge surface, not a generic checklist.

• Runnable source for the login-and-sync read path in Python or Node.js — the loop above, hardened, paginating across wallets and partner orders.
• An OpenAPI / Swagger specification for the normalized feed, so balances, transactions, swaps and ramp orders are queryable through one stable contract.
• A protocol and auth-flow report covering the login handshake, the syncKey/dataKey repo model, and how the partner-order records map into the schema.
• Automated tests against a consenting test account and against a CSV export, so the two agree on the same period.
• Interface documentation plus data-retention and consent-handling guidance for running it in your environment.

Consent and the rules that actually apply

Because Edge is non-custodial, the legal anchor is simple and sits with the user: there is no institution holding a balance to consent on their behalf, so the dependable basis is the account holder's own consent and their possession of the credentials that decrypt the store. We treat that as the gating fact and build around it — consent is recorded, access is logged, and credentials are used only in session.

The regulated edges of Edge are the buy/sell and swap partners, not the wallet: MoonPay, Banxa and the swap services carry their own AML, KYC and Travel Rule obligations on their side of each order, and their records reflect that. We keep the integration data-minimized to what the engagement needs, work under NDA where required, and stay within authorized, user-consented access throughout.

What we handle on this build

Concrete engineering realities for Edge specifically, all on our side of the line:

• The zero-knowledge model. Data is only legible after a local decrypt with the user's credentials, so we design the build to run against a consenting account and decrypt client-side — the credentials never need to persist beyond the read, and we architect so they do not.
• HD address rotation and repo sync. Edge issues a fresh address per transaction and syncs through the syncKey/dataKey repo, so we handle transaction de-duplication and address rotation explicitly rather than emitting duplicate or orphaned records when a wallet was only partially synced.
• Many partner record shapes. Nine-plus swap partners and several fiat ramps each return orders in their own format; we normalize them into one schema and wire a re-validation step for when Edge adds or drops a partner, so the feed does not quietly lose a provider's history.

How this brief was put together

Checked on 2026-06-06 against Edge's own support and developer material and its store listing, cross-read with independent reviews of the wallet's architecture. Primary sources opened:

• Edge support — exporting transactions to CSV / QuickBooks
• EdgeApp/edge-core-js — open-source account and wallet core
• Edge support — available payment options and ramp partners
• Google Play listing — co.edgesecure.app

Compiled at the OpenBanking Studio integration desk, reviewed 2026-06-06.

Screens we worked from

Other wallets in the same integration space

Buyers integrating Edge usually want the same feed across several wallets. These are the apps that come up alongside it, with what each one holds:

• Trust Wallet — multi-chain self-custody wallet with in-app swaps and dApp browsing; transaction and token data sit per-device with on-chain settlement.
• Exodus — desktop and mobile wallet holding portfolio balances, exchange orders and a transaction ledger across many assets.
• MetaMask — the default EVM and now multi-chain wallet; account, token and dApp-interaction history are the integration targets.
• Coinbase Wallet — non-custodial companion to the exchange, with encrypted cloud backup and multi-chain holdings.
• Atomic Wallet — multi-asset wallet with staking and built-in swaps, holding balances and trade records.
• Coinomi — long-running multi-chain wallet supporting a very large asset list with built-in exchange.
• Guarda Wallet — multi-platform wallet with balances, exchange and staking records across many chains.
• SafePal — hardware-and-software wallet whose app holds portfolio and transaction data plus swap orders.
• Electrum — long-established Bitcoin-only wallet with a transaction history and address book.
• Phantom — wallet rooted in Solana and now multi-chain, holding token balances and on-chain activity.

Questions integrators ask about Edge

Where does Edge store the data if it is zero-knowledge?

Records are encrypted on the handset before they reach a sync server. Edge holds an encrypted repo keyed by a syncKey for authentication and a dataKey for encryption, so the contents are only readable once a consenting user supplies their username and password or recovery key. The integration decrypts client-side, in session, and reads the store from there.

Can you pull swap and buy/sell history, or only on-chain transactions?

Both. On-chain transactions carry the user's own metadata such as notes and category, and the swap and fiat on/off-ramp orders that surface inside the app come from third-party partners like ChangeNOW, LetsExchange, MoonPay and Banxa. We normalize all of them into one transaction schema.

Does any open-banking scheme apply to a self-custody wallet like Edge?

No account-aggregation or open-banking regime covers a non-custodial wallet, because there is no institution holding the balance to consent on the user's behalf. The dependable basis is the user's own consent and possession of their credentials. The buy/sell and swap partners carry their own AML and Travel Rule obligations on their side of the flow.

Can you start from the CSV export while account access is arranged?

Yes. Edge exports a wallet's transaction history to CSV or QuickBooks for a chosen date range, so that file gives us a working feed to model against on day one while a consenting account is set up for the live decrypt-and-read path.

Source for the login-and-sync read path, the OpenAPI spec, tests and documentation land in one to two weeks. You can take it as delivered source from $300, paid only after delivery once it works to your satisfaction, or skip the build and call our hosted endpoints per request with nothing upfront. Tell us the app and what you want from its data and we will scope it — start a conversation here.