I’ve gone through the updated repository, the NPM package, and the GitBook. With these materials now available, the elements described for Milestone 1 are implemented, including the SDK core, Rootstock RPC handling, EIP-1193 provider, wallet integration, token and basic NFT utilities, signature management, build configuration, and the testing setup.
Thanks to the team for preparing and sharing the updated resources.
Thanks for the confirmation!
We’re proceeding to milestone 2 now.
We voted against the active proposal not because we disapprove the proposal, but the proposal was apparently created in an inappropriate way. We encourage the team to discuss this with the Rootstock team and properly make another proposal with the right setup.
After reviewing the correct updated submission, we are content with the proposal and believe the milestones were accurately met.
Thank you for the support!
Hello friends! Been a while since our last update, but the key updates are that milestone 2 is completed and validated. We’ve delivered:
Staking contract interfaces with pre-packaged hooks for staking operations, staking contract interaction abstractions, a callback-oriented interaction layer, among other things. We also delivered reference Winks, including a token transfer Wink, tRBTC faucet, and a staking Wink. This is accompanied by documentation including installation instructions and API reference for core functions. The KPIs this milestone achieved are: Staking functionality integrated, a ready Wink with a pre-defined function, successful transactions with Tweet generation, and operational faucet and staking operations.
In our next milestone, which we’ve already made progress on, we’re doing a second implementation, releasing comprehensive documentation and doing a full release of Winks on Rootstock, along with npm publication and complete testing framework, and ci/cd pipeline. We’re also getting ready for GTM conversations with protocols on Rootstock and plan to focus on distribution post M3. This distribution will be both desktop plus mobile X app.
Huge thanks to @tamlerner and @Kaf_Anode for their support! Onwards and upwards!
Based on feedback from the Team and some Delegates, elaborating here on the technical scope we’re set to achieve with M3:
Deliverables for milestone 3:
Second reference Wink:
Staking, faucet, or NFT interaction Wink
Demonstrates advanced SDK capabilities
Package distribution:
NPM and Github package publication
Complete CI/CD pipelines
Comprehensive documentation:
Technical documentation via Gitbook
Usage examples and Rootstock-specific configuration
Developer onboarding materials with demo apps
Testing suite:
Playwright iframe embed testing
Complete test coverage
KPIs for milestone 3:
Two working reference implementations (token transfer + faucet, staking or NFT)
Published SDK packages with automated CI/CD
Complete Gitbook documentation live
Testing pipeline functional
Since we’ve already made significant progress on the milestone, as confirmed by a Delegate, the timeline to complete this would be 7-10 days only. After this, the next set of challenges revolve around:
Appreciate the M3 scope walkthrough and the M2 work shipped. We reviewed the implementations in the rootstock-sdk.winks repo against the M2 deliverable list: stakeTransaction, faucet, and post-transaction Tweet generation are all present and match what’s promised by name. The implementations are minimal in places, and faucet in particular is a single HTTP call to an external endpoint that’s currently unreachable, so KPI 4 (faucet operations working) isn’t satisfied at runtime. Two clarifications on M2 plus a structural concern on M3 would help close out the review.
On M3 ecosystem impact: the M3 scope covers SDK polish, a second reference Wink, NPM publication, CI/CD, Gitbook documentation, and Playwright testing. Your M3 elaboration places adoption and distribution work, including warm intros and POCs with 3-5 projects, after the grant completes. The V3.2 grant guidelines open with:
As scoped, M3 closes the grant without measurable Rootstock-side activity attributable to the work, and the FES accountability metric is undefined when ecosystem value generation depends on post-grant adoption. Folding a signed LOI or named integrator POC into M3 KPIs would change that. Without it, the case for the M3 milestone as currently scoped is thin.
Thanks for the response! I’ll share both the M2-related items you’ve asked for easy verification. For M3, let me get back on this shortly, thank you!
Hey @winksdotfun, thanks for the update. I have a significant concern before potentially supporting M3 funding. The core value proposition of Winks is distribution through Twitter/X, but when I click through prior Winksdotfun examples shared in your earlier comment, X first shows a warning that the link may be unsafe/spammy. Then, after choosing to ignore the warning and continue, the destination URL appears to be broken.
Before moving forward with M3, I’d like to see:
Thanks and looking forward to your responses.
Hi @Tane. For the Tweet and txn hash, please see the URLs herewith;
1. Token Transfer Wink — Demo & Embed
a. Here is the live token transfer Wink on X:
https://x.com/UltimateWink/status/2036838093521822062?s=20
b. tx hash (token transfer):
2. Staking Wink + Tx Hash
a. Live Wink:
https://x.com/UltimateWink/status/2037784246635708524?s=20
b. tx hash (staking):
3. Faucet Wink + Tx Hash (the faucet is currently out of funds)
a. Live Wink:
https://x.com/UltimateWink/status/2033753686867120393?s=20
b. Testnet tx hash (faucet):
Regarding the documentation, M3 will cover everything, including the hooks, callback layer, etc.
Thanks for pulling these together, @winksdotfun.
These cover the two halves we asked for but not the link between them: a rendered Wink and a real on-chain stake, with nothing tying that transaction to the embed. A manual stake would look identical, so the tweet-to-transaction flow still is not inspectable end to end. The transfer hash is a plain rBTC send, and the faucet is out of funds. M2 is settled either way, so this is for the record, not to reopen it.
On M3, our position is the same one we laid out on the scope: SDK completion, packaging, and documentation are not measurable Rootstock activity on their own. A signed LOI or a named integrator would change that; without it, the case for the milestone stays thin.
Thanks @Tane. Noted your concerns on M3 - I’ll circle back on this shortly.
Hi @Axia! Thanks for your questions - your observations are correct, as well as your thesis. Our domain reputation for the core winks domain is affected due to cold spamming on emails as well as DMs (done for bd mostly), and thus the “potentially spammy link” warning. The “broken” links are because those Winks are no longer hosted on our server since their intended purpose was complete. For future non-flagging or non-breaking, we plan to use a different domain, and to keep their hosting live on server for at least 12 months (renewed if needed), and if they are of the type that have limited-period purpose, then we’ll show some fail-state landing page instead of just displaying a broken link.
Below are the examples you requested:
Live Rootstock Wink rendered from X:
https://x.com/UltimateWink/status/2036838093521822062?s=20
Trial tx hash from above Wink:
I trust this addresses your queries, but please let me know if you need any additional information or clarifications. Thank you!
Hi Tane! Thanks for your patience on the signed LOI/named integrator part. We’ve worked on this since the last few weeks, and happy to announce that we’ll be doing an integration with MOC for DOC minting Wink! Trust this would be a good start, and with this case study, we can attract more projects to generate Winks with.
Thanks, @winksdotfun. A DOC minting Wink with MOC is the kind of named integration we asked for.
Two things to make it concrete. Has MOC confirmed on their side? A signed LOI or a public confirmation from their team would settle it. And is the integration part of M3 rather than a follow-on? Your M3 scope leaves the second reference Wink open to a staking, faucet, or NFT interaction; we would welcome the DOC minting Wink in that slot, with the completion evidence being the Wink live on X and mainnet DOC mint transactions traceable to the embed, since that link is where earlier verification fell short.
Both together would resolve our concern on M3’s ecosystem impact.
Thanks @Tane. Yes, MOC is confirmed, there is no LOI, but when the Wink is ready, they’ll help us market it to drive traction. And yes, we can do the DOC minting Wink itself as the second reference Wink for M3, so that it’s covered within this milestone’s deliverables; the Wink will indeed be functional on X and enable mainnet DOC mint transactions traceable to the embed. Glad to hear this will resolve your concerns about M3’s ecosystem impact! 
Thanks for the response and for continuing to engage with the feedback.
I have voted Against the M3 proposal. I’m still not comfortable supporting M3 at this stage.
My concern is not only whether the SDK/package/docs can be completed. My concern is whether M3, as currently evidenced, creates a verifiable distribution path and measurable Rootstock activity — which is the core value proposition of Winks.
The main reason this proposal was compelling was that Winks could make Rootstock actions accessible through X/Twitter. But the prior examples shared in the thread surfaced two issues that directly affect that thesis:
The team’s explanation confirms that the domain reputation was affected by prior cold email/DM activity and that earlier Winks were no longer hosted because their original purpose had ended. I appreciate the transparency, but this creates a real execution risk. If the core product depends on X distribution, then domain reputation, link trust, hosting continuity, and durable user paths are not secondary details — they are part of the product.
I also don’t think switching to a different domain and committing to keep future Winks hosted for 12 months is enough by itself. That may be the right mitigation plan, but I would want to see it working before approving the next milestone.
For M3, I would need stronger evidence that the end-to-end flow works in the way the proposal claims. Specifically:
The proposed MOC integration is directionally positive, and I agree it could make M3 more compelling. But without public confirmation from MOC or inspectable end-to-end transaction evidence, I don’t think it fully resolves the concern yet.
I supported this grant at the start and still think the idea is good. What changes my read on M3 is that it is the last milestone. Once it pays out the grant is closed and there is nothing left to hold anyone to, so whatever matters has to be inside this milestone.
The DOC minting Wink live on X with mainnet mints traceable to the embed is the part that would make M3 worth funding. That sits in a forum reply and not in the KPI, which still only asks for two working reference implementations. As @Curia pointed out, working just means it runs in a demo.
The team also said distribution comes after M3. So as written, the grant closes with the actual result still ahead of it and no milestone left to tie it to. Voting against M3 as written.
Hey @winksdotfun we have voted for this proposal, and our for vote is not a blanket approval of SDK/package/docs alone. It is support for the updated M3 on the understanding that final delivery must demonstrate the full value proposition: a named Rootstock integration, a working X-based user path, and verifiable on-chain activity attributable to that path. If the milestone is completed on those terms, it meaningfully resolves the gap that delegates identified and gives Rootstock a concrete case study for social-to-on-chain actions.