Where Send keeps its data, and how an integrator reaches it

Every payment a Send user makes settles on Base, the Coinbase-built Layer 2 chain, which means the transfer history is already a matter of public record, readable block by block. So the interesting integration question is not the money movement at all. It is everything the wallet wraps around that movement: the human-readable sendtag that stands in for a long hex address, the public profile and link-in-bio a user shares to get paid, the referral relationships, and the SendEarn reward accruals. None of that is on-chain. It sits in Send's own backend, and that split, half public ledger, half private app state, is what shapes the whole job.

Bottom line: the chain gives you balances, transfers and swap settlement for free, with no permission needed beyond an address. The value an integrator usually wants on top of that, who a sendtag belongs to, what a profile shows, how rewards add up, comes from the app backend and is account-scoped. A complete integration stitches the two together so a single read returns a coherent picture of one account.

What data exists, and where it lives

The columns below separate the two tiers deliberately, because the route to each differs. On-chain rows are observable by anyone running against Base; off-chain rows need a consenting account.

Routes in, and the one we lean on

Three approaches genuinely apply to this app. They are not alternatives so much as parts that combine.

On-chain decode (Base)

For anything that touches the ledger, we read Base directly, through an indexer such as Basescan's API or a JSON-RPC provider, and decode it into wallet-meaningful records. Reachable: balances, transfers, and swaps for any address. Effort is moderate, durability is high because the chain is permissionless and append-only. Nothing here depends on Send keeping a feature alive. The work that matters is decoding: a KyberSwap swap is a contract call, not a transfer, so it has to be unpacked to read sensibly.

User-consented backend access

The sendtag resolver, profile fields, referral graph and reward ledger live behind Send's authenticated app surface. We reach them through a consenting account, mapping the auth flow and the request shapes the app itself uses. Reachable: the full off-chain tier tied to that account. Effort depends on the auth chain; durability is good with a re-validation pass for front-end changes. Access to a consenting account is arranged with you during onboarding, as part of the build.

Native export

Where the app or its web surface offers a user-facing export of activity, we treat it as a low-effort supplement and a cross-check against the decoded on-chain data, not as the primary feed.

For most briefs on this app the spine is the on-chain decode, because it is the most durable surface and needs no per-feature cooperation; the consented backend access is layered on top to add the identity and rewards context the chain cannot give you. We would only recommend leading with the backend if your use case is purely about sendtags and profiles and never touches money movement.

What lands at the end

Deliverables are tied to the surfaces above, not a generic checklist:

• An OpenAPI specification describing a unified read model: one account, both tiers, normalized fields.
• Runnable source (Python or Node.js) for the core reads, sendtag resolution, address activity, swap decode, profile fetch, with retries and pagination handled.
• A protocol and auth-flow report covering the consented backend session, the token or cookie chain as it actually behaves, and the KyberSwap router calldata layout for swap decoding.
• Automated tests against captured fixtures so a backend change surfaces as a failing test, not a silent gap.
• Interface documentation an in-house team can extend, plus data-retention and consent-handling guidance fit for a US operator.

A worked example

Illustrative only, field names and the exact auth shape are confirmed during the build, but this is the shape of a combined read: resolve a sendtag, then pull that address's on-chain activity.

# Two-tier read for one Send account (illustrative)

# 1) off-chain: resolve a sendtag under a consenting session
session = send_login(consented_credentials)          # auth chain mapped during build
addr = session.resolve_sendtag("alice")              # -> "0xabc...def" (Base address)
profile = session.get_profile("alice")               # display name, bio, links

# 2) on-chain: read movement for that address from Base
params = {
    "module": "account", "action": "tokentx",
    "address": addr, "chainid": 8453,                # Base chain id, confirmed in build
    "sort": "desc",
}
txs = base_index.get("/api", params=params)          # Basescan-compatible endpoint

records = []
for t in txs["result"]:
    if t["to"].lower() == KYBER_ROUTER:              # swap, not a plain transfer
        records.append(decode_kyber_swap(t))         # input/output token + amounts
    else:
        records.append(normalize_transfer(t))        # from, to, token, amount, ts

# error handling: empty result vs rate-limit vs bad address are distinct
if txs.get("status") == "0" and txs.get("message") != "No transactions found":
    raise RetryableIndexError(txs.get("result"))

How teams put it to use

• A bookkeeping tool that turns a user's Send activity into categorized statements, with swaps split into buy and sell legs.
• A creator-payments product that verifies a payee by resolving their sendtag and showing the public profile before funds move.
• A partner dashboard that reconciles referral attribution from the backend against on-chain settlement.

Consent and the rules that bind

Send is operated by a US company, Send, Inc.; related project materials describe Send entities as registered with FinCEN as a money services business and on NMLS (as those listings state, not asserted here independently). Two facts shape the compliance posture. First, the on-chain tier is public and permissionless by design, reading Base needs no one's consent, only an address, and we keep those reads data-minimized to what the use case requires. Second, the off-chain tier is personal app data: sendtag ownership, profile, referrals and rewards. We touch it only under a consenting account, with consent scope, expiry and revocation honored, every access logged, and an NDA in place where the engagement calls for it.

On the consumer-promotion side, Send's own listing states it does not target UK consumers with cryptoasset promotions and ties future UK availability to FCA rules under FSMA; we hold to that boundary in anything we build and do not repackage the app's data into a promotion it has disclaimed.

Engineering notes we account for

Two specifics on this app drive design decisions we handle, not hurdles for you:

• Swap decoding is not optional. Because in-app swaps go through KyberSwap's aggregator router rather than a direct transfer, a naive on-chain read shows a contract call with no obvious token-pair meaning. We decode the router calldata and events so swaps read as swaps, and we pin the work to the confirmed router address rather than a label.
• The sendtag resolver is the join key. Linking the public ledger to the private profile depends on resolving a sendtag to its controlling Base address reliably. We map that resolver and design the sync so a handle change or a profile edit does not orphan a record, with a re-validation step for when the app's front end shifts.
• Reward state is split across tiers. SendEarn accrues in the backend and settles on-chain, so we reconcile the two views rather than trusting either alone, which keeps yield figures honest.

Working with us

Source delivery starts at $300, and you pay only after the code is in your hands and behaves the way you need. That model ships you the runnable integration, the OpenAPI spec, the auth-flow and swap-decode report, tests and documentation, yours to run and extend. The alternative is the hosted route: we stand up the endpoints and you pay per call, with no upfront fee, which suits teams that would rather consume an API than maintain one. Either way the build cycle runs one to two weeks. Tell us the app and what you want out of its data, and we arrange access and the compliance pieces with you from there. Start a conversation with the studio.

Screens we worked from

What we checked

Mapped from the app's Play listing and disclaimers, the KyberSwap aggregator documentation for the swap path, the Basescan API docs for the on-chain reads, and the $SEND token material for the chain and migration facts. Sources opened:

• KyberSwap Aggregator API specification
• Basescan API documentation (Base explorer)
• Base block explorer
• $SEND token overview

Mapped by the OpenBanking Studio integration desk · June 2026.

Apps in the same space

Other wallets and payment apps an integrator often unifies alongside Send, named for context, not ranked:

• MetaMask — self-custody EVM wallet; balances and activity sit on-chain, settings and connections in the app.
• Coinbase Wallet — non-custodial multi-chain wallet with USDC on Base and a comparable public-ledger plus app-state split.
• Trust Wallet — multi-chain mobile wallet; on-chain holdings across many networks.
• Rainbow — Ethereum-focused wallet with profiles and an on-chain activity feed.
• Phantom — Solana-first wallet (also multi-chain) holding token, NFT and staking state.
• Rabby — EVM wallet with multi-chain dApp handling and pre-transaction checks.
• Exodus — multi-asset wallet with portfolio and swap history.
• Sentz — stablecoin send, save and earn app with comparable backend reward state.

Questions integrators ask about Send

If Send is non-custodial, what data even needs an integration?

The money movement is on Base and already public, but the layer that makes Send usable is not: the sendtag-to-address resolver, the public profile and link-in-bio fields, referral state, and SendEarn reward accruals all live in Send's backend. Reaching those is the work, and it needs a consenting account.

How do you tell a Send token swap apart from an ordinary transfer on Base?

In-app swaps route through KyberSwap's aggregator router contract, so on-chain they appear as a call to that contract rather than a plain ERC-20 transfer. We decode the router calldata and the emitted events so a swap is recorded as a swap, with the input and output token amounts, instead of an opaque contract interaction.

Which chain and token identifiers should the integration anchor on?

Send operates on Base, Coinbase's Optimism-based Layer 2, and the $SEND token is an ERC-20 there (it migrated from Ethereum, per the project's own token page). We pin the integration to the Base chain ID and the confirmed token contract addresses captured during the build rather than to display symbols, which are not unique.

Can a sendtag be resolved to an on-chain address without the account holder?

Public profile fields tied to a sendtag are readable by design, but mapping a sendtag to its controlling address with confidence, and reading referral or reward ledgers, is account-scoped. We run that part under a consenting account, with access arranged with you during onboarding.