ISRC, title, artist, rights owner and source system.
ACC MVP / music only
Operate catalog certification
Ledger
Bulk catalog certification simulator
Model how ACC processes an evergreen catalog: metadata and audio enter once, certificates are issued in batches, ledger events are created, and batch roots are anchored to the blockchain layer.
BETA note: ACC Core creates real ledger events, calculates a deterministic batch root and stores an OpenTimestamps-ready proof object in R2. Bitcoin confirmation is shown only after a real attestation exists.
ACC Core
Live anchor engine
{
"jobType": "acc.core.anchor",
"liveCertificatesIssued": 0,
"liveCertificatesBatched": 0,
"liveLedgerEvents": 0,
"anchorBatches": 0,
"latestBatch": "none",
"latestRoot": "pending",
"latestBatchStatus": "Ready for first batch",
"otsStatus": "Not batched yet",
"automation": "private ops cycle runs outside the public UI"
}Anchor batches
Blockchain proof queue
No live anchor batch yet. Issue one or more real ACC certificates, then run anchor batch.
Ledger events
Recent hash-chain events
No live ledger events yet. Real events appear after ACC Core certificate issuance.
Information flow
Where data enters, where proof exits
Files or existing asset hashes enter the ACC intake queue.
HUMAN, SEMI-MIX or AI GEN declaration is bound to each work.
ACC ID, audio hash, declaration hash and status are created.
Certificate events are grouped into a ledger batch root.
The batch root is anchored externally for timestamped integrity.
Partners read certificates, ISRC lookup and verification state.
Each work receives a public verification URL and market signal.
- Catalog CSV / DDEX feed
- Audio files or asset hashes
- Creator or label declarations
- Tamper-evident batch root
- Timestamped anchor
- Hash continuity across ledger events
- Public certificate URLs
- Partner API records
- Blockchain anchor receipts