BRC-175: 1Sat Fungible Basket Profile

[GenericCPU]

Summary

Adds BRC-175: fungible 1Sat tokens as 1-sat tips sharing one origin, each with face-value amt (balance = Σ amt).

• Storage basket 1sat-ft (separate from NFT 1sat)
• Transfers spend tips and create payee (+ change) 1-sat tips with conserved amt; imports BRC-150 provenance
• Locked supply optional (supply + max on origin); omit when uncapped
• Mint-batch attestation for same-tx genesis siblings; missing amt ⇒ 1 (legacy)
• Chain scan / basket separation: bare 1-sat tip moves are shared with BRC-147; MUST NOT auto-file into 1sat on “spent a 1-sat parent” alone; FT lineage (application/1sat-ft+json) MUST NOT paint as NFT. Documents old-client misfile / burn risk. Cross-note added on BRC-147 Compatibility / Security.

Number: 175 (was briefly drafted as 166; 175 is free on upstream).

Implemented in HandCash wallet for hold/send/receive; mint via BRC-100 / Mint Studio.

Test plan

• Spec review (David / 1Sat maintainers especially welcome on amt conservation + optional lock)
• Confirm basket name 1sat-ft is acceptable
• Confirm number 175 is still free at merge time
• Review bare-transfer coexistence with BRC-147 ingest heuristics

[ty-everett]

Is this stuff using the BRC98/99 semantics like BTMS does, at the wallet layer?

Or is this operating above that and just reserving the basket name for the application layer?

[GenericCPU]

Wallet layer. 1sat-ft is a BRC-98/99 basket via BRC-100 createAction/listOutputs, same filing primitive BTMS uses, not an overlay token protocol. The 175 rules (origin, amt, 1-sat tips) sit on top of that basket. We’re reserving the name so wallets don’t file these into 1sat.

[shruggr]

I’m stuck on amt after a split — want to make sure I’m reading it right.

Genesis tip amt=1000. Spend it, two 1-sat outputs, remittance says 400 and 600.

1. Where is 400 committed so the receiver of that output can verify it without trusting the sender? Bare P2PKH has no amount in script, and BRC-150 only proves tip→origin.
2. If the check is conservation on the action, that receiver doesn’t have the 600 remittance. What stops the sender from attaching amt=1000 to both outputs?
3. The extra 1-sat is not the ordinal child of the genesis sat. Besides remittance, what makes it a unit of this token?

[raspi-user]

I reviewed BRC-175. I like the goal of giving wallets a shared 1sat-ft basket for fungible 1Sat-style holdings, but I do not think this is merge-ready yet.

The main blocker is that amt is not independently bound to the new carrier outputs. BRC-150/BRC-159 can prove continuity of a physical sat, but this proposal explicitly allows splitting one fungible tip into multiple newly funded 1-sat carrier outputs. Those extra carrier sats are not ordinal descendants of the origin sat. So unless the full transfer state is committed somewhere verifiable, a receiver cannot independently know whether their output has 400, 600, or whether the sender has claimed 1000 to multiple recipients.

I think the spec needs a deterministic transfer commitment model before merge: either an on-chain manifest, a signed action-level remittance, or another canonical structure that binds all input tips, all output tips, their amt values, and the conservation equation. Each recipient must be able to verify their own received tip without trusting the sender's private per-output metadata.

There are also secondary issues to tighten:

1. Open-supply semantics need to be made coherent. The draft says unlocked/open supply has no cap, but also says mint.extend is not binding and new tips still need genesis, mint-batch, BRC-150, or a proven parent hop. That makes post-genesis issuance unclear or impossible.

2. Mint-batch amt values need independent verification. If sibling amt values live only in remittance and are not committed on-chain, a receiver cannot verify the batch total against max without trusting supplied metadata.

3. BRC-150 extension to 1sat-ft should be explicit. BRC-150 currently defines provenance for basket 1sat; this PR says 1sat-ft wallets must accept it unchanged. That probably needs either a BRC-150 erratum in the same PR or precise compatibility language.

4. amt / max integer canonicalization is missing. Please define JSON type, no-leading-zero rules, maximum supported size, parser failure behaviour, and whether 0, negative values, decimals, exponent notation, or oversized values are invalid.

5. The origin content type should be normative. BRC-147 now references application/1sat-ft+json, but BRC-175 does not clearly require that content type for the origin envelope.

6. Conformance vectors should cover the failure cases. This proposal needs machine-readable examples for genesis, locked mint, split, merge, invalid double-claim, missing sibling remittance, parent-hop failure, open-mint rejection, and old-client misfile cases.

Overall: promising direction, but the current draft's fungibility depends too heavily on uncommitted remittance data. The transfer/conservation proof needs to be as deterministic as the basket naming before this becomes a BRC.