Skip to content

feat: show verified-build status from Stellar Expert on contract detail page - #57

Merged
pselle merged 5 commits into
mainfrom
feat/verified-build-status
Sep 4, 2026
Merged

feat: show verified-build status from Stellar Expert on contract detail page#57
pselle merged 5 commits into
mainfrom
feat/verified-build-status

Conversation

@pselle

@pselle pselle commented Aug 31, 2026

Copy link
Copy Markdown
Contributor

From roadmap deliverable D5:

...verified-build status from Stellar Expert on contract detail pages.

If the contract is verified, the contract detail page shows a "Verified Build" badge.

Demo video. Shows a Contract with the "Verified Build" badge and working sidebar links, as well as a contract without this information lacking such a badge/link.

verified-build-demo.mov

Depends on stellar-registry/indexer#46 first

pselle and others added 3 commits August 31, 2026 10:42
…il page

Fetches api.stellar.expert's per-contract validation status server-side
in the contractDetails loader (that API sends no CORS headers, so it
can't be called from the browser) and, when Stellar Expert has an
attested build for the contract, shows a "Verified Build" badge plus a
sidebar link to the verified source at that commit. Absent/unverified/
errored lookups render nothing extra, matching the existing convention
of hiding empty fields (e.g. the null-deployer fix in #32).

Extracts the public/testnet URL-segment mapping root.tsx already did
inline for stellarExpertUrl into lib/network.ts so both call sites share
it.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V1fF2DvpYam3mg2R6oTqpG
@pselle
pselle requested a review from chadoh August 31, 2026 17:23

@chadoh chadoh left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't love that we are doing this over-and-over-and-over again on every request, given that we are fetching information about a given contract ID that will never change. I also don't like that call needs to be done serially after fetching the contract from our own API. This makes our latency at least as bad as Stellar Expert's latency.

In stellar-registry/indexer#32, we added Wasm parsing to our indexer, using a Webhook that we wired Goldsky to hit every time a Wasm is published to the Registry. We could do the same thing for contracts every time a contract ID is registered. This would be a natural place to fetch Stellar Expert info exactly one time per contract ID. It would also allow us to set corresponding "verified" data on the Wasm associated with each contract ID, if that Wasm is itself registered.

Added benefit of doing it via indexer/server: we also solve the problem of how to show verified sources on our Wasm pages, given that Stellar Expert doesn't itself have a concept of a Wasm.

@chadoh

chadoh commented Sep 1, 2026

Copy link
Copy Markdown
Member

That said, this technically works and allows us to check off the milestone. If you want to make a "stretch goal" issue for the indexer work and come back later, I'd be ok with that.

@pselle

pselle commented Sep 2, 2026

Copy link
Copy Markdown
Contributor Author

Thanks for this comment! Agree that this would be better to move to an indexer flow. I'll work on that over in the indexer repo, and return to this once the data side is pushed, reviewed, and deployed.

In an outside chat, we also discussed that this verified build status would be desirable on wasm pages as well -- for the first pass, I'll be adding the data to contract API endpoints, and then work on adding it to wasm endpoints.

Converting this PR to draft for now, will mark ready to review when there are new updates on the UI side.

@pselle
pselle marked this pull request as draft September 2, 2026 12:42
pselle added a commit to stellar-registry/indexer that referenced this pull request Sep 2, 2026
Add a webhook based off of the 'register' event that will get data from
Stellar Expert on a contract Wasm's "verified" status.

This will allow us to update our database efficiently in the indexing
process, and not have to hit the Stellar Expert API often in the front
end for data that won't change.

Related to stellar-registry/ui#57, to make this
data available for the UI to consume

---------

Co-authored-by: Chad Ostrowski <221614+chadoh@users.noreply.github.com>
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
pselle and others added 2 commits September 3, 2026 11:20
The indexer now fetches and caches Stellar Expert's verified-build
attestation once per contract_id (stellar-registry/indexer#40), wired
up via the same webhook pattern as wasm-details, and returns it as
`verified` on the contract detail response. Drop the per-request
client-side call to api.stellar.expert from the contract detail
loader and read contract.verified instead — addresses the review
feedback on this PR (serial extra fetch on every page load, latency
tied to Stellar Expert's own).

Wasm pages don't carry verified-build info yet; that's a follow-up
once the indexer exposes it on wasm endpoints too.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KSCRzm3HAm3sAkkPYEtfA8
@pselle
pselle force-pushed the feat/verified-build-status branch from dab97ea to 6f77aa1 Compare September 4, 2026 00:20
@pselle
pselle marked this pull request as ready for review September 4, 2026 00:24
@pselle
pselle requested a review from chadoh September 4, 2026 12:41

@chadoh chadoh left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💐

@pselle
pselle merged commit 63b3032 into main Sep 4, 2026
3 checks passed
@pselle
pselle deleted the feat/verified-build-status branch September 4, 2026 16:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants