IP-Liquidator / Garcia Sounds

A technical whitepaper

• Version: 1.0
• Date: 2026-09-18
• Author: Anika Inc
• Status: Working system. This paper describes what exists, what is advisory, and what is not yet built.

Abstract

IP-Liquidator is a web application for registering intellectual-property assets, tracking their pledged value against acquisition goals, and recording on-chain tokenizations of those assets on the Base network (chain ID 8453). It consists of three components:

1. Garcia Sounds — a static web application (Firebase Authentication + Cloud Firestore) implementing a six-stage lifecycle: leads, valuation, vault registration, pledging, tokenization records, and an append-only transaction ledger.
2. A valuation engine — a formula-based appraisal reference (Node) with a browser port used strictly as an advisory suggestion tool. Owner-entered values are always stored and displayed as self-reported; the engine never overrides them.
3. GSMC2 — an ERC-1155 smart contract (Solidity ^0.8.24) for fractional royalty units, one token ID per registered asset, with allowlist-gated transfers and an on-chain encumbrance mechanism that mirrors the application's pledge ledger.

The application moves no money, extends no credit, and creates no legal liens. It is a tracking and record-keeping tool — not legal, financial, or tax advice. GSMC2 has been tested on a disposable local chain only; it is not deployed to Base mainnet.

1. Problem

Owners of intellectual property — music catalogs, software, crypto holdings, patents — commonly lack a single place to:

• Register what they own, with an explicit statement of who assigned the value and how.
• Track how much of an asset's registered value has been pledged toward obligations, so the same collateral is not committed twice.
• Record the on-chain representation of those assets (token IDs, transaction hashes) alongside the off-chain records.

Existing tools either hide their valuation assumptions, silently accept owner numbers as if they were appraisals, or combine tracking with custody of funds. IP-Liquidator separates these concerns: the app tracks and enforces pledge limits in its database; any on-chain action happens in the owner's own wallet, outside the app.

2. System architecture

The system implements a six-stage asset lifecycle:

Leads → Valued → Vault → Pledged → Tokenized → Recorded

Stage 1 — Leads (intake pipeline)

garcia-sounds/leads.html implements a native Firestore-backed intake pipeline with stages:

New → Under Review → Valued → Tokenized → Closed

Each lead carries per-lead valuations, and every stage transition is written to a write-once audit log that records the acting user's signed-in Google account email. A lead at the Valued stage can be promoted directly into the IP Vault as a registered asset.

Stage 2 — Valued (valuation recorded)

A valuation is recorded on the lead or asset using one of five input paths: trailing royalties, stream counts, recurring revenue, a live crypto spot price, or the owner's own estimate. An optional in-form Appraise helper suggests a value computed from the reference formulas (Section 5). The owner may accept, edit, or ignore the suggestion. What is saved is always tagged with its source.

Stage 3 — Vault (asset registration)

garcia-sounds/vault.html registers assets — music, apps/software, crypto, patents, and other IP — as collateral records. Assets may be promoted from leads or registered directly. Every value in the vault is stored with valueSource: "self-reported" and displayed with a self-reported tag, regardless of which input path produced it.

Stage 4 — Pledged (collateral allocation)

garcia-sounds/acquire.html lets the owner create acquisition goals and pledge registered assets toward them. The double-pledge guard (pledgeToGoal in js/store.js) runs inside a Firestore transaction: an asset's total pledged value across all goals can never exceed its registered value. The check is atomic against the database, so a hand-edited form or a second browser tab cannot bypass it. The reference engine enforces the same invariant off-chain (Section 6).

Stage 5 — Tokenized (on-chain record)

garcia-sounds/tokenization.html plus contracts/GSMC2.sol. The application itself never mints: it has no wallet connection and no blockchain RPC access. The owner mints a GSMC2 ERC-1155 token ID per asset in their own wallet on Base, then records the token ID and transaction hash in the app. The tokenization page links to basescan.org so any recorded hash can be verified independently. The contract's encumber/release functions mirror the application's pledge ledger on-chain (Section 7).

Stage 6 — Recorded (transaction ledger)

garcia-sounds/transactions.html. Every vault registration, pledge, tokenization, and goal event is written to a Firestore transactions collection. The security rules deny updates to this collection (allow update: if false), making the ledger append-only. Entries can be exported as CSV.

3. Data model and per-account isolation

The application is a static ES-module site (no build step) deployed to Netlify, backed by Firebase Authentication (Google sign-in) and Cloud Firestore.

Collections (all under users/{uid}/...)

There are no cross-account or public collections. No platform-wide aggregates exist in this build.

Enforcement, not convention

Per-account isolation is enforced by firestore.rules, not by application code alone:

• A signed-in user can read or write only their own users/{uid} subtree.
• Writes are restricted to the seven known collections; there is no catch-all match, so any future collection added without a rule update is denied by default.
• Each collection validates document shape (required fields present with correct types; numeric values non-negative).
• transactions denies updates entirely; auditLogs is write-once.
• catalogTracks explicitly permits estValue: null, representing the "Unvalued" state — tracks imported without prices are not assigned invented values.

Deployment security

netlify.toml sets response headers including Strict-Transport-Security, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy, Permissions-Policy, and a Content Security Policy restricting scripts to self and gstatic.com, connections to Google/Firestore/Identity endpoints, and frames to accounts.google.com (Google sign-in) with frame-ancestors 'none'.

4. Valuation methodology

The valuation engine exists in two forms: a Node reference implementation (workspace/ip-liquidator/valuation.js, zero dependencies, with a pressure-test suite in test.js) and a browser port (garcia-sounds/js/valuation.js) used only as the advisory Appraise helper. Both implement the same formulas.

Formulas

These multiples are exposed as tunables in the reference code. They are ordinary industry rule-of-thumb ranges, not certified appraisals. The paper states this plainly because it is true: the engine computes arithmetic on inputs; it does not appraise.

Maximum loan-to-value, per asset class

The advertised platform maximum is 40% LTV. Worked example from the test suite: 13 music masters valued at $325,000 support up to $130,000 of credit at the 40% music cap.

Advisory-only design and self-reported labeling

The in-app engine is suggestion-only:

1. The Appraise button computes a formula value from the inputs on the form.
2. The owner may accept it, edit it, or ignore it entirely.
3. Whatever is saved is stored with valueSource: "self-reported" and rendered with a SELF-REPORTED tag.

The engine's code contains no Firestore write calls — it cannot persist anything on its own. It never overrides an owner-entered value and never presents an owner number as formula-derived. The reference implementation's own documentation states the rule: self-reported values are labeled everywhere they appear; the engine will not launder an owner's number into looking like a formula produced it.

This labeling is a core integrity feature, not a cosmetic one. Any downstream consumer of vault data — a pledge calculation, a token issuance record, a CSV export — can see exactly which values came from formulas and which came from the owner.

5. Pledge and encumbrance mechanics

Two layers enforce the same invariant: one unit of collateral value backs at most one obligation.

Application layer (authoritative for the UI)

pledgeToGoal(goalId, assetId, amount) in js/store.js:

1. Opens a Firestore transaction.
2. Reads the asset's registered estValue and the sum of its existing pledges across all goals.
3. Rejects the write if existing pledges + new amount > estValue.
4. On success, appends the pledge and writes a ledger entry.

Because the check executes inside the transaction against current database state, concurrent tabs or hand-edited client forms cannot over-pledge. The UI additionally shows per-asset available amounts and clamps the pledge input, but the transaction is the enforcement point.

Reference engine layer

createVault() in valuation.js maintains an in-memory encumbrance ledger: registerAsset, pledge, and release operations, with pledge throwing when the requested amount exceeds unencumbered credit (maxCreditUsd − encumberedUsd). The ledger is append-only; entries are never edited or deleted. A verified test case: after pledging $100,000 against a vault, a $50,000 token-backing attempt is rejected because only $28,000 of credit remains unencumbered.

On-chain layer

The GSMC2 contract's encumber/release functions (Section 6) provide the same guard for token units: encumbered units cannot be transferred until released.

6. Tokenization design — GSMC2

GSMC2 ("Garcia Sounds Coin 2") is an ERC-1155 fractional royalty-unit contract:

• Standard: Solidity ^0.8.24, OpenZeppelin ERC1155 + Ownable.
• Supply: 10,000 units per issuance (ticker GSMC2).
• One token ID per registered asset. issue(supply, valuationUsd, proofURI) mints the full supply to the contract owner and stores a valuation snapshot, a proof URI (IPFS or metadata identifying the underlying IP), and an encumbrance counter. Empty proof URIs are rejected; over-encumbrance is rejected.
• Private placement by construction. Transfers are allowlist-gated: secondary transfers require both sender and receiver to be allowlisted, enforced in the _update hook. Non-allowlisted transfers revert.
• Encumbrance. encumber(id, amount, label) locks units as loan backing; release(id, amount, label) unlocks them. Encumbered owner units cannot move until released. Events (Issued, Encumbered, Released, AllowlistSet) provide an on-chain audit trail mirroring the application's pledge ledger.
• Metadata. uri(id) returns the stored proof URI for the token ID.

The app records; the owner mints

This separation is deliberate and is restated here because it is the most commonly misunderstood point: the Garcia Sounds application has no wallet connection, no private keys, and no blockchain RPC access. It cannot mint, transfer, or encumber tokens. The Tokenization page is a form for recording the token ID and transaction hash of a mint the owner performed themselves, in their own wallet, on Base. The page links to basescan.org so each recorded hash is independently verifiable. The application itself has no way to confirm a hash — it records what the owner attests.

Deployment status

GSMC2 compiled cleanly with solc (8,258 bytes of bytecode, 38 ABI entries) and passed a six-check end-to-end suite on a disposable local chain (chain ID 31337): issuance, encumbrance, blocked over-transfer, allowlisted transfer, release, and blocked outsider transfer. It is not deployed to Base mainnet. Deployment requires the vault owner's explicit wallet signature — via a wallet-signing flow (MetaMask or Coinbase Wallet), never by transmitting a private key. The repository includes a WALLET_DEPLOY_CHECKLIST.md (network: Base 8453; owner address; proof URI; valuation; supply; gas estimate; explicit signature step). The script-based deploy path uses a DEPLOYER_KEY environment variable on the owner's own machine only.

7. Music catalog

The application ships with a real catalog: 12 uploaded audio files were measured and deduplicated to 6 unique tracks (files sharing a title and identical duration are the same recording in different container formats):

The seed script (catalog/seed-tracks.mjs) writes one catalogTracks document per track — title, filename, duration, format, source "audio-upload" — with estValue: null. No values are invented. The owner prices every track on the Catalog page; until then, tracks display as "Unvalued" and are excluded from collateral totals. The script is idempotent (skips filenames already present) and runs with the owner's own Firebase service-account key, which never leaves their machine.

8. Security and trust model

Known limits: the pledge guard is enforced in application code against Firestore, not in security rules themselves — a compromised client SDK session could still write directly, which is why rules additionally validate document shape. The application cannot verify tokenization hashes; it links to basescan.org for independent verification.

9. Real vs. recorded — the complete table

10. Roadmap and open items

1. Base mainnet deployment of GSMC2 — pending the vault owner's explicit wallet signature. No private keys are requested, transmitted, or stored.
2. Wallet-signed deploy page — a mobile/browser flow where MetaMask or Coinbase Wallet signs the deployment transaction directly, replacing the script-based DEPLOYER_KEY path.
3. Lovable project reconciliation — the hosted "IP Powerhouse" project's recent changes have not been inspected against this build; the two implementations need a diff and a decision on which is canonical.
4. Live pressure test — the js/ data layer was authored to complete the uploaded HTML shells; it needs testing against a real Firebase project (auth flow, pledge guard under concurrency, rules publish) before it is trusted with real records.
5. Shared/admin views — per-account isolation is deliberate. Any cross-account or aggregate view is a separate, explicit feature, not an implied one.

11. Language standard

This paper, like the build it describes, uses technology information only. Anything not implemented is labeled roadmap, never implied as live.

The following categories of language are not used in this project's copy, docs, or UI:

• Banking/charter claims — no NCUA, CDFI, credit-union charter, or chartered-institution claims of any kind.
• UCC filing language — no UCC filings claimed, referenced, or implied as executed.
• Sovereign / nation-like / governmental-authority framing — this is software built by Leonard / Anika Inc, not a jurisdiction, government, or authority.
• Institutional partnership claims — no banks, payment networks, or institutions presented as partners or live integrations. References to Base mean the public blockchain network (chain ID 8453), not a partnership.
• Property deeds/titles as executed instruments — ownership records are owner-entered tracking entries, not executed legal instruments.
• Cooperative-as-existing-entity framing — no cooperative is presented as formed or operating.

If a future feature touches any of these domains, it ships as an explicit roadmap item only after answering: what technology exists today, and what is only planned? Copy is corrected to match the answer, not the aspiration.

12. What this paper does not claim

• That any valuation in the system is a certified appraisal. Formula outputs are arithmetic on owner-supplied inputs; owner estimates are labeled as such.
• That the application mints tokens, moves funds, extends credit, or creates enforceable claims. It does none of these.
• That GSMC2 is deployed, trading, or available. It is tested locally and undeployed.
• That any external institution, network operator, or authority endorses, partners with, or charters this project.
• That the music catalog values exist. They do not — the owner sets every one.

End of whitepaper v1.0 — 2026-09-18.