The SEP only aims to draft the API structure, mostly focusing on the response. Implementation details is up to submissions.

Fwiw, we're already talking to people submitting proposals and it was mentioned that the API design would be SEP-based, and they were welcome to give feedback and help design the best solution possible. The problem is constrained in nature (exposing findings), so final solutions wouldn't deviate completely from the SEP proposal anyway.

It's worth mentioning the SEP doesn't talk anything about the verification process itself (infrascture, data persistance, etc); only attempts to normalize how they will be exposed to consumers.

FYI I am one of the RFP proposer and with Aha we are also making a proposal to address it (in collaboration with another team.)

The RFP is ambiguous on the term API. Here you assumed REST API and are already making design choices with verification semantics. In the delegate discussions I personally pushed that a SEP could/should be one of the deliverables and here as well we have some ambiguity on the verifier API SEP.

The REST API is our requirement because we want to simplify interfaces like the Lab. That said, it doesn't void any other response implementations, just documents the one we care about.

This SEP is up for discussion to avoid making the wrong assumptions. Help us think this through and we'll update it with something that works better. This is not set in stone.

As long as this does not get merged before the RFP itself quicks off I am personally fine.

Because in practice I don't thinks it's that easy to adjust a SEP even if still in draft and discussions tend to stop.

(I will try to make some feedback in case but I am writing this while on a leave. I was afraid of being too late to raise my voice if I did not do it now.)

Hello Tupui, Our team created this for this RPF : https://stellar-contract-verification.vercel.app/ Does this seem like a step in the right direction? We could really use your feedback.

I spent quite some time on this before submitting a proposal. I actually managed to recreate about 200 of the on chain wasm.

You can see some of my comments around things needed to properly reproduce it https://github.com/orgs/stellar/discussions/1923#discussioncomment-17335218 and the next thread.

I was kind of surprised that there was not more attention to this issue in the other teams submitting RFPs. I did not see who won the process but hope they have a clear solution to this which is one of the two hard problems I see (the other is decentralized verifications - aggregation and trust levels)

Maybe the team working on this can share their solution?

Two hundred is a much bigger number than anything visible from the outside, and that gap is the thing I keep tripping over. Our census only counts published claims. The SDF experimental repos plus the StellarExpert API. By that measure exactly 1 wasm is rebuild-verified today. Your 200 recreations do not appear in either surface, so from any consumer's point of view they may as well not have happened. That seems worth stating plainly in this thread. The ecosystem's real verification coverage is already meaningfully higher than its recorded coverage, and nothing currently exists to close that distance. The rebuild work is being done and then lost.

On your two hard problems, I would put the same two on the list, and the second is the one I keep circling in this thread. If several verifiers with different trust models (rebuild match, attestation, a governance decision) each answer for the same wasm hash, someone has to record who claims what, where they agree or disagree, and what evidence survives after a results URL goes stale. Our sweep found the disjointness is not hypothetical: 105 wasms verified by StellarExpert's path, 1 by the rebuild flow, and zero overlap between those sets. Aggregation was scoped out of this SEP, which was probably right for the SEP, but it does leave the question without a home.

Not our RFP, we came at this from the consumer side, and what we have so far is measurement rather than a verifier. If it is useful I will happily write up the method and the numbers here, and I would be genuinely interested in how you drove those 200 rebuilds, since a documented path from an unlabelled wasm to a reproduced build is exactly what the retroactive population needs and would sharpen what we are measuring.

The 200 took much from Stellar expert but also doing lot of mapping from wasm to repo and then almost brute forcing the arguments to rebuild - looking at wasm tags and makefiles in the repo and such stuff.

I am sure more is possible with more patience and definitely a lot more is possible if devs from these deployed projects provide as much info as they can on how they built it.

When there is some official registry I can publish the work someday.

That method description is useful, and the last line is the part I keep thinking about. You have 200 rebuild results and nowhere to put them, which means the ecosystem's real verification coverage is sitting on someone's disk rather than anywhere a consumer can see it. That gap is a smaller problem to solve than the rebuilding itself.

We already run the census daily and keep the history, so the distance from that to a place where third-party rebuild results can be recorded is short: a record per wasm hash saying who rebuilt it, with what toolchain and arguments, what the result was, and a hash-anchored pointer to the evidence, so the claim survives after the workflow logs age out. Deliberately not a verifier and not a standard, just a durable place to put results that already exist, aligned with the SEP-58 vocabulary and this API's shape so it can be replaced by something official later without anyone losing their work.

Two questions, since you would be the first person publishing into it. What would you need such a record to capture for your 200 to be worth publishing rather than re-deriving, particularly around the build arguments you had to brute force? And would the mapping you built from wasm to repo be worth carrying as its own field, since that mapping is most of the work and is currently thrown away every time someone repeats it?

On your point about deployed projects publishing their build info. That is the same record from the other direction. If a place existed where a team could post how they built a contract, the retroactive population stops being a research problem for each verifier separately.

Chad here from The Aha Company / Stellar Registry team.

If a place existed where a team could post how they built a contract...

This is exactly what we proposed in our joint application for this RFP with @ethanfrey. The Stellar Registry would provide an obvious place for both:

1. Storing post-deploy updates to contract meta info
2. Storing source-verification data in a neutral, 3rd-party, on-chain location

Stellar Registry is live now. At its core it is public infrastructure: a smart contract. On top of that smart contract we've built various tooling: browse it at stellar.rgstry.xyz, publish to it with stellar-registry-cli, make cross-contract calls using the stellar_registry::import_contract! macro, and request your own (sub)registries or root-registry wasms/contracts by making a request in our governance repo (being upgraded to a Tansu DAO before long). That should give you an idea of its capabilities.

As indicated from our RFP submission, we think Source Verification is a great fit for Stellar Registry. We look forward to working with any teams implementing this standard.

What would you need such a record to capture for your 200 to be worth publishing rather than re-deriving, particularly around the build arguments you had to brute force? And would the mapping you built from wasm to repo be worth carrying as its own field, since that mapping is most of the work and is currently thrown away every time someone repeats it?

Ethan had enough ideas about this to create a separate SEP proposal: Contract Verification Attestations. I'd be curious to get his answers to your specific questions here.

I like the idea of having a field to indicate the source code that was used, not necessarily the one present on the wasm. verified_source_code_uri seems like a better name as it make it unambiguous.

Possible values could be:

https://example.com/archive.zip
ar://<address>
ftp://ftp.example.com/archive.zip
git+https://github.com/user/repo?rev=commit-hash
git+ssh://[email protected]/user/repo.git
svn+https://svn.example.com/repo?rev=1234

I think we can use vcs+url pattern to be to handle source_repo + source_rev in a single string.

Keeping all the information in a single field for how to get to the source will simplify a few things, even if it pushes some complexity onto clients.

Small note that it should be verified_source_code_url, l not i, because the intent is for the uri to be a location, not any type of identifier. Wdyt?

I like the idea of the git urls with rev as argument.

Do clients need to support all of those? I mean does anyone use svn for Soroban development?

I would make a subset for what is actually used and force all clients to support those, and make future SEP to support more if really needed. It shouldn’t be open ended.

My vote would be to support:

https
git+https
git+ssh
ipfs

For https and ipfs, you also need to specify the format. Tarball with gzip encoding? Tarball with bzip2? Normal zip archive?

Verifiers will need to have software that can run all of them so it should be a clearly scoped set of formats.

RFPs don't need to implement this API from day 1. We just want to get the conversation started so we think things through.

Putting my hat of RFP delegate. The team(s) selected to engage on this RFP is expected to interact with the community and SDF very closely throughout the years. I say years here as there is a strong expectation on maintainability and sustainability of what is developed. This is a valid remark for all RFPs. RFPs as it stands are similar to public goods: we want to build dependable infrastructure.

I said earlier I do think it's too early to have a PR up as we must all brainstorm together and that can only come from a clean slate. We are also breaking the process here as the PR for a SEP should only be proposed after a discussion period.

The PR can be be used for brainstorming. Don't like something? Make a suggestion, and if it fits, we can change. Case in point, https://github.com/orgs/stellar/discussions/1945#discussioncomment-17218331.

@fnando Part of the funding that teams are requesting is to dedicate proper working time to work on this topic. This is important because we, the delegates and SDF who green lighted the project, want to get the input from skilled teams. Most people only have a few hours there and there to dedicate to open source and volunteering work. Here it's about security and the topic is important enough considering the current supply chain context that we do things right.

If there is a reason to shortcut the process (which we are doing as per the instructions on how to raise a SEP), please raise this internally so that we are made aware of it on the delegate side.

In general, it would be good if you were to join the discussions we have with delegates on RFP. You would bring valuable input and perspective to the table.

I also want to note that many decisions need to go hand-in-hand with some implementation and real-world testing before they are finalized.

I just submitted stellar/stellar-cli-docker#23 which brings up a very non-obvious issue that only shows up when I am trying to build docker images to verify existing mainnet contracts.

I think this is a very important conversation to have and should definitely have multiple parties with time involved in it (stellar core devs, anyone working on the contract verification RFP, and teams working on explorers)

Given this seems to address the aggregation aspect of the proposal, I've decided to withdraw that use case for now. We can amend the initial proposal or draft a new one if we come to the conclusion that this is indeed required.

I'll update the pr, removing the aggregation aspect. If we come to the conclusion that something like this is required, then we can draft a separate SEP or amend the initial one.

Would it still be useful to keep verification as a list? I don't see a reason for it, now.

@jia57b thanks for you comment!

My deliberate stance is that this endpoint answers one narrow question: is this wasm reproduced from its source, by whom, with what verdict. The richer, verifier-specific detail lives on the verifier's own service, reachable from a report link. The shape also evolves additively (new optional fields, new sibling arrays, open enumerations), so deferring detail now costs nothing later. That "no breaking change required to add it" property is the spine of most of what follows.

2. unverified reason

I'm keeping status as verified | mismatched | unverified with no reason field for now. A machine-readable reason is genuinely useful for an integration audience ("why did this fail on verifier X?"), but that's not this endpoint's job. And that audience is exactly who follows the report link to the verifier's own service. For a display UI, the contract is unverified either way, and a help text can enumerate the common reasons (pending, source unavailable, unsupported build environment, policy rejection, build failure, etc.). If real demand shows up, an optional reason is additive and non-breaking, so nothing is lost by waiting.

3. Out of band semantics

I'd keep this a single boolean. From the consumer's standpoint the cases collapse to one relevant bit: can I independently recheck this from the recorded SEP-58 fields, or not? Splitting it into method × source-visibility × reproducibility multiplies the combinations a verdict-display UI has to reason about, for detail that belongs on the verifier's page.

4. Source visibility and long-term viewability

I'm not convinced distinguishing these states is useful. "Source unavailable" already subsumes "private source" from the consumer's standpoint: in both, you can't inspect it here. The distinction is explanatory, not verdict-changing, so it belongs in help text and the verifier's report; not having the source available is evidence enough for lack of verification.

A consumer that wants to confirm also gets the answer for free: it already has source_repo / tarball_url and learns "private / deleted / down" by trying to resolve them.

5. Evidence artifact references

I like the sha256 addition. What would be the possible types that must be documented by the SEP? Covering all cases is not feasible. Some examples:

• report: a web-redable url
• other: open purpose

{
  "result_urls": [
    {"type": "report", "url": "https://verify.example.com/stellar/<hash>"},
    {
      "type": "provenance",
      "url": "https://verify.example.com/wasms/cb2fc3a1/provenance.intoto.jsonl",
      "sha256": "1f2e3d4c5b6a79887766554433221100ffeeddccbbaa99887766554433221100"
    },
    {
      "type": "attestation",
      "url": "ar://AbCdEf0123456789AbCdEf0123456789AbCdEf0123456789ABC"
    },
    {
      "type": "sbom",
      "url": "https://verify.example.com/wasms/cb2fc3a1/sbom.spdx.json",
      "sha256": "0a1b2c3d4e5f60718293a4b5c6d7e8f90a1b2c3d4e5f60718293a4b5c6d7e8f9"
    },
    {
      "type": "audit",
      "url": "https://audits.example.com/my-contract-2026-05.pdf",
      "sha256": "778899aabbccddeeff00112233445566778899aabbccddeeff001122334455667"
    }
  ]
}

6. Future trust signals

Fully agree, and that's precisely why results live under a named source_code_verifications array rather than flattened onto the wasm. A SEP-55 attestation claim is a separate claim, so it arrives later as a sibling array (e.g. build_verifications); additive, no rename or move of any SEP-58 field, no break for existing consumers.

More broadly: verifiers should enrich their verifications with as much data as possible, and surface that on their own service. The report entry is the intended link from a consumer back to that fuller record.

I am a colleague of @jia57b, adding data and one blocker to two of the points above.

Out-of-band semantics. Our latest census of mainnet contracts that record a CLI and Rust version but
no build recipe found published images covering 6 of the 99 toolchain pairs those contracts record.
Serving them at all therefore means a verifier assembles environments itself from pinned components. A
rebuild in a publisher's own image and a rebuild in a verifier-assembled one are different claims, and
today both are out_of_band: false whenever the verifier considers them in-band — the consumer cannot
tell which it got.

We are explicitly not asking for a trust-level enum. Which criteria a wasm must meet is the
verifier's decision, and ranking publishers is not something this SEP should have to do.

Proposal. Replace the boolean with fields that say what kind of verification this was, and add an
optional pointer from the entry to the policy the verifier applied. A consumer then judges for itself
and the SEP ranks nobody.

Evidence artifact references. {url, sha256, type} covers what we need. The case that makes sha256
load-bearing rather than convenient: attribution does not survive a copy. It rests today on the
result root's HTTPS origin, which covers only the copy served from that origin. An archived or mirrored
copy is hash-checkable but not self-attributing — anyone can upload bytes claiming to be a given
verifier's.

A signature closes that, and there is nowhere to put one. Of report/provenance/attestation/sbom/audit,
none is a signature, and attestation is taken: SEP-55 uses that word for the source-repo marker, so a
consumer reading a signature entry as an attestation reports a signed result as an attested one.

Proposal. Add a distinct signature type — not a reuse of attestation — and pin three things
in the SEP, or no consumer can verify any verifier:

1. Detached, never embedded. Embedding changes the artifact's bytes, so its hash, so every entry
   pointing at it — "add signing later" becomes a migration across every published copy.
2. Signed over the artifact's exact published bytes. No canonicalisation needed, as long as the
   artifact does not contain its own signature.
3. Algorithm and encoding named on the entry, not inferred. Ed25519 is the obvious default.

And one security consideration worth stating rather than leaving to implementations: a key fetched from
the same result root as the artifact it verifies is circular — whoever can serve a forged root serves a
forged key with it. The key must be anchored somewhere the consumer already trusts; a verifier may
publish it in its own manifest for discovery and rotation, but that copy cannot be the anchor.

Out-of-band semantics

What will systems do with the out of band boolean or additional fields?

My take from https://github.com/orgs/stellar/discussions/1945#discussioncomment-17201871 and https://github.com/orgs/stellar/discussions/1945#discussioncomment-17616775 is that the out of band information won't be used by user facing systems and is mostly useful for transparency and debugging.

Replace the boolean with fields that say what kind of verification this was

I think we should drop the out of band field, and move the out of band information proposed into a new field that verifiers can place additional information about the verification, such as logs or some structured data. That new field's contents does not need to be standardised, because there's no proposed system that would interoperate with it. Verifiers are likely to have different implementations and innovations and so this can freely capture that raw transparent data.

If a verifier says a contract is verified it should mean the verifier has been able to authentically build the code into the contract, and the rest of the information is implementation details provided for transparency and debugging.

Agreed on dropping any trust-level judgement — not what we were asking for.

One pushback: verified: true says the bytes matched, not whether a third party can check that themselves. Free-form debug info doesn't help an aggregator tell those apart.

Proposal: keep the free-form bucket for everything else, but standardize one optional field — a URL to the recipe/policy a third party would need to reproduce the build. Contents stay verifier-defined; the field just says whether something checkable exists.

Thank you! That's valuable feedback.

Hey @orbitlens!

Thanks for your feedback.

To me the whole idea of verifying source code tarballs without publishing the source code itself looks absolutely bizarre

I'm with you on that but, unfortunately, some partners won't release the source code. Even SDF personnel had a hard time being onboarded and getting access to source code, having to go through NDAs, clearance, etc.

please add a bulk-load API endpoint for verification results to this SEP

I'll update the draft with this.

I think Orbitles meant more that having a service claiming to have "verified source" without having access is strange.

Good points on the compliance part and the wording there 👍 Probably we could make some recommendations regarding TOS and service provided to help there. If we could get some help from legal folks at SDF that would be very helpful I think.

@tupui That's exactly what I read. I gave an example on how having access to source code can be a problem even for SDF personnel, and how we need to support it anyway.

If we pull the data from, say, https://api.verifier-registry.com, then we'll be displaying something like "Contract source: <github.com/repo> verified by api.verifier-registry.com". Therefore, if users lose their funds and come to us asking why we marked the contract source as verified, we'll point to the "verifier-registry.com" as an ultimate centralized service responsible for the verification, not to some random verifier that I never met.

👍🏻 This seems to me like the intuitive way I would also want to use and serve results.

It's another motivator for why I think we should remove aggregator support from the SEP and keep it hyper focused on a single verifier. And even if removed an aggregator could still serve this same API and add some additional fields where those additional fields could be another SEP. So don't not support it, but orient the SEP on just a "verifier" and then a type of verifier could be one that aggregates but yeah the utility is questionable. Ideally the top of the API response is a verified: bool.

I thought the aggregator support was being removed as a result of this conversation: #1945 (reply in thread), but I still see it present in the open PR.

the whole idea of verifying source code tarballs without publishing the source code itself looks absolutely bizarre

@tupui That's exactly what I read. I gave an example on how having access to source code can be a problem even for SDF personnel, and how we need to support it anyway.

❓ @fnando I thought the support for contracts without repos was contracts that get developed in closed source but then get released public when deployed but there isn't a repo, it'll just be uploaded somewhere such as to the verifier. The verifier is verifying because it has the source yes?