1Sat Ordinals Basket Profile for BRC-46 / BRC-100

Abstract

This BRC defines the application basket profile for 1Sat Ordinals under BRC-46 / BRC-100. It reserves the basket name 1sat, specifies eligibility of outputs placed in that basket, documents the tag vocabulary and BRC-37 customInstructions schema used for display and remittance, and describes normative hold / list / transfer / import flows via existing wallet interface methods.

It does not redefine 1Sat Ordinals origin theory. Offline tip→origin proof is specified in the companion BRC-150.

Motivation

BRC-37 deliberately leaves customInstructions semantics to the named basket. BRC-46 enables token-like tracking in baskets but does not define a 1Sat profile. Without a shared basket name and metadata contract, wallets cannot reliably:

1. Hold the same inscription UTXOs in a common basket.
2. List and filter collectables for apps and UI.
3. Transfer a 1-sat tip while preserving origin claims for the receiver.
4. Import historical ordinals via internalizeAction with interoperable remittance.

Existing deployments (including HandCash Desktop) already use basket 1sat with overlapping tags and JSON instructions. This BRC records that convention so independent wallets can interoperate without trusting a single vendor.

Specification

Basket identifier

• The basket name is the UTF-8 string 1sat.
• Per BRC-46, wallet implementations normalize basket identifiers by trimming whitespace and lowercasing. After normalization, conforming use of this profile MUST use exactly 1sat.
• This identifier does not use the BRC-99 reserved p prefix. It is a standard application basket under BRC-46 permissioning (grant / deny access to the basket as a whole, unless a future p -scheme supersedes that for assets).

Eligibility

An output SHOULD be placed in basket 1sat only when all of the following hold:

1. satoshis === 1.
2. The output is intended as a 1Sat Ordinals tip (a 1-satoshi UTXO in an inscription ownership chain), per 1Sat Ordinals.
3. The sender or importer reasonably believes the tip belongs to a 1Sat origin (the first 1-sat outpoint carrying a valid first ord envelope on that sat).

Wallets MUST NOT place ordinary payment change or multi-sat outputs into 1sat merely to attach ordinal-looking tags.

Outputs that fail eligibility MAY still appear if a buggy sender used the basket; receivers SHOULD treat such outputs as malformed for this profile and MUST NOT present them as verified inscriptions solely because of basket membership.

Outpoint encoding

• BRC-100 wire outpoint fields use dot form: txid.vout (see BRC-100 / BRC-36 practice).
• 1Sat Ordinals / OrdFS commonly use underscore form: txid_vout.
• Conforming implementations MUST treat txid.vout and txid_vout as the same outpoint when txid is 64 hex chars and vout is a non-negative decimal integer.
• Inside this profile’s customInstructions object, origin SHOULD use underscore form for consistency with 1Sat indexers. Tags MAY use either form after the origin: prefix; readers MUST normalize before comparison.

Tags

Tags are optional BRC-46 / BRC-100 output tags used for filtering and display hints. They are non-authoritative for asset identity.

Unknown tags MUST be preserved when transporting the output (BRC-37 / BRC-46 spirit). Tag query via listOutputs uses existing tags / tagQueryMode fields.

Custom instructions (BRC-37)

When present for basket 1sat, customInstructions MUST be a UTF-8 JSON object serialized as a string (matching BRC-37 examples). Conforming writers SHOULD emit:

{
  "origin": "<txid_vout>",
  "name": "<display name>",
  "app": "<optional creator/app id>",
  "provenance": { }
}

Additional JSON keys are permitted and MUST be ignored by readers that do not understand them. Readers that do not understand provenance MUST still store and forward the entire string unchanged (BRC-37).

Claims vs proof

• origin, name, app, and all tags are claims.
• A wallet MUST NOT treat a claimed origin as proven solely because it appears in tags or customInstructions.
• Proven tip→origin binding is defined by BRC-150. When that remittance is absent or fails verification, the wallet MUST treat identity as unproven and SHOULD avoid presenting sender-supplied name / app as authoritative for that tip.

Hold and list

Applications list held tips with BRC-100 listOutputs:

{
  "basket": "1sat",
  "includeTags": true,
  "includeCustomInstructions": true
}

Optional tags / tagQueryMode filters apply as in BRC-46. Wallets MAY require basket permission per BRC-46 / BRC-100 before returning outputs.

Transfer (send)

A conforming transfer of a held 1sat tip SHOULD use BRC-100 createAction with:

1. An input spending the current tip outpoint (satoshis === 1).
2. An output with satoshis: 1, basket: "1sat", tags per this profile, and customInstructions as above.
3. Prefer supplying inputBEEF / AtomicBEEF for the spent tip when available (BRC-62, BRC-95) so the new owner can validate the spend graph.
4. Action labels MAY include 1sat for activity filtering; labels are non-normative for asset identity.

Example (non-normative shape):

{
  "description": "Send Collectable",
  "labels": ["1sat"],
  "inputs": [{ "outpoint": "<tip txid.vout>", "inputDescription": "1sat collectable" }],
  "outputs": [{
    "lockingScript": "<recipient P2PKH or other 1-sat lock>",
    "satoshis": 1,
    "outputDescription": "Collectable transfer",
    "basket": "1sat",
    "tags": ["ordinal", "origin:<txid.vout>", "name:Example"],
    "customInstructions": "{\"origin\":\"<txid_vout>\",\"name\":\"Example\",\"provenance\":{}}"
  }]
}

Senders SHOULD attach BRC-150 provenance remittance when they can build a valid package. Senders that cannot prove origin MUST NOT present the transfer as a verified inscription transfer; they MAY still move the 1-sat UTXO, but receivers will treat identity as unproven.

Import / receive (internalizeAction)

To place an existing tip into basket 1sat, use BRC-100 internalizeAction with protocol basket insertion (BRC-46):

{
  "tx": "<AtomicBEEF bytes for the tip transaction>",
  "description": "Import 1Sat ordinal",
  "labels": ["1sat"],
  "outputs": [{
    "outputIndex": 0,
    "protocol": "basket insertion",
    "insertionRemittance": {
      "basket": "1sat",
      "tags": ["ordinal", "origin:<txid.vout>"],
      "customInstructions": "{\"origin\":\"<txid_vout>\",\"name\":\"Example\"}"
    }
  }]
}

insertionRemittance.customInstructions follows the same schema as transfer. Provenance MAY be omitted on import when the importer verifies origin by other means before insertion; once transferred onward, senders SHOULD attach provenance for the new tip.

Payment separation (wallet policy guidance)

Spending or revealing 1sat basket outputs is not a BRC-29 / default-basket payment. Conforming wallets SHOULD:

• Require distinct user authorization (or a dedicated item/basket grant) before createAction / relinquishOutput that spends 1sat outputs.
• Not treat a general “pay” or auto-pay grant as authorization to spend 1sat tips.
• Not fund ordinary payment outputs from 1sat basket UTXOs.

Normative fine-grained asset permission schemes remain BRC-99 territory and are out of scope for this profile.

Compatibility

• Wallets that do not implement this profile MUST still store and forward unknown baskets’ customInstructions and tags unchanged (BRC-37).
• This profile does not conflict with BRC-99 p baskets; future permission-wrapped variants MAY wrap 1sat semantics under a p <scheme> … name without invalidating this profile for the plain 1sat basket.
• Marketplaces (e.g. OrdLock), BSV-20/21, and mint APIs are out of scope.

Security considerations

• Tag / metadata spoofing — Without provenance verification, a sender can attach another inscription’s origin and name. See BRC-150.
• Basket pollution — Placing non-1-sat or non-ordinal outputs in 1sat confuses list UIs; receivers should re-check satoshis and inscription rules.
• Burn — Per 1Sat Ordinals, packing a sat into a multi-sat output ends that origin trail. Do not continue origin: claims across a burn.
• Indexer trust — Display media URLs and collection metadata often come from indexers; this profile does not make indexers authoritative for tip→origin binding.

Implementations

• HandCash Desktop (reference): basket 1sat list / send / import; tags and customInstructions as above; payment grants never cover item spends.
  Source: src/wallet/collectables.ts, src/wallet/oneSatImport.ts, src/wallet/itemAccess.ts in HandCash/HANDCASH-DESKTOP.

References

1. 1Sat Ordinals — https://docs.1satordinals.com
2. BRC-37 — Basket and Custom Instructions Extension for Bitcoin Outpoints
3. BRC-45 — Outputs are Tokens
4. BRC-46 — Wallet Transaction Output Tracking (Output Baskets)
5. BRC-62 — BEEF Transactions
6. BRC-95 — Atomic BEEF Transactions
7. BRC-99 — P Baskets (reserved permission schemes)
8. BRC-100 — Unified Open BSV Wallet-to-Application Interface
9. BRC-150 — 1Sat Provenance Remittance for Basket 1sat