1. Application
Applicant name or organization: Shikhar Singh
Primary contact / forum handle: [forum handle]
Social handle (X and/or LinkedIn): 0xShikhar⚡️ (@0xShikhar) / X https://www.linkedin.com/in/0xshikhar
GitHub profile: 0xshikhar (Shikhar Singh) · GitHub
How did you hear about this grant program? The Round 1 Grant Guide on this forum, via the @ShutterNetwork posts on X.
Wallet address for payment (if approved): 0x30BCD2e90B3C05e54446568d823408B2ddfa7A01
Application type:
Round 1 — Proactive grant for defined future work
Round 1 objective (select one):
Objective 5 — Package a Repeatable Shutter Workflow
Contribution area:
Research or technical work
2. The Shutter need or opportunity
What specific need, opportunity, or gap does this contribution address?
Shutter API can seal a payload until a timestamp or an on-chain event. It does not run a proposal round. A buyer who wants a sealed RFP still has to register an identity, fetch encryption data, encrypt with @shutter-network/shutter-sdk, store the ciphertext, bind it to the bidder, close the round, poll for the key, decrypt, and prove the plaintext is the submitted ciphertext. That glue does not exist, so every integration is a one-off.
The current pieces stop at the cryptographic call.
@shutter-network/shutter-sdkencrypts and decrypts. It does not register an identity, watch a trigger, or verify a round. GitHub - shutter-network/shutter-sdk: TypeScript SDK for interacting with the Shutter crypto library, providing encryption, decryption, and utilities. · GitHubshutter-api-examplesis a hello-world and a rock-paper-scissors app. GitHub - shutter-network/shutter-api-examples: Example apps to get you familiar with how to interact with shutter api and sdk · GitHub- The use-case docs describe a sealed-bid RFP in prose. They ship no contract, schema, or verify command. Shutter API Use Cases | Shutter Docs
- Event-based decryption has been specified since October 2025. A timestamp close still lets an operator choose when to ask for the key. A
RoundClosedevent does not. That path is documented and not packaged. Preview: Event-Based Decryption for Shutter API
Shutter has already tried to buy this once. In May 2025 brainbot ran a sealed RFP for sealed-bid auctions on Paddle Battle and collected the bids on Shutter’s own sealed-bid page. The work was awarded to General Magic. The public result is a Paddle Battle Next.js app on Chiado, not a package another buyer can install. Request for Proposals: Create Sealed Bid Auctions on Paddle Battle and GitHub - brainbot-com/paddlebattle-nextjs: Sealed Bid Auction with Shutter Network · GitHub. The API page still lists Paddle Battle as “soon integrating,” and lists sealed-bid RFPs as a use case. Shutter API | Threshold Encryption Service
This grant turns that one-off into a reusable workflow.
Why is it relevant to Shutter now?
Objective 5 asks for an existing Shutter capability packaged for a defined user. Sealed RFPs, selection processes, procurement, and auctions are the examples in the guide. Shutter DAO 0x36 Impact Pilot Program Round 1: Grant Guide & Application Template. The last attempt to build this did not leave anything a second buyer can run. The next integration still starts from the API docs.
What specific demand signal supports this work now?
The May 2025 Paddle Battle RFP, linked above. brainbot already ran a sealed process to procure a sealed-bid integration, awarded the work, and the leftover is a single application. The docs still describe the RFP flow as if the package existed.
Who benefits from the outcome, and how?
- brainbot, the operating owner of Shutter API, gets a reference package for the next auction or RFP integration instead of another bespoke build.
- A DAO or grant program collecting competing proposals gets a round it can run without implementing the API by hand.
- Shutter DAO 0x36 gets a reusable workflow for a use case it already lists.
Value pathway (required for Round 1):
Validated path toward a pilot, integration, or repeatable workflow
Durable ecosystem, adoption, or public-goods value aligned with Shutter’s mission
Who is the relevant decision-maker, operating owner, funder, partner, or beneficiary group?
| Role | Who | Status |
|---|---|---|
| Operating owner | brainbot, Shutter API | Named. Already procured one sealed-bid integration through the May 2025 RFP |
| Prior build | Paddle Battle / General Magic | Named. Public Chiado app, not a reusable package |
| First organizer | A DAO or grant program collecting competing proposals | Route, not a signed buyer. Named before the second tranche, or a written refusal is filed |
| Beneficiary | Shutter DAO 0x36 | The workflow is for a use case already in Objective 5 |
What problem are they solving, and what evidence supports the value of addressing it?
A sealed RFP leaks if bids are visible before close. Shutter API locks the payload and stops there. The Paddle Battle app shows the integration can be done once. It does not show that the next buyer can repeat it.
What Shutter product, deployment, service, or capability would this contribution advance?
Shutter API, using both the time trigger and the event trigger.
What decision, implementation step, or next action should this contribution enable, and by when?
| Counterpart | Decision or step | Target date |
|---|---|---|
| brainbot | Use or decline the package as the reference for the next sealed-bid or sealed-RFP integration | Repo and transcript by 30 November 2026 |
| First organizer | Run a second round, or write down the blocker | Organizer named before the second tranche. Their decision is the next step, not the milestone |
| Later buyer | Install the package and rerun the verify CLI without this team | Package public by 30 November 2026 |
What evidence will show progress beyond outreach, general interest, or a speculative concept?
A verified contract, a public package, a verify CLI, and one live transcript.
Deliverables and acceptance criteria:
| # | Deliverable | Acceptance criterion |
|---|---|---|
| D1 | Gap note | Posted in week 1. Links the SDK, the examples repo, the use-case doc, the event-trigger post, and the Paddle Battle app. States what each does not do. Content hash on the forum |
| D2 | Round contract | Solidity. Create a round, hash the terms, one submission per address, no plaintext on-chain, close emits RoundClosed, no edits after close. Verified on Chiado. Tests in CI |
| D3 | Workflow SDK | TypeScript. Depends on @shutter-network/shutter-sdk and does not fork it. Calls: createRound, prepareProposal, submitProposal, status, reveal, transcript. Time trigger and event trigger. Typed error when the key is not out |
| D4 | Two apps and a verify CLI | Organizer page: create, watch, reveal, export. Proposer page: read terms, seal locally, submit, receipt. verify-round recomputes hashes, checks the identity and the key, and exits non-zero on a mismatch |
| D5 | Live transcript | One completed Chiado round. Terms hash, identity, key, every ciphertext hash, every decrypted hash. Forum post with the verify command, and the organizer’s yes, no, or blocker |
Milestone for the second 50% payment:
D2, D3, and D4 public, and D5 posted, by 30 November 2026. An informational checkpoint on 4 November publishes D1 and a deployed contract with one sealed submission.
Timeline, assuming an award in the week of 12 October:
| Week | Dates | Work |
|---|---|---|
| 1 | 15–21 Oct | D1 gap note. Contract interface frozen |
| 2 | 22–28 Oct | Contract tests. Chiado deploy |
| 3 | 29 Oct–4 Nov | Checkpoint: deployed round, SDK against it, one sealed submission |
| 4 | 5–11 Nov | Event-trigger close. Verify CLI |
| 5 | 12–18 Nov | Organizer and proposer pages |
| 6 | 19–25 Nov | Public round opened |
| 7 | 26–30 Nov | Reveal, transcript, forum delivery post |
Out of scope:
No new cryptography, no changes to Shutter or Snapshot code, no encrypted-mempool work, no voting product, and no PEN work. The organizer’s later decision is not a grant milestone. The grant is judged on the artifacts. Plaintext never goes to a backend.
Risks and limits:
The event trigger may fail on Chiado. If it does, the transcript uses the timestamp trigger and the report says what failed. No organizer may take the first round. The deliverable is then the transcript plus the written refusal. The package makes the next attempt cheaper than the Paddle Battle build. It does not, by itself, create demand.
Why this applicant:
I build client-side cryptographic workflows. Press Protocol seals a publication with Ed25519 on the client, addresses it with CIDv1, and mirrors it over IPFS and Tor. https://pressprotocol.com/ and GitHub - 0xshikhar/PressProtocol: Censorship-resistant publishing infrastructure for the decentralized web. Combines IPFS, Tor, and cryptographic identity with multi-transport failover for resilient, permissionless content distribution. · GitHub. The same rule applies here: the payload is sealed before it leaves the proposer, and a third party can verify the result without trusting the operator. SDKs for that stack already ship in TypeScript, Python, Go, and Rust.
3. Funding request
Amount requested: $2,500, paid under the program’s USDC and SHU arrangement. 50% on approval, 50% after the milestone review.
| Item | Amount |
|---|---|
| D1 gap note and D2 contract, tests, Chiado verify | $800 |
| D3 workflow SDK, time trigger and event trigger | $700 |
| D4 organizer page, proposer page, verify CLI | $700 |
| D5 live round, transcript, delivery post | $300 |
| Total | $2,500 |
If the DAO prefers a smaller award, a contract-and-CLI cut without the second app is $2,000.
4. Prior compensation and disclosures
Have you, your organization, or a related party received or requested compensation for this work from Shutter or another source?
No
Do you have any financial, professional, or organizational conflict relevant to this application?
No. I hold no role with brainbot, Axia, SEEDGov, or Shutter. Press Protocol is a separate project and is not part of the deliverable.
5. Public discussion
Forum post link: this thread.
Questions for the community:
- brainbot: is a reference sealed-RFP package useful after Paddle Battle, or is the Next.js app the intended end state?
- Is a Chiado transcript enough for the second tranche, with a Gnosis round as follow-on work?
- If the budget is tight, is the $2,000 cut preferable?
6. Applicant attestation
I confirm that the information in this application is accurate to the best of my knowledge; that I have disclosed relevant prior compensation and conflicts; and that I understand any award remains subject to the published process and DAO approval.
Name / handle: Shikhar Singh / @0xShikhar Date: 2026-10-09