[2508 Grant Proposal] Winks.fun: On-chain actions on Rootstock within Twitter

Grants & Incentives
42

Hi everyone,

Since the M3 vote we have spent the time building rather than restating our case, because the concerns came down to one thing: show it working. Here is where we have landed.

The integration is public. The DOC minting Wink with Money On Chain is announced and live in beta, and @RootstockColl has reposted it:

Worth clicking that one directly, because it answers a question asked here more than once. The Wink itself: https://rbtc-doc-gaift.ondigitalocean.app

The earlier links. The old examples were flagged and had gone offline once their campaigns ended. That was a fair hit to take. These are on fresh infrastructure and are hosted to stay, but for clarity, we’re giving Rootstock builders SDK so they can self-host and will not rely on us.

@Axia, this is aimed at your vote. You said domain reputation, link trust and hosting continuity are part of the product rather than side details. We are also removing the dependency on us entirely: the SDK is available directly, so any project can generate and host its own Wink without relying on us keeping a server alive. Hosting continuity stops being a question about our team.

On transactions being attributable to a Wink rather than to a manual action done separately, which you and @Tane both pressed on, we built an explorer for exactly that. It shows every transaction from every Winks app on Rootstock as it happens, filterable by Wink and by mainnet or testnet, including a DOC Minting filter:

@Tane, on your two conditions: the integration is named and public, and the DOC minting Wink sits inside M3 as the second reference Wink rather than as a follow-on. It is already standing up in beta, ahead of the milestone closing.

@ChronoTrigger, your point was the sharpest one made in this thread and we took it. Because M3 is the last milestone, the result has to sit in the KPI and not in a forum reply. So we propose the M3 completion criteria read as follows, and we are happy to be judged against them:

  1. The DOC minting Wink with Money On Chain, live on X.
  2. Mainnet DOC mint transactions traceable to that embed through the Winks explorer.
  3. The reference Winks above live and reachable, plus the SDK published for permissionless Wink creation.
  4. Documentation, CI/CD and Playwright embed testing as scoped.

That puts the actual outcome, a real Rootstock action driven from X with on-chain proof, inside the milestone instead of after it.

@Curia, this also speaks to your point that working only meant it ran in a demo. Under these criteria, working means live on X with mainnet transactions anyone can trace.

@DAOplomats, thank you for voting in support and for setting the terms plainly: a named Rootstock integration, a working X path, and verifiable on-chain activity attributable to it. That is what the criteria above commit to. Thanks also to everyone who has backed M3 and stayed constructive through a long back and forth.

Happy to answer anything before the next vote.

Thanks,
AJ, Winks.fun

43

Thanks, @winksdotfun. The DOC minting Wink is live and sits inside M3, which covers what we asked for in July.

What remains is usage. The newest record in the Winks explorer is from early September, before the launch post. Could you share mainnet DOC mint transactions made through the Wink since the announcement, as hashes we can open on a block explorer? It would also help if your proposed criterion on “mainnet DOC mint transactions traceable to that embed” said how many mints, over what period, you expect to show, so that a single test transaction cannot satisfy it.

44

Hi @Tane thanks for the quick review. This DOC minting Wink has just soft-launched, it’s in QA, there are no transactions yet. The explorer’s purpose was to be able to attribute actions to Winks.

45

Thanks, @winksdotfun. Understood that it has just soft-launched.

Since your proposed criterion is mainnet DOC mints traceable to the embed, the simplest way to show it is to run the test in production: mint once through the Wink on mainnet and let it show up in the explorer’s DOC Minting filter. We can then confirm it ourselves from the explorer and the transaction hash, without needing a walkthrough. Before the resubmitted vote, it would help to have that first mainnet mint visible, plus the number and period you intend for the criterion.

46

Hi @Tane, both items are done.

We ran the test in production. There are now mainnet DOC mints through the Wink, and they show up in the explorer under the DOC Minting filter:

The one to open first:

0xc76c38a91839c04af98421eadd8056eb8c8b3c59959f36fcaad552d22fb50781

On explorer.rootstock.io that is a successful contract call in block 9270328, Sep 25, with 0.288769344 DOC minted to the sending wallet. Three more from the same run:

0xeb484636bab8881b6fc4427025b6d35aafbb6fde02ab59f65582cfa3debd612f
0x90c7009fd963da07e344c816be8ecef365e2ad736fe8d2111e29f81afc1c838a
0xe0ea1164554fc9505f9277e6767fd911ce44de80fe2ee7fa9a0014ce1802b97e

These are test transactions from our own wallet, in small amounts. They establish the end-to-end path that a mint made through the embed lands on mainnet and is attributable in the explorer.

On the number and period, set so that a single transaction cannot satisfy it: At least 20 mainnet DOC mints, from a minimum of 10 distinct wallets, completed through the DOC minting Wink within 30 days of the M3 vote passing. All visible under the DOC Minting filter in the Winks explorer, with hashes verifiable on explorer.rootstock.io.

The distinct wallet floor matters more than the raw total, which is why it is set separately, and our own and MOC’s wallets are excluded so the number cannot be padded from the inside. If it comes in under that, we are content for the milestone to be judged unmet.

Thanks for pushing on this one. Getting the attribution path visible was the part worth being strict about.

47

Thanks for the data! How are these four mints attributed to the Wink? Could you explain what links each transaction to the embed on-chain?

48

Hi @winksdotfun

We’re glad to see the spam/unsafe warning has been addressed — we were able to follow the X link directly to mint DOC without the flag that affected earlier links. This had negatively informed our M3 vote before.

Separately, we agree that a concrete deliverable in terms of transaction count (20), unique wallets (10), and time period (30) is the right direction.

We’re curious about the logic behind the specific numbers chosen, though — what is the team basing this objective on, as in data on conversion rates from your prior campaigns on other chains, or on typical DOC-minting transaction/wallet volume over a similar timeframe through other channels?

This could help in assessing what represents meaningful traction.

Thanks!

49

Here is how the explorer works: When a Wink sends a transaction, the app posts the hash to our API under a key belonging to that Wink. We look the hash up on a Rootstock node and take from, to, value, status, and block number from the chain, dropping the row if what we were told contradicts what the chain says. The chain proves the transaction is real and unaltered. The attribution to a particular Wink comes from the reporting key.

50

Thank you! Regarding the numbers: We counted every successful DOC mint on the MoC contract (0xf773…8370) from 16 to 28 September, across both mint entry points (0x3b3032d2 and 0x7d28f1e5), excluding our own test wallet and all failed attempts. Across every channel, that is 7 mints from 6 distinct wallets, or roughly 18 mints from around 15 wallets over 30 days. The window is short, so read it as an order of magnitude. Anyone can repeat the count from the contract page.

Your question made us realise the criterion is better stated in two parts, so treat this as a refinement of what we told Tane. The target we’re campaigning to hit is 20 mints from 10 distinct wallets in 30 days. While that is very high given the aforementioned data, we’d rather be measured against ambition than comfort. The threshold the milestone should be judged against is 12 mints from 8 distinct wallets, same window, same rules: no Winks or MOC team wallets, every mint carrying the Wink’s on-chain marker, all verifiable on explorer.rootstock.io without reference to our own explorer. That is two-thirds of the protocol’s current monthly mints and over half its minting wallets, which for a channel in its first 30 days is what meaningful traction looks like, and well beyond what a test run could produce.

51

Your breakdown addresses @DAOstar_gov’s question about the basis for the target, and the explorer walkthrough answers ours: attribution comes from the Wink reporting each hash under its key.

That works inside the Winks explorer, but your threshold of 12 mints from 8 wallets asks for every counted mint to carry the Wink’s on-chain marker and be verifiable on the Rootstock explorer alone. The four test mints from your earlier post don’t carry one yet. Each is a direct call to the MoC contract’s mintDocVendors function with the vendor address set to zero and no other tag, so on-chain they look like any other DOC mint.

Could you confirm what the marker will be and make sure it is in place before the M3 vote, so delegates can verify the count from the Rootstock explorer when the 30 days are up? Most other mints in your count already pass a non-zero vendor address, so a Winks address with no vendor markup in that field looks like a straightforward option.

52

Hi @Tane, agreed, and thank you for pointing at the simpler option. You’re right that the vendor field is the better marker. An unregistered address in that field carries no markup, so nothing changes for the user, and it is recorded in the mint event itself rather than in a tag we would have to ask you to decode.

The marker is this address, in the vendorAccount field of every mint the DOC Wink builds:

0x4f944cbdce6a74618d754fa6cf845eae5899eb7d

It is a dedicated address used for nothing else, so a filter on it returns only Wink mints. The Wink is live with it set, and here is the production test:

Opening that shows a successful mintDocVendors call with the marker as the second argument, 1.687 DOC minted to the sender, and the same exchange rate as the earlier zero-vendor mints, so no markup applied. That is what every counted mint will look like. The earlier test mints with a zero vendor are excluded from any count, as is the wallet that ran this one (0x2fFf…5d32).

Verification for the 30 days is therefore: successful mints on the MoC contract carrying that address in the vendor field, counted on the Rootstock explorer.

1 Like
53

Thanks for confirming. We checked the test mint and the marker is in the vendor field. We’re ready to validate the 30-day results against it on the Rootstock explorer.

1 Like
54

Our concern is that this proposal asks the DAO to approve payment for Milestone 3, the final milestone, while the KPIs will only be assessed during the 30 days following the vote. Should those KPIs not be met, there are no consequences in place and no tools left to the DAO to act on it. We are not comfortable with this.

SEEDGov Delegate Thread
55

Hi @SEEDGov, that is a fair concern. What we can offer is a commitment made in public and on the record.

The threshold stands exactly as written: 12 mints from 8 distinct wallets outside the exclusion list, each carrying the marker, over the 30 days. We’ll report the count in this thread at the end of the window, with the hashes, whichever way it goes. The measurement does not depend on us, which is the point of the work we did on the vendor marker. Any delegate can run the same count from the Rootstock explorer and arrive at the same number, so there is no version of this where we report a result that the chain does not support.

We’d also note that this is not the last thing we want from this ecosystem. We are building on Rootstock beyond this grant, and a team that quietly missed a number it had committed to in public would not get a second conversation here. That is a strong constraint on us.

The deliverables you are approving are complete and verifiable today: the SDK, documentation, CI/CD, the Playwright suite, the live Winks and the on-chain attribution marker.

56

Hi @winksdotfun , thank you for your responsiveness. We share the discomfort @SEEDGov raised, for two reasons we outline below. The window at play is only 30 days, which in our view is short enough that waiting it out would avoid this discussion altogether.

1. The “milestone judged unmet” comment
On Sep 25 (post #46), after adjusting the KPIs, you stated:

However, M3 as proposed is the final milestone, and the 30-day window only opens after the vote passes. If the full tranche is released on approval, “judged unmet” carries no financial consequence. It does carry a reputational cost, but with a window of only 30 days, we feel that as delegates we should be prudent with treasury disbursements.

2. Compliance with the Grant Guidelines
Current Grant Guidelines V3.3 enforced September 3rd 2026 state:

4. Terminal Milestone Withheld Until Post-Completion Review (Section 7)
A final tranche of ~30% of total grant value is now withheld until a post-completion impact review confirms delivery against the committed targets. This closes the previous gap where the final milestone had no completion gate.

Applied to this grant:

  • Total grant: $27,000 (3 × $9,000)
  • 30% holdback: $8,100
  • M3 release on approval: $900
  • Released after the T+30 review, if 12 mints / 8 wallets is met: $8,100

The current M3 request is for the full $9,000. Our understanding is that it should be submitted for $900, with the remaining $8,100 requested in a follow-up proposal once the 30-day count is reported in this thread with hashes.

This turns Winks’ own commitment into the completion gate the guidelines intend, and it gives the team a clear path to full payment if the target is met.

We remain supportive of the DOC minting integration and the progress since July. Our concern is only that the payout structure match the guidelines and Winks’ stated commitment.

1 Like
57

I support M3 given the progress made on the DOC minting integration, which is now live on X. I did notice a minor UI issue: when clicking “Connect Wallet,” the wallet selection pop-up appears partially out of frame, making it difficult to access the exit button. I believe this is a fixable issue and would encourage the team to address it.

I also agree with @DAOstar_gov suggestion that the payment structure should align with the grant guidelines. Since the 30-day adoption target has not yet been demonstrated, I think it is reasonable to release $900 upon M3 approval and withhold the remaining $8,100 until the team provides verifiable evidence that the agreed targets have been met. This would help ensure the DAO allocates its treasury funds effectively, with the majority of the final milestone payment tied to verifiable adoption.

Finally, given that the proposal is currently well below quorum, I’m concerned it may not pass. If resubmission is necessary, I would encourage the team to address the UI issue and revise the payout structure to reflect the proposed evidence-based approach.

Curia Delegate Thread
58

Hi Curia, thanks for pointing out the UI bug, we’ve fixed it now! :slight_smile:

1 Like