Core Talks Through A Covenant Source Registry

Two days after Toccata activation, the R&D channel turned to a wallet and explorer problem that always appears once arbitrary scripts become real: how does software understand a public covenant it has never seen before?

On July 2, IzioDev said he and saefstroem had discussed a core-provided service for understanding any public or published covenant. The motivation was already visible in the wild. "I start to see people creating covenant-specific SDK, which is solvable uniformly," he wrote. ^{[1] [2]}

Sutton immediately grounded the design in covenant ID preimage mechanics. The registry should be fed with the information required for a genesis launch proof through the covenant id preimage. In his words, the entity registering provides the needed material, and "the covenant id preimage was designed exactly for this." ^{[3] [4]}

The scope did not stop at Silverscript source. Max asked whether custom scripts outside Silverscript could register if the registrant already knew covenant id and offsets. saefstroem answered that the surface should cover all P2SH redeem scripts, not only Silverscript source, but registration should require a live P2SH UTXO with non-zero value. Sutton agreed those non-Silverscript paths are harder to audit, while saying they should still be supported. ^{[5] [6] [7] [8] [9]}

Hosting and trust were the real fight. saefstroem said the idea should live under some subdomain of kaspa.org. Arthur supported a registry-like surface because templates and verifier circuits will be reused, but warned that a single central kaspa.org registry can be misread as "kaspa.org says this covenant is safe." That reading, he said, creates centralized audit pressure. ^{[10] [11] [12]}

IzioDev said he had pressed the same concern with saefstroem. The answer he relayed was the Etherscan analogy: source verification is not an audit seal, and verified source can still be a scam. Arthur then argued the opposite failure mode. A fully decentralized registry can make malicious or low-quality entries easier to spread. His compromise was explicit levels: unverified, provenance-verified, community-reviewed, externally-audited, and similar tiers. ^{[13] [14] [15]}

saefstroem sketched an operational middle path. Protocols could submit third-party audits the way Etherscan listings do, then a small set of core reviewers would assert audit legitimacy without pretending the registry itself is a full security guarantee. Arthur pointed at crates.io as another model: publication is not endorsement, while separate signals such as advisory tabs and dependency reports create additional trust surfaces for downstream wallets. ^{[16] [17] [18]}

The useful claim is modest. Nobody announced a finished kaspa.org registry product in that thread. What they did was define the product boundary correctly: a provenance and metadata surface for public covenants, keyed off covenant id preimage data, open to redeem scripts beyond Silverscript, and careful not to confuse source publication with safety certification.

All sources link to public messages in the Kaspa Core R&D (public) Telegram channel.