Document the wire-format invariants in one place, referenced from all three languages

[Otaiki1]

Context

Three independent implementations must agree byte for byte, and a disagreement is silent until a
claim fails on-chain with InvalidProof:

1. The circuit's public signal order (circuits/membership.template.circom + the generated component main {public [...]} line).
2. The contract's public_inputs vector order (contracts/sharibo/src/lib.rs, in claim).
3. The SDK's G1/G2 byte encoding and field-element serialisation (packages/client/src/prove.ts).

Plus the external nullifier derivation, which is implemented twice — compute_external_nullifier in
Rust and computeExternalNullifier in TypeScript — and must produce identical values.

Each site has good comments. None of them is authoritative, and the recipient-binding work will change
the signal order in all three at once.

Where to build it

• New file docs/wire-format.md.
• circuits/membership.template.circom, contracts/sharibo/src/lib.rs, packages/client/src/prove.ts — replace the local prose with a pointer to the document.
• test-vectors/ — the fixtures that make it checkable.

What to do

• Specify the public signal order, with the index each signal occupies and the rule for adding a new one.
• Specify the external nullifier derivation: SHA-256 over big-endian u64 circle_id || u32 round, reduced mod r. Note that both implementations must agree on byte order, and point at the test that proves it.
• Specify the G1/G2 encoding: compression, endianness, byte lengths.
• Specify vk.ic length as public_inputs + 1.
• Add a "changing this" checklist naming every file that must move together.

Acceptance criteria

• All three implementations point at this document instead of describing the format themselves.
• The document is validated by the committed test vectors, not just prose.

[hilaryy82-source]

@hilaryy82-source has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

i would like to work on this issue

ℹ️ Repo Maintainers: To accept this application, review their application or assign @hilaryy82-source to this issue.

[Itzabdoul1]

@Itzabdoul1 has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hello, I carefully analyzed the issue and identified the relevant sections of the codebase. I'd be happy to work on a clean, reliable implementation and submit a quality pull request.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Itzabdoul1 to this issue.

[DanbabaJr]

@DanbabaJr has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi, I would love to work on this issue please assign

ℹ️ Repo Maintainers: To accept this application, review their application or assign @DanbabaJr to this issue.

[drips-wave]

Congratulations, @DanbabaJr! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on August 31, 2026.

🧑‍💻 @DanbabaJr: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊