Reaching Spring Development Bank's wallet and on-chain ledger

What data lives inside SDB

Each row below is a real surface of the app, where it comes from, how fine-grained it is, and what you would build on it.

Authorized routes to the data

On-chain extraction (Ethereum + Polygon)

The blockchain side needs no one's permission to read. SDB token transfers and USDT deposits on Polygon PoS are public, so a node or explorer query returns holdings, deposits and confirmations directly. This is the most durable route — chain data does not change shape when the app ships a new build. We point the client at an RPC endpoint and a block cursor, and it keeps pace with finality.

Consented portal integration (protocol analysis)

Balances, the off-chain ledger, FX quotes, transfers and staking payouts live server-side behind the account login. We map the session and token chain the app uses, then read those surfaces under the account holder's authorization. Effort is moderate; durability depends on the app's release cadence, which is why the build ships with tests that catch a changed field. Access is arranged with you during onboarding, against a consenting account.

Native export, where present

If a statement or transaction export exists in-app, it serves as a low-effort fallback and a cross-check against the live reads. It is not the primary feed — it is a reconciliation aid.

For most use cases we would run the first two together: the chain gives you settlement that can be proven independently, and the consented portal gives you the off-chain ledger the chain cannot see. Pick the portal alone only if on-chain confirmation is irrelevant to you.

What lands in your repo

• Runnable Python and Node.js client — on-chain readers (token balances, USDT deposit confirmation on Polygon PoS, SDB across both chains) plus a consented portal session client, exposed as one normalized feed.
• Deposit and transfer poller — a per-address block-cursor worker that picks up new SDB and USDT activity as blocks finalize and emits events you can route into your own queue.
• Automated test harness — fixtures for each surface so a changed response field shows up as a failed assertion before it reaches your data.
• Normalized cross-chain schema — one record shape that nets the Ethereum/Polygon split and the off-chain balances into a single per-currency view.
• OpenAPI/Swagger description of the mapped portal surface, for your own tooling.
• Protocol and auth-flow report — the session/token chain as it actually works on this app.
• Interface documentation and data-retention guidance.

A read against the live surfaces

Illustrative, trimmed from the kind of client we ship. The SDB token address is hedged to the block-explorer listing; the portal host is a placeholder for the surface mapped during the build.

# Confirm an SDB/USDT deposit on Polygon PoS, then read the off-chain balance.
from web3 import Web3

polygon = Web3(Web3.HTTPProvider("https://polygon-rpc.com"))
# SDB token contract, per the block-explorer listing (verify before use):
SDB = polygon.to_checksum_address("0xdf136ef2afd305fb6334d53fe4ff9ae82f5b3180")

def new_deposits(deposit_addr, token, cursor):
    # resume from the last seen block; never rescan the whole chain
    start = cursor.get(deposit_addr, "latest")
    logs = polygon.eth.get_logs({
        "fromBlock": start,
        "address": token,
        "topics": [TRANSFER_SIG, None, topic(deposit_addr)],
    })
    cursor[deposit_addr] = polygon.eth.block_number
    return [decode_transfer(l) for l in logs]

# Off-chain ledger: balances behind the account holder's session.
import requests

r = requests.get(
    "https://app.springdevelopmentbank.example/api/balances",  # surface mapped during analysis
    headers={"Authorization": f"Bearer {session_token}"},
)
if r.status_code == 401:           # session expired -> refresh once, then retry
    session_token = refresh(session_token)
    r = requests.get(r.url, headers={"Authorization": f"Bearer {session_token}"})
r.raise_for_status()

for line in r.json()["currencies"]:   # ~11 currencies, incl. digital gold
    print(line["code"], line["available"], line.get("chain", "fiat"))

Consent and a contested regulator

SDB's regulatory story is unusual and worth stating plainly. The bank was launched by Myanmar's National Unity Government in 2023 and describes itself as licensed by an interim central bank that the NUG set up; the military junta's own central bank has said digital currencies are not permitted in the country. Both reports are from the news coverage cited below. That standoff means there is no settled banking-supervision regime to ride here, and no open-banking or account-aggregation scheme of the kind a UK or Brazilian app would offer.

So the dependable basis is the account holder. We work from the consent of the person whose data it is, plus the public Ethereum and Polygon ledgers that anyone may read. Consent is recorded, access is logged, the data set is kept to what the use case needs, and an NDA is in place where the engagement calls for one. We do not assert any licensing claim of the app's as settled fact, and we do not work around the account login — we read what the holder authorizes.

Engineering notes from the build

Two things about this app drive real decisions in the client, and we handle both rather than hand them to you as homework.

Dual-chain reconciliation. SDB is minted on Ethereum and bridged to Polygon, so the same logical holding can appear on two networks. We read each chain separately, tag balances by network, and net the bridged portion, so the unified number matches what the app shows the holder instead of double-counting the split.

On-chain settlement versus the in-app credit. A USDT deposit confirms on Polygon PoS, but the app credits its own internal ledger, and the two can sit a few blocks apart. We design the sync so a confirmed on-chain transaction is matched to its portal credit, with the lag window handled explicitly rather than assumed away.

Access and any sandbox or consenting test account are set up with you during onboarding; the build runs against that, not against a wall you have to clear first.

Interface evidence

Store screenshots of the app, for reference on the surfaces described above.

Sources & review

Checked on 7 June 2026 against the app's store listings, its public site, and news and token-data coverage of the SDB token's Ethereum/Polygon split, its Polygon PoS deposits, and the bank's disputed status in Myanmar. The token contract address shown above came from a block explorer and should be re-verified at build time.

Primary references: RFA — Myanmar's shadow government sets up crypto bank, The Register — Myanmar's first crypto-based bank launches, The Irrawaddy — SDB crypto after MEXC listing, Bitrue — Introduction to the SDB token.

Compiled by OpenFinance Lab engineering, 7 June 2026.

Other apps in the same category

Same wallet-and-multi-currency territory, named for keyword reach and to show where a unified integration lands. No ranking is implied.

• Revolut — multi-currency accounts with built-in crypto trading; holds fiat balances, card transactions and crypto positions behind one login.
• Wirex — crypto neobank supporting many fiat currencies and a wide set of crypto assets, with automatic conversion at spend.
• Cash App — peer-to-peer payments plus a Bitcoin balance, savings and investing for US users.
• Bleap — self-custodial MPC wallet with card spending and stablecoin cashback; balances are user-controlled rather than custodial.
• Quppy — all-in-one wallet consolidating fiat and crypto balances, cards and transfers in a single account.
• Theya — Bitcoin self-custody with multi-sig across phones; holds key shares and on-chain balances.
• Ping — dollar and crypto accounts plus invoicing for international contractors, with same-day payout records.

Questions integrators ask

The same SDB balance shows up on-chain and inside the app — which one do you treat as correct?

Both, mapped against each other. On Polygon PoS and Ethereum we read token movement straight from the chain; inside the app the credited ledger can trail a confirmed transfer by a few blocks. The build matches a confirmed on-chain transaction to its portal credit, and flags any holding that turns up on one side but not the other.

How does new activity get picked up — do you poll, or push?

On-chain, we keep a block cursor per address and pull new SDB and USDT transactions as blocks finalize, so a re-run resumes from the last seen block instead of rescanning. The off-chain ledger syncs the consented portal session on a schedule you set. The packaged Python and Node.js client exposes both as one feed.

SDB sits on both Ethereum and Polygon — how do you avoid double-counting it?

We treat the bridged supply as one logical holding. The client reads each network on its own, tags balances by chain, and nets the bridged portion so the unified figure matches what the account holder sees in the app rather than summing the two sides twice.

Spring Development Bank's licensing is disputed — what authority do you work under?

The account holder's. The bank is licensed by the National Unity Government's interim authority and that status is contested inside Myanmar, so we don't route through any banking-regulator gateway. We read what the consenting account holder authorizes plus the public Ethereum and Polygon ledgers, log the consent, and keep the data set minimal.