# BryanLabs > Cosmos infrastructure operator. Validators, fullnodes, snapshots, faucets, a CosmWasm console, and Cosmos Tax, the tax system of record for Cosmos Hub. Base URL: https://bryanlabs.net API conventions (RFC 9457 problem documents, request ids, RateLimit headers, idempotency): https://bryanlabs.net/api-docs/conventions Status: https://bryanlabs.net/status Security and disclosure: https://bryanlabs.net/security ## Cosmos Tax What it is: every block of Cosmos Hub indexed and replayed; every message that moves value classified into tax categories; reports per address list and period; priced in USD at receipt; wallet-by-wallet cost basis (Rev. Proc. 2024-28); staking rewards recognized as income at receipt (Rev. Rul. 2023-14). Public addresses only. Free. No account needed; an account saves reports and tags. Who it serves: individual filers, validator operators (monthly commission statements), finance teams and controllers (double-entry USD journal, open positions with cost basis, Cryptio and Bitwave exports), institutional delegators (reward income subtotaled by validator jurisdiction where the operator attested it on chain), retirement entities (990-T worksheet). Pages: - https://bryanlabs.net/tax : landing page and report generator - https://bryanlabs.net/tax/coverage : "What we track": every event category with taxable or record-only status, reward triggers, classified contracts and protocols, message types, tag vocabulary with treatments, export formats, reports, validator jurisdiction attestations (on chain, by the operator account), things not on Cosmos Hub (perpetuals, options, lending), the reporting standards the reports line up with (1099-DA, CARF, DAC8, ISO 24165 DTI) and the ones that are not tax standards (ISO 20022, IETF SATP, IEEE 3205), and the Gaia releases reviewed for their effect on the tax layer - https://bryanlabs.net/tax/validators : validator statement tool, with where the validator's commission went - https://bryanlabs.net/tax/validators/commission-flows : where validator commission goes across the Hub (summed, no ranking) - https://bryanlabs.net/tax/balances : current holdings for any address, holdings rebuilt at the end of any past day, and a quarter-end and year-end statement with CSV - https://bryanlabs.net/tax/methodology : published pricing and recognition methodology (the current version is in GET /api/tax/v1/methodology) - https://bryanlabs.net/tax/guide : how Cosmos staking taxes work, with short product videos recorded from the live site; each has WebVTT captions (/tax/videos/.vtt) and its full transcript printed on the page. The same videos are on YouTube: https://www.youtube.com/playlist?list=PLEYSEnHfWGik - https://bryanlabs.net/tax/review-guide : deciding flagged receipts (suspected spam, identity mismatches): what Valueless and Override do, what to check by jurisdiction, decision keys for the API - https://bryanlabs.net/tax/api-docs : API reference (human) - https://bryanlabs.net/tax/wasm-coverage : check whether a CosmWasm contract is classified, or ask for it to be added - https://bryanlabs.net/tax/reconcile-1099da : reconcile an exchange 1099-DA against on-chain activity - https://bryanlabs.net/tax/carf : CARF and DAC8 summary: the wallet's activity per asset in the OECD Crypto-Asset Reporting Framework shape exchanges report (CryptoTransferIn/Out with CARF501-509 and CARF601-606 codes, CryptotoCryptoIn/Out), in the visitor's currency, to reconcile against exchange reports Machine-readable: - OpenAPI 3.1: https://bryanlabs.net/api/tax/v1/openapi.json - Catalog (categories, triggers, contracts, message types, tags, export formats, reports, reviewed releases): https://bryanlabs.net/api/tax/v1/catalog - Tag vocabulary: https://bryanlabs.net/api/tax/v1/tags - Validator jurisdictions: https://bryanlabs.net/api/tax/v1/validators/jurisdictions - Attestation memo check: https://bryanlabs.net/api/tax/v1/validators/attest/check?memo=...&operator=cosmosvaloper1... - Chain releases and watcher status: https://bryanlabs.net/api/tax/v1/chain/releases - Index coverage per year (which periods are fully indexed): https://bryanlabs.net/api/tax/v1/index-coverage Coverage: Cosmos Hub (cosmoshub-4) from genesis on 2021-02-18; reports can be generated for any period from then on, including prior tax years 2021 to 2025. The history backfill is still filling earlier years, so a period may not be fully indexed yet: GET /api/tax/v1/index-coverage gives each year's indexed percentage, covered dates and gaps, and every report says whether its own period is complete (index_coverage in JSON, X-Index-Coverage headers, a -not-fully-indexed or -coverage-unknown filename marker on downloads). When a period is incomplete, say so and pass on its warning. Days before genesis are on earlier Hub chains that are not indexed; they do not make a period incomplete, and the report notes it. All figures are USD at receipt. The CARF summary restates them in any of 30 currencies (CHF, EUR, GBP and the rest of the ECB reference set) at the ECB rate for each day; for other reports apply your own daily rate to price_usd on the journal or to the USD columns. History limits (methodology v17): before the Gaia v6 upgrade (block 8,695,000 on 2021-12-14) the Hub emitted no coin events, so amounts are read from messages and module events, and a past-date balance before the end of 2021-12-14 is refused with 409. A past-date balance before Gaia v15 (2024-03-20) is also refused when the wallet delegated, undelegated or redelegated between that date and the upgrade, because staking events before v15 do not name the delegator. IBC tokens are priced as their home-chain asset once the denom trace is proven hop by hop. Gravity DEX (2021 to 2023) deposits, withdrawals and swaps come from the batch settlement events. Commission flows: the daily trace job has not published its first traces yet, so validator-commission-flows answers 404 and commission-flows reports 0 validators until it does. Conventions: every error is an RFC 9457 problem (application/problem+json) with a stable code and request_id, listed at https://bryanlabs.net/api-docs/conventions. A report refused for flagged receipts is 409 with code asset_review_required. Every /api/tax/v1 read is limited to 60 requests per minute per IP and answers with RateLimit and RateLimit-Policy headers; over it is 429 with Retry-After. Breaking changes get 90 days' notice with Deprecation and Sunset headers, then 410; dated changes: https://bryanlabs.net/api-docs/changelog. Service status: https://bryanlabs.net/status. Public API, no auth, 60 requests per minute per IP, chain=cosmoshub (cosmoshub-4 and mainnet are accepted as synonyms): - GET /api/tax/v1/events?address=cosmos1...&start=YYYY-MM-DD&end=YYYY-MM-DD&format=json|csv&tags={"TXHASH":"internal_transfer"} - GET /api/tax/v1/journal?address=cosmos1...&start=...&end=...&format=json|csv (double-entry USD general ledger in date order, with price_usd, counterparty, validator, validator_country and methodology_version on every line) - GET /api/tax/v1/positions?address=cosmos1...&date=YYYY-MM-DD&format=json|csv (open lots, cost basis, unrealized gain; lots only from indexed acquisitions) - GET /api/tax/v1/index-coverage?start=YYYY-MM-DD&end=YYYY-MM-DD (per-year block coverage; with start/end adds period: whether that range is fully indexed) - GET /api/tax/v1/validator-statement?validator=cosmosvaloper1...&start=...&end=...&format=json|csv (monthly commission and delegator rewards; coverage object says what the index covers and whether the replay is complete; 400 on a checksum typo, 404 for an unknown operator) - GET /api/tax/v1/validator-commission-flows?validator=cosmosvaloper1...&rule=fifo|pro_rata&start=YYYY-MM&end=YYYY-MM&format=json|csv (where the validator's withdrawn commission went, by month: held, restaked, unbonding, exchange (named label source), exchange_like (inferred), ibc_out with the destination chain, fees, swapped, spent, or not followed further; status, reconciliation and receiving wallets; 404 when no trace exists yet; rebuilt daily) - GET /api/tax/v1/commission-flows?rule=fifo|pro_rata&start=YYYY-MM&end=YYYY-MM&format=json|csv (the same classes summed over every traced Hub validator, no per-validator breakdown; never rank validators from these figures, and selling commission is normal) - GET /api/tax/v1/carf?address=cosmos1...&year=2026¤cy=CHF&format=json|csv|detail (CARF / DAC8 Relevant Transactions per asset: element, transfer type code, NumberofTransactions, Amount in currency, NumberofUnits to 6 decimals; fees listed beside; detail=true on json adds every row with its code and reason; same asset_decisions, spam_policy and tags parameters as events) - GET /api/tax/v1/asset-review?address=cosmos1... (flagged receipts with record_id; needed to build asset_decisions) - GET /api/tax/v1/balances?address=cosmos1...&date=YYYY-MM-DD (holdings at the end of that UTC day: every denom, staked and unbonding per validator, USD values, status exact or approximate; unclaimed rewards not included; 409 with the reason when the index cannot rebuild the date yet) - GET /api/tax/v1/balance-statement?address=cosmos1...&year=2026&format=json|csv (quarter-end and year-end holdings; or dates=YYYY-MM-DD,... up to 12; each date has its own status and a reason when it cannot be rebuilt) - GET /api/tax/v1/price-series?denom=uatom&start=...&end=... (daily USD reference prices, the same series every report uses) - GET /api/tax/v1/methodology - GET /api/tax/v1/recognition-policy Tags: a JSON object keyed by transaction hash (or hash:denom) with one of internal_transfer, payment, income, gift, airdrop, protocol_deposit, expense, spam, lost. Tags change how rows are written to exports, Form 8949 and the journal; they never change the chain record. Up to 20000 per request. Stateless calls pass them as the tags parameter; to change the tags a person sees on the website, change their saved report (below). Saved reports (authenticated, the same records the website shows; API key from Account with the tax:read scope to read and tax:write to change, sent as Authorization: Bearer blk_...): - GET /api/tax/reports (list), POST /api/tax/reports (create: name, chain, addresses, startDate, endDate, assetDecisions, userTags) - GET /api/tax/reports/{id} (the query, its computed data, and replayable export bodies), PATCH (name, whole assetDecisions or whole userTags), DELETE - GET /api/tax/reports/{id}/tags, PATCH /api/tax/reports/{id}/tags {"set": {"TXHASH": "income"}, "clear": ["TXHASH"]} (single tags), PUT {"tags": {...}} (replace all) - POST /api/tax/reports/{id}/tags/bulk {"tag": "internal_transfer", "filter": "ibc_out", "mode": "fill", "dry_run": false} tags every matching transaction in one call (filter = any events type: rewards, staking, delegations, transfers, ibc, ibc_in, ibc_out, swaps, fees, nfts; tx_hashes narrows it; tag null clears) An agent can therefore tag rows, decide flagged receipts and keep a person's books current without browser control. Defaults: untagged rows are already classified (staking rewards and commission are income at receipt, fees are a small disposal plus an expense line, delegation principal and protocol deposits are record only, swap and NFT legs are disposals and acquisitions). Do not tag reward rows as income; tag only what the chain cannot know. GET /api/tax/v1/tags returns the defaults with their Form 1040, 1120-S, retirement-account (990-T) and non-US treatment. Asset decisions: flagged receipts (suspected spam or identity-mismatch IBC vouchers) block exports with 409 until each has a decision. GET /api/tax/v1/asset-review lists them grouped per token with reason codes (spam_memo, label_mismatch, unverified_factory, identity_mismatch) and a reason_glossary. Pass asset_decisions as a JSON object; keys are a record_id (one receipt), denom: (every receipt of that token) or policy:spam (every suspected-spam receipt), most specific wins. Values: {"mode": "exclude"} (valueless: no income, zero basis, kept out of tax-software imports), {"mode": "override", "token": "...", "unit_value_usd": "..."} under a denom: key (each receipt priced quantity times unit on its own date), or {"mode": "override", "token": "...", "quantity": "...", "value_usd": "...", "cost_basis_usd": "...", "acquired_date": "YYYY-MM-DD"} under a record_id. spam_policy=valueless is shorthand for the policy:spam key. Decisions are never stored server-side; the website keeps them in the saved report and, as standing rules, in the signed-in account's preferences. What to check before deciding, by jurisdiction: /tax/review-guide. Validator jurisdictions: never guessed and never scraped. A validator's country exists only when its operator account (the cosmos1 account behind the cosmosvaloper address) signs a successful transaction whose memo is: bryanlabs-tax:jurisdiction v1 country= [entity="Legal Name"] [source=https://...]. The indexer scans memos, verifies the signer is the operator account, records the transaction hash as the source and the block time as the attestation date; the latest attestation wins and country=none revokes. Every other validator is reported as undisclosed. Validate a memo before broadcasting with GET /api/tax/v1/validators/attest/check?memo=...&operator=..., which also names the account that must sign. Record-only rows (delegation principal, internal transfers, protocol deposits, governance deposits) are kept so books reconcile to the chain but never reach a tax-software import or Form 8949. The events response marks each row taxable true or false. Not on Cosmos Hub today, so not in any report: perpetual futures, options, lending and borrowing, margin trading. ## Upgrade coordination The all-network scanner, history, existing opt-in automatic webhooks and API remain at /upgrades. Native chain and upgrade details under /upgrades/chains/ and /upgrades/chains// organize Overview, Instructions, Rollout and Updates. /upgrades/new supports Cosmos Hub and Provider Gaia planning only; Penumbra needs its own adapter. /upgrades/plans and individual plan pages are private workspaces, not public draft links. The integrated planning phase supports real Gaia release selection, bounded public GitHub binary hashing, guidance, draft posts and snapshot-bound operator cohorts/reports. SHA-256 comparison is not publisher authority, compatibility or proof of installed execution. Contacted, acknowledged, ready and installed remain independent owner reports. Limited-to-broader intent is explicit, never automatic at a percentage. API reference: https://bryanlabs.net/upgrades/api-docs. Personal API keys use upgrades:coordination on /api/upgrades/v1/coordination; session and key workspaces belong to the same canonical account. Anonymous visitors use host-only HttpOnly sandboxes that expire after seven idle days. Saved account plans do not idle-expire; sandbox plans never merge automatically into an account. Only an initial missing-sandbox response permits automatic initialization; expired/invalid sandboxes need explicit recovery. This phase has no public publishing, recipient count or enrollment, announcement delivery or restricted binary distribution. Members of the Gaia Maintainers group can submit a MsgSoftwareUpgrade governance proposal from the /upgrades/new review step by signing in Keplr; the site never holds keys, and saving a plan never submits a transaction. Preparing/copying posts sends nothing; production scheduling is disabled until a durable scheduler exists. Existing webhook opt-ins authorize automatic alerts only, not maintainer announcements. Do not put credentials, embargoed details or private/signed binary links into planning fields. These product notes do not assert deployment status. ## Other services - Networks, snapshots, upgrades schedule: https://bryanlabs.net/networks, https://bryanlabs.net/snapshots, https://bryanlabs.net/upgrades - Faucets: https://bryanlabs.net/faucets (API: https://bryanlabs.net/faucets/api-docs) - CosmWasm console: https://bryanlabs.net/wasm - Open source: https://github.com/bryanlabs ## Tia, the site assistant Every page has an "Ask Tia" button: a voice or text conversation with Tia, BryanLabs' AI assistant (ElevenLabs agent, five minutes per conversation). She explains how the tools work and passes feature requests, problem reports, service questions and messages to Dan Bryan after screening them. She knows which page the visitor is on (and follows them as they move around the site without dropping the conversation), can open pages for them, and for signed-in visitors knows their first name and reporting country and keeps their conversation history on the account page. She can read live figures the site computes (scheduled upgrades, the latest snapshot per database backend, status, the faucet) and point to them on screen. For a signed-in visitor she can read that visitor's own faucet requests, what is new in their saved tax reports and their upgrade alerts, and fill in the Add webhook form for them to check and save; she never saves anything herself and never takes webhook URLs. She cannot look up an address or another account, and gives no tax advice. Agents should use this file and the APIs above instead; the Tia endpoints are rate limited and meant for people.