[2602 Grant] TYKORA — Prize Vaults for DoC & USDRIF (Tropykus Yield) on Rootstock

Grants & Incentives
1

A. Project Name

TYKORA

B. Classification

Project stage: Beta (Mainnet contracts deployed; dApp running in Sandbox mode; audit-ready)

Sector: DeFi / Consumer Savings / Liquidity & TVL Growth

Target audience:

  • Rootstock stablecoin users (DoC / USDRIF)

  • Users seeking principal-protected, yield-based participation

  • Ecosystem communities (Money On Chain, Tropykus users, Rootstock DeFi participants)

TYKORA is a Rootstock-native, principal-preserving Prize Vault protocol. Users deposit DoC or USDRIF, funds are routed to Tropykus to generate yield, and only the yield is distributed to 3 winners per draw (50/30/20). Principal remains withdrawable at any time, with brief lock periods only during draw settlement.
The protocol is designed to increase sticky stablecoin TVL, drive measurable Tropykus utilization, and provide transparent on-chain prize distribution using Bitcoin-anchored randomness via the Rootstock bridge.

  • Underlyings: DoC + USDRIF

  • Winners: 3 winners per draw (50% / 30% / 20%)

  • Yield split: Prize / Treasury / Keeper (90% / 9% / 1%)

  • Draw period: 7 day

  • Withdrawals: Withdraw anytime; a lock may occur only during draw settlement (close/award/claim). Settlement depends on BTC-anchored randomness via the Rootstock bridge and may take ~60 minutes (6 BTC confirmations) before the draw can be awarded/claimed and the vault unlocks.

  • Randomness: BTC-anchored via Rootstock bridge (production); emergency/manual fallback for exceptional cases.

Submission Date

2026-02-04

Founder Information

Founder name: Jonathan Bravetti

Professional Background: JXLabs is a Bitcoin-first R&D and product studio building Rootstock-native applications focused on measurable on-chain adoption. The team has experience shipping production smart contracts and user-facing dApps, emphasizing security-by-design (testing, threat modeling, audits), operational readiness (monitoring, runbooks, keeper flows), and transparent open-source development.

LinkedIn profiles:

GitHub profiles:

Prior blockchain experience:

Built and shipped Rootstock-native systems and dApps (including BΔLT, a Bitcoin inheritance/custody-focused protocol).

Production deployment experience, contract lifecycle operations, and user-facing product delivery on mainnet.

Team

Key team members and roles:

Jonathan Bravetti
CEO & Solutions Architect
Founder of Jonxsoft and JXLabs. With over 15 years of experience in enterprise software, systems architecture, and Cryptographic integrations, Jonathan leads both the strategic vision and technical execution of the lab. His focus is on designing robust, decentralized solutions that adhere to the core principles of Bitcoin — sovereignty, transparency, and security.

Nahuel Castro
Systems Engineer – Software Development & Technical Leadership
Systems Engineer with over 10 years of experience in software development, systems integration, and technical project management.
He has led multiple development teams and projects across various industries, combining deep technical expertise with a strong leadership mindset. At JXLabs, Nahuel contributes to the overall architecture, planning, and implementation of secure and scalable blockchain-based solutions.

Agustin Ross
Systems Engineer – Full Stack Development
Systems Engineer with a strong focus on software development and full stack technologies.
He has solid experience building modern web applications, working across both frontend and backend layers with a deep understanding of system architecture and user experience. At JXLabs, Agustin contributes to the development of decentralized applications, ensuring smooth integration between blockchain logic and user-facing components.

Jessica Rubira
Licensed Publicist – Communications & Branding
Jessica oversees the project’s visual identity, brand messaging, and communication strategy. She ensures that JXLabs communicates clearly and consistently, with a focus on education, transparency, and trust in the Bitcoin space.

Previous blockchain/web3 projects:

BΔLT (Bitcoin Autonomous Legacy Trust) and other internal R&D initiatives under JXLabs.

Media & Resources

Traction & Metrics

Current user base:

Early stage / internal testers + controlled Sandbox interactions

Transaction volume:

Early stage; internal testing completed across multiple wallets and scenarios

TVL:

Early stage; internal testing Sandbox context.

Growth trajectory:

Post-audit production launch + activation phase oriented to increase stablecoin deposits and retention

Key achievements to date:

Two vault instances deployed on Rootstock Mainnet:

  • DoC (Rootstock Mainnet): 0x701e0f2C4937dc3369f5F81cE045aBF01A4a8B7D
  • USDRIF (Rootstock Mainnet): 0xc82614A59819F88681c9dA82a39ac6C536c644cD

dApp functional in Sandbox mode with deposit/withdraw + draw lifecycle flows

Public codebase structured and audit-ready for Coinspect

Operational flows implemented: close/award/claim lifecycle and keeper actions

Grant Request

Total amount requested: 20,000 USDRIF (or rBTC equivalent)

Milestone breakdown (deliverables + dates + amounts)

Timeline is expressed as “weeks from grant approval” to avoid calendar mismatch.

Milestone 1 — Independent security audit (Coinspect)

Duration: 2 weeks (Weeks 1-2)

Amount: 12,000 USDRIF (or rBTC equivalent)

Note: The 12,000 USDRIF budget corresponds to the quoted Coinspect audit fee for the TYKORA smart-contract scope.

Deliverables

Formal engagement with Coinspect for an independent audit of TYKORA Prize Vault smart contracts (DoC + USDRIF)

Audit-ready package:

  • Tagged release / exact commit hash
  • Deployment & build instructions
  • Complete test suite
  • Audit report publication (executive summary + technical details as permitted)

Remediation cycle:

  • Fixes applied
  • Expanded tests
  • Re-verification and final tagged audited release

Success metrics / KPIs:

  • Audit report delivered
  • 100% findings fixed or explicitly documented with mitigation/risk acceptance
  • Final audited release tagged and publicly available

Milestone 2 — Production mainnet launch & operational enablement

Duration: 3 weeks (Weeks 3–5)

Amount: 3,000 USDRIF (or rBTC equivalent)

Deliverables

Transition from Sandbox mode → Production mode for both vaults (DoC + USDRIF) on Rootstock mainnet

  • Disable any sandbox caps and enable production parameters (if applicable)
  • Final parameters locked + keeper runbook + monitoring + verified addresses page

Operational enablement:

  • Keeper procedures (close → award → claim)
  • Monitoring guidance + operational runbook
  • Documented parameters and safety conditions (splits, draw timing, constraints)

Public launch package:

  • Verified contract addresses + explorer references consolidated
  • Onboarding docs (“How it works”), FAQs, risk disclaimers
  • Documentation aligned with audited code

Success metrics / KPIs:

  • Production mode enabled
  • Keeper lifecycle executed end-to-end on mainnet with a published runbook
  • Launch documentation published with verified references

Milestone 3 — Liquidity & adoption activation (TVL impact)

Duration: 4 weeks (Weeks 6–9)

Amount: 5,000 USDRIF (or rBTC equivalent)

Deliverables

Activation plan executed to drive liquidity and sustained participation:

  • Coordination with Rootstock ecosystem channels and key communities (DoC/MoC, USDRIF stakeholders, Tropykus)
  • Educational content (tutorials, demos, explainers) to reduce onboarding friction

KPI reporting during the activation period:

  • TVL per vault (DoC + USDRIF)
  • Number of depositors
  • Yield routed through Tropykus attributable to TYKORA
  • Draw participation metrics + prize distribution transparency

Success metrics / KPIs:

  • Public KPI report(s) with verifiable metrics (TVL, depositors, retention proxy, Tropykus supplied liquidity)
  • Evidence of measurable post-launch growth (TVL and/or depositors and/or Tropykus utilization uplift)

Mission & Vision

TYKORA aligns with Rootstock ecosystem goals by acting as a liquidity retention engine for stablecoins on Rootstock:

  • Attracts and retains DoC + USDRIF liquidity with a principal-preserving mechanism
  • Routes deposits into Tropykus, increasing money market utilization (measurable on-chain)
  • Incentivizes longer deposit duration with recurring draws, increasing sticky TVL and activity
  • Reinforces Rootstock’s Bitcoin-first positioning through BTC-anchored randomness via the Rootstock bridge

Product Details

Core features & functionality

  • Principal-preserving deposits into Prize Vaults (DoC and USDRIF)
  • Yield generated through Tropykus; yield split into:
  • Prize pool (distributed to winners)
  • Treasury allocation (sustainability)
  • Keeper incentive (reliable operations)
  • Draw lifecycle as an on-chain state machine: OPEN → CLOSED → AWARDED → CLAIMED

Transparent analytics: Draw status, prize totals, previous winners, per-vault accounting

Technical architecture

Two Rootstock mainnet vaults:

  • TYKORA DoC Vault (underlying: DoC)
  • TYKORA USDRIF Vault (underlying: USDRIF)

Strategy contract per vault allocating funds to Tropykus

Accurate accounting via totalUnderlying() with safe fallback (kToken balance + exchange rate)

Keeper operations:

  1. CloseDraw()
  2. AwardDrawFromBtc(drawId)
  3. ClaimDraw(drawId)

Integration with Rootstock

Deployed on Rootstock Mainnet

Uses Rootstock-native primitives:

  • Tropykus for yield generation
  • Rootstock bridge BTC header access for Bitcoin-anchored randomness

Security considerations

  • Public codebase with tagged releases and reproducible builds
  • Independent Coinspect audit before production mode
  • Post-audit remediation, expanded tests, final audited release tag

Operational risk controls: runbooks, monitoring guidance, keeper incentives aligned with uptime

Description

Core problem being solved

Stablecoin liquidity is highly mobile and incentive-sensitive. Rootstock benefits from stronger retention mechanisms that keep stable deposits on-chain and convert them into sustained protocol usage.

Solution overview

TYKORA turns stablecoin deposits (DoC/USDRIF) into yield-bearing positions via Tropykus and distributes only the yield as prizes. Users preserve principal while being incentivized to keep deposits longer via recurring draws.

Unique value proposition

Rootstock-native Prize Vault primitive focused on sticky TVL

Direct utilization uplift to Tropykus via strategy routing

Bitcoin-anchored randomness through Rootstock bridge (no external randomness dependency)

Multi-stable support (DoC + USDRIF) aligned with Rootstock ecosystem liquidity goals

Competitive analysis

PoolTogether-like prize vaults exist on other chains, but TYKORA is tailored for Rootstock with:

  • BTC-anchored randomness (Rootstock-aligned)
  • Rootstock stablecoin focus (DoC + USDRIF)
  • Tropykus-first yield routing for measurable ecosystem Benefit

Project Roadmap

Week 1-2: Milestone 1 — Audit + remediation + final audited release tag

Week 3–5: Milestone 2 — Production mode launch + runbooks + verified docs

Week 6–9: Milestone 3 — Activation + KPI reporting (TVL, depositors, retention proxies, Tropykus supplied liquidity)

Performance Targets

Targets are designed to be measurable, transparent, and aligned with Rootstock liquidity goals:

TVL targets (combined DoC + USDRIF vaults):

≥ 50,000 stablecoin TVL within 8–12 weeks post-production launch

≥ 500,000 stablecoin TVL within 6 months post-launch (stretch goal, market-dependent)

User acquisition:

≥ 100 unique depositors within 8–12 weeks post-launch

Repeat participation measured via repeat depositors / average holding time proxy

Transaction volume / activity:

  • Regular draw lifecycle execution (weekly cadence)
  • Public reporting of draw participation and prize distribution events

Tropykus utilization impact:

Report supplied liquidity routed via TYKORA strategies and yield generated over time

Conclusion

TYKORA is a Rootstock-native Prize Vault protocol designed to increase sticky stablecoin liquidity, strengthen Tropykus utilization, and deliver measurable on-chain outcomes through a principal-preserving, prize-based mechanic.

We appreciate the Rootstock Collective’s consideration and welcome any questions, feedback, or requests for clarification from the community and reviewers.

Social & Community

1 Like
Rootstock Collective Governance-at-a-Glance 26-02-13
Rootstock Collective Governance-at-a-Glance 26-02-13
2

We appreciate the detailed proposal and the team’s focus on principal protection and transparent prize distribution for Rootstock stablecoin users. There are a few areas where more clarity would strengthen the case for TYKORA’s adoption.

Adoption vs lending directly on Tropykus

Since deposits are ultimately deployed into existing lending markets, what is the durable user value proposition vs users simply lending on Tropykus directly and keeping their yield? Please share any retention/participation modeling (even directional) to support that a “3 winners per week” structure won’t overly concentrate rewards and lead to churn.

Trust assumptions and resilience of BTC-anchored randomness

BTC-anchored randomness is innovative, but it introduces operational dependency on the bridge/header availability. What are the concrete procedures for downtime/delays and manipulation attempts, and what exactly is the emergency or manual fallback path? Please specify who can trigger it, what controls exist (multisig/timelock), and what transparency commitments you will follow when these paths are used.

User liquidity and failure handling

The proposal mentions brief lock periods during settlement, but does not quantify their expected and worst-case impact. What lock duration should users expect, how will it be communicated in-product, and how will disputes or settlement failures be handled? Additionally, in stress scenarios (strategy loss, stablecoin depeg, liquidity constraints), what is the explicit user-facing policy (withdrawal gating, loss socialization, etc.)?

We will continue to review the proposal structure, milestones and deliverables while waiting for the answers to the questions above. Thanks!

2 Likes
3

Hi @Tane

Thanks for the thoughtful review and the very specific questions. We appreciate the focus on measurable adoption, trust assumptions, and user experience under stress. These are exactly the areas we want to make fully explicit before moving from Sandbox to Production. Below we address each point in detail, including concrete procedures, fallback paths, and our transparency commitments.

1) Adoption vs lending directly on Tropykus

TYKORA’s durable value proposition is behavioral + UX-driven, not higher raw APY:

  • Savings primitive, not a lending UI: Many users will not optimize for “maximum APY” every week. They prefer a simple “deposit once, keep principal, auto-participate” product. TYKORA packages Tropykus yield into a consumer-friendly savings mechanic with transparent weekly outcomes.
  • Lottery-like upside without principal risk: Users keep 100% principal exposure (subject to underlying/strategy risk disclosed) while exchanging predictable small yield for chance-based upside. This mechanism is proven to improve retention in prize-linked savings formats vs standard yield-only products.
  • Sticky TVL / reduced “yield hopping”: Instead of users chasing small weekly APY differences, TYKORA creates a reason to stay through draw periods (participation + social proof via on-chain winners).

Directional retention / participation modeling (not yet production data):

  • Define weekly yield Y generated by total deposits D on Tropykus. The expected value for a user with deposit d remains proportional:
    E[user payout] ≈ (d/D) × (prize pool).
    That is, EV is not “concentrated” beyond weight-based probability; it’s a variance/experience change, not an EV transfer.
  • Concentration risk vs “3 winners/week”: We intentionally cap to 3 winners to keep the experience legible and prizes meaningful (avoids “too many tiny payouts”). However, it does increase variance. To mitigate churn:
    • We publish and show in-product “your odds” and EV estimates (based on your share of tickets and current prize).
    • We plan to track repeat depositor rate and median holding time as primary KPIs during the activation milestone; if churn is driven by variance, parameterization is available (e.g., adjust draw cadence or split structure) while maintaining the same security model.
  • Why not just lend on Tropykus? Advanced users can and will lend directly. TYKORA targets the much larger segment that wants:
    • A simple savings UX,
    • A fun/viral loop (winners feed),
    • A “set-and-forget” deposit with a clear weekly cadence.

2) Trust assumptions and resilience of BTC-anchored randomness

We agree randomness must be resilient and the trust model must be explicit.

Primary path (production)

  • Randomness source: BTC block header via Rootstock bridge, after N confirmations (currently 6).
  • This is used only to derive the seed and select winners. All winner selection is verifiable on-chain from the header data and draw snapshot.

Downtime/delay procedures (bridge/header availability)

If the BTC header isn’t available at the required height (bridge delay/outage), TYKORA does not “invent” randomness. The protocol remains in the settlement phase until one of:

  1. Header becomes available → proceed normally, or
  2. Emergency cancel triggers (see below).

Manipulation attempts (economic + operational)

  • With BTC header anchoring and confirmations, an attacker would need non-trivial capability to influence Bitcoin block production. We treat this as extremely high-cost, but still:
    • All randomness inputs are public and replayable.
    • Draw snapshot parameters (tickets, drawId, etc.) are immutable once the draw is closed.
    • Any anomalies can be audited by anyone.

Emergency / manual fallback path (explicit)

We designed two safety levers:

A) Emergency cancel (on-chain, deterministic, no winner selection):

  • If settlement is stuck beyond a defined delay, an owner-controlled emergencyCancelDraw(drawId) returns reserved yield back to the strategy and starts the next draw.
  • Trigger permissions: Owner only.
  • Controls: We recommend (and will use post-grant) a multisig owner, and can add/operate with a timelock if the Collective prefers (or commit to it as part of Milestone 2 operational hardening).
  • Transparency: When emergency cancel is used, we will:
    • Publish the tx hash and reason in the official channels,
    • Update docs/runbooks and dApp notices.

B) Manual award path (testing / exceptional recovery):

  • We have a manual award mode for environments where bridge is unset (e.g., sandbox/testing).
  • For production: we can keep it disabled or keep it behind the same multisig owner + public disclosure policy. If used, we commit to:
    • Posting the seed derivation method publicly,
    • Providing a reproducible script so anyone can verify the outcome,
    • Announcing it clearly in-product and in comms.

3) User liquidity and failure handling

Expected lock duration (normal case)

  • Settlement lock happens only during: close → award → claim.
  • In production, award requires BTC confirmations. With 6 confirmations and typical ~10 min blocks, expected time is ~60 minutes, but it’s dependent on Bitcoin conditions.
  • Worst-case: if Bitcoin is slow or bridge lags, lock can extend beyond 60 minutes.

Communication in-product

We will implement explicit UX messaging (Milestone 2):

  • A “Locked” state banner with:
    • Reason: “Settlement in progress (BTC confirmations required)”
    • Countdown/progress: current best BTC height vs required target height (already available from bridge reads)
    • Links to explorer / transparency references
  • We will display “Withdraw anytime (except during settlement)” and show lock status clearly.

Settlement failures / disputes

  • If award/claim cannot proceed due to bridge delay, keepers simply wait; funds are not moved except the reserved yield already pulled into the vault at close.
  • If the issue persists beyond the emergency delay, the emergency cancel path is used (owner multisig), funds return to strategy, next draw starts.

Stress scenarios (strategy loss, stablecoin depeg, liquidity constraints)

TYKORA is principal-preserving by mechanism, but not “risk-free.” We will publish a clear user-facing policy and disclosures:

  • Strategy loss / protocol risk (Tropykus):
    • If the strategy suffers loss, vault assets can be impacted because deposits are deployed into Tropykus.
    • Policy: withdrawals remain enabled unless an emergency mode is activated to prevent inconsistent accounting while repairs/runbooks execute.
    • We already have an Emergency Mode that blocks new deposits and draw operations, while allowing withdrawals (with tickets potentially stale until repair). After stabilization, an on-chain Fenwick repair can resync tickets.
  • Stablecoin depeg risk (DoC/USDRIF):
    • Depeg affects the real-world value of the underlying; TYKORA cannot eliminate that.
    • Policy: we do not socialize losses beyond what the underlying itself represents; users hold exposure to the underlying they deposit.
  • Liquidity constraints / redemption delays:
    • If the strategy cannot instantly redeem, withdrawals may be delayed or constrained by available liquidity (depending on strategy implementation).
    • Policy: we will document whether withdrawals are instant or best-effort based on strategy liquidity; if constraints exist, they will be surfaced in-product (status + risk text).

TYKORA’s hard guarantees are on-chain process guarantees (transparent state machine, deterministic accounting, explicit emergency paths). Financial outcomes depend on underlying + strategy risk, and we will be explicit about that in docs and UI.

We’re happy to provide any additional details or supporting materials you may need, and we remain available for further questions or follow-ups.

JXLabs team

1 Like
4

XLabs has built credibility through BΔLT, delivering ahead of schedule and completing a Coinspect audit. That execution track record should count on future projects.

This proposal really caught my attention cause I actually modeled a very similar lottery-based staking about a year ago. The behavioral thesis is solid and I think the team is onto something real. Prediction markets, betting apps, lottery-style products prove the same thing: humans don’t optimize for expected value and predictability. They chase variance and upside possibilities. At scale, a fat weekly prize pool can create massive excitement, awareness, and a self-reinforcing, exponential growth loop.

But here’s what my previous modeling revealed, and I think it’s worth discussing openly.

The math cuts both ways. At high TVLs, this thing can snowball. At low TVLs, it struggles to generate any behavioral pull at all.

Trying to run some numbers to make a point here: Assuming Tropykus yields somewhere around 5-8% APY on stablecoins, a 100k TVL vault generates roughly 100-150 USDRIF per week in yield. After the 90/9/1 split, the prize pool lands around 90-140 USDRIF split across three winners. First place takes ~50-70 USDRIF.
That’s probably not enough to generate real excitement or get shared around and go viral.

On the flip side: At 1M TVL, we’re can have a 1,000-1,500 USDRIF weekly yield, with a prize pool around 900-1,350 USDRIF. First place takes ~450-675 USDRIF per week. That can draw attention. At 5M TVL, first place is pulling 2,250-3,375 USDRIF weekly! That can easily go viral, winners telling their friends, social media posts, etc.
A massive self-feeding flywheel.

The cold-start challenge is real. Prizes stay small until TVL grows, but TVL growth depends on prizes being attractive enough to draw people in.

A few questions for the team:

  1. Have you modeled what TVL threshold makes prizes behaviorally compelling? At what point does the flywheel start to turn?
  2. Any thoughts on bootstrapping the early phase? Some protocols seed prize pools or run promotional periods to bridge this gap. Relying purely on organic yield in the early days could make traction stall and halt.
  3. Is there a contingency plan for if TVL growth is slower than expected after M3?

I think the product concept has real potential, and I’d like to understand the team’s thinking on navigating the early chasm, which I feel can potentially be brutal.

2 Likes
5

I acknowledge that this model is engaging. The prize vault mechanism can tap into a real user psychology: the desire to win.

This is also an improvement over traditional lotteries. Instead of paying for lottery tickets with a near-certain loss of principal, users here only incur an opportunity cost, the yield they could have earned. That is a much healthier framing.

However, that opportunity cost is also a downside too. If prizes are not attractive enough, and a user keeps missing the top 3 week after week, it can start to feel like their capital is just sitting idle. So the fun factor fades quite quickly.

So retention is the main risk, especially in the early phase. If TVL is low, prizes will naturally be small, and without strong marketing or some form of early boost, it may be difficult to keep users engaged long enough for the system to reach scale.

what is the minimum prize size, or TVL threshold, that you believe is necessary for users to perceive this experience as meaningfully attractive?

One small idea, assuming TVL and interest rates are high enough to support this structure. Instead of users giving up all of the Tropykus yield, perhaps they could keep a portion of it (for example 50%), while the remaining yield goes to the prize pool.

This might provide a baseline return in the first phase, while keeping the lottery style upside engaging.

2 Likes
6

@ChronoTrigger Thanks for the thoughtful modeling. We agree with the core point: this mechanism has a real cold-start challenge because weekly prizes only become socially compelling once TVL (and therefore yield) reaches a certain scale.

1) TVL threshold where prizes become behaviorally compelling (directional)

Using a simple approximation:

  • Weekly yield ≈ TVL * APY / 52
  • Prize pool ≈ weekly yield * 90%
  • 1st prize ≈ prize pool * 50%

So:

1st prize ≈ TVL * (APY / 52) * 0.90 * 0.50
At APY 5%–8%, this is roughly TVL * (0.000433 to 0.000692) per week.

That implies these rough thresholds:

  • ~$100/week 1st prize → TVL ≈ $145k–$230k
  • ~$250/week 1st prize → TVL ≈ $360k–$580k
  • ~$500/week 1st prize → TVL ≈ $720k–$1.16M
  • ~$1,000/week 1st prize → TVL ≈ $1.45M–$2.31M

Our internal view is that the “shareable / talkable” phase typically starts around $250–$500 weekly 1st prize, suggesting the flywheel becomes meaningfully self-reinforcing around ~$0.5M–$1.0M TVL, depending on APY.

2) Bootstrapping the early phase

We agree that relying purely on organic yield at very low TVL can stall, so our early-phase plan focuses on distribution + visibility loops that don’t require modifying deployed vault parameters:

  • Community activation: coordinated launches with Money On Chain/DoC community, USDRIF stakeholders, Tropykus ecosystem users, and Rootstock channels.
  • “Winner proof” as content: regular public posts highlighting winners and prize amounts (with on-chain references) to build social proof quickly.
  • Sponsored prize top-ups (transparent): third parties (partners/sponsors/treasury) can inject additional funds that are treated as extra “yield for the draw”, increasing early prizes while keeping principal fully intact. Any top-ups would be clearly disclosed and verifiable on-chain.

3) Contingency if TVL growth is slower than expected after M3

If TVL growth is slower, we won’t change the rules of the already-deployed vaults. Instead, we’ll double down on activation levers that work within the protocol’s immutability:

  • Increase the frequency and consistency of sponsored prize weeks (with explicit disclosures and on-chain traceability).
  • Expand distribution through ecosystem partners (wallets, communities, and stablecoin channels) to reduce onboarding friction.
  • Publish periodic KPI snapshots (TVL, unique depositors, repeat depositors proxy, prize sizes, Tropykus supplied liquidity attributable to TYKORA) so the community can clearly judge whether the flywheel is forming.

We agree with your cold-start framing. The early phase is about getting enough visibility and participation to reach the prize sizes where the product becomes naturally viral.

JXLabs Team

1 Like
7

@Ignas, I respectfully think at typical 5-10% annual yields, people do “feel like their capital is just sitting idle”, specially in the degen web3 universe.

I think the idea of keeping 50% of the yield, would make the yields feel even more lackluster for the user, and detract 50% of the lottery prizes, which need to grow ASAP to gain momentum.

I think you’re way overestimating human nature regarding upsides with very low chances (think about the success of betting, prediction markets, cassinos, get rich quick scams).

1 Like
8

@Ignas thank you for the thoughtful feedback. We agree that retention is the core risk in the early phase, and that the UX must remain “fun” long enough for TVL to compound.

1) Minimum prize size / TVL threshold (directional modeling)

We think users start perceiving the experience as meaningfully attractive once the 1st prize is consistently in the ~$50–$100/week range, because that’s where “variance + upside” becomes shareable and emotionally salient (even if EV is unchanged).

Using conservative, directional assumptions:

  • Stablecoin APY on Tropykus: ~6% (midpoint of 5–8%)
  • Yield split: 90% prize / 9% treasury / 1% keeper
  • Winners split: 50 / 30 / 20

That yields the following order-of-magnitude weekly outcomes:

  • TVL $100k → weekly yield ≈ $115 → prize pool ≈ $103 → 1st prize ≈ $51
  • TVL $250k → weekly yield ≈ $288 → prize pool ≈ $259 → 1st prize ≈ $129
  • TVL $1M → weekly yield ≈ $1,154 → prize pool ≈ $1,038 → 1st prize ≈ $519

So we view ~$100k TVL as the “first compelling threshold” (first prize ≈ ~$50/week), and ~$250k+ TVL as the zone where retention dynamics and word-of-mouth should become meaningfully stronger.

2) Retention framing: opportunity cost vs “idle capital”

We agree the opportunity cost can feel like “idle capital” if a user repeatedly doesn’t win. To mitigate that, the product must make two things extremely explicit in UX:

  • This is principal-preserving: users never pay for tickets and don’t risk principal via the prize mechanism.
  • The “cost” is only the yield they would otherwise keep — but that yield is what funds the prize pool (so the upside remains real, not promotional).

We’ll also keep improving in-product transparency (live prize estimate, draw countdown, previous winners/prizes, and clear messaging that 3 winners are paid each draw).

3) On the idea of users keeping part of the yield (e.g., 50/50 split)

We appreciate the suggestion, and we agree with the intention: reducing the “opportunity cost” feeling can help retention in the earliest phase.

That said, our current view is that a 50/50 split is not a good fit for TYKORA’s core behavioral thesis under typical stablecoin yields (~5–10% APY). In practice, keeping a partial yield often becomes too small to feel meaningful for users, while at the same time it reduces prize growth materially—and prize magnitude is the main driver of excitement, sharing, and the flywheel we are trying to ignite.

In other words, we believe the early-stage challenge is better addressed by making the prize upside strong and legible, and by using activation levers (education, onboarding improvements, ecosystem coordination, transparent prize boosts) rather than diluting the prize pool into a small “baseline” return.

We’ll still keep this design space in mind, but our default approach is to preserve the “full-yield-to-prizes” model to maximize momentum and clarity.

4) Early-phase retention and growth plan

We agree that organic yield alone at low TVL may not be enough. Our approach is to bridge the cold start with activation levers compatible with immutability, such as:

  • coordinated activation with DoC/MoC, USDRIF stakeholders, Tropykus community and Rootstock channels,
  • educational + demo content to reduce onboarding friction,
  • boosted prize weeks funded transparently via external sponsorships and/or protocol-aligned marketing budgets (implemented as explicit top-ups/donations visible on-chain, not parameter changes).

If growth is slower than expected post-M3, we won’t modify deployed vault rules; we will intensify these activation levers and publish KPI reporting so the community can judge traction with real data.

JXLabs team

2 Likes
9

Hi @jxlabs thank you for sharing this proposal.

I have several questions:

Sandbox metrics:

  • How many users does the sandbox currently have?

  • What is the current TVL in the sandbox?

User research:

  • What type of user research has been conducted, if any, to understand the target user segments who may want to use this prize vault?

  • Have you conducted research to validate what you wrote in an earlier comment:

  • Similarly, has this view been validated?

These are core behavioral claims about what drives user engagement and retention. The economic modeling you’ve provided is helpful for understanding the mechanics, but the retention risk depends on whether real users actually behave as theorized. Understanding what user data, research, or evidence exists to support these assumptions would help the community assess the likelihood of the cold-start strategy succeeding and whether the proposed TVL thresholds are realistic.

Looking forward to your response :slight_smile:

1 Like
10

Hi @Axia thanks for the thoughtful questions. Happy to clarify, and I agree these behavioral assumptions should be treated clearly as hypotheses to validate rather than guaranteed outcomes.

1) Sandbox metrics (users / TVL)

TYKORA has not been publicly launched yet. Up to now, the sandbox has only been used in a controlled, internal context—primarily by JXLabs internal team wallets for end-to-end testing—plus a small number of reviewers from the Money On Chain and Tropykus communities for early feedback and validation.

Also worth noting: throughout development we deployed multiple vault instances as part of iterative testing and upgrades. As a result, test deposits were moved across deployments and TVL fluctuated across versions. Across all test deployments combined, total testing TVL reached approximately ~1,500 DoC/USDRIF at peak. In the two most recent vault deployments, the current sandbox TVL is around ~100 (DoC/USDRIF total) across 6 stakeholders. These figures reflect controlled testing rather than organic usage, and will only become representative once we open the sandbox publicly.

Regarding the public announcement and “go-live”: our intention is to make the broad public launch only after the smart contracts have been independently audited by Coinspect and any findings have been remediated. Until then, we will keep access limited to controlled testing and stakeholder feedback.

2) User research

We have not run a large-scale formal research study yet (no paid panels / no survey at scale). What we have done is directional, product-driven research during development:

  • Qualitative feedback loops with a small set of stakeholders (internal JXLabs + select Tropykus/MoC contacts) focused on: clarity of “no-loss” framing, perceived excitement vs “boring yield”, trust signals, and UX friction.
  • Iterative UX testing while running the end-to-end lifecycle (deposit → draw settlement → award → claim) to identify drop-off points and messaging improvements.
  • Behavioral analog benchmarking (lottery-style savings / prize vaults / prediction & betting mechanics) to inform the core thesis: many users respond strongly to variance + upside even when EV is similar.

We treat these as inputs, not proof. The public sandbox phase (post-audit) is where we plan to validate assumptions with real user behavior and publish KPI reporting (Milestone 3).

3) Validation of the “$50–$100/week 1st prize” perception threshold

We want to be explicit: this threshold is currently a directional hypothesis, not “validated” by statistically significant user data yet.

The basis for it is:

  • observed “shareable” psychological thresholds in analogous consumer products,
  • early qualitative feedback on what feels “worth talking about,”
  • and practical expectations around stablecoin yields (5–10% APY range).

Once the sandbox opens publicly (post-audit), we will validate this empirically using:

  • retention proxies (repeat depositors, average holding-time proxy),
  • funnel conversion (visit → connect → approve → deposit),
  • engagement around prize events (award/claim visibility),
  • and user feedback loops during activation.

We’ll report this transparently as part of the Milestone 3 KPI updates.

4) Thoughts on the 50/50 yield split suggestion (baseline yield to users)

We agree the idea is thoughtful, and it’s a reasonable mechanism in some markets. However, our current view is that a 50/50 split is not a good fit for TYKORA’s core behavioral thesis under typical stablecoin yields (~5–10% APY):

  • The “kept yield” portion often becomes too small to feel meaningful for users week-to-week (especially in a high-expectation DeFi environment).
  • At the same time, it materially reduces prize growth, and prize magnitude is the main driver of excitement, sharing, and the early flywheel we need to ignite.
  • Because TYKORA vaults are immutable, we are not planning to “tune” the split in-place. If we ever explore a different split model, it would require deploying a separate vault design, which we would only consider after we have public, post-audit behavioral data indicating it’s necessary.

So, instead of mutating deployed vaults, our plan (if growth is slower) is to intensify activation levers compatible with immutability (education, distribution, ecosystem coordination, improved UX + transparency around lock/settlement, etc.), and iterate via new deployments only when data clearly justifies it.

Thanks,

JXLabs team

1 Like
11

Thanks @jxlabs for the comprehensive proposal. For the emergency multisig, do you plan to include external ecosystem guardians to minimize centralization risk and can you just confirm the Coinspect quote covers the full scope of both vaults and the bridge randomness integration?

3 Likes
12

+1 to this. I want to continue emphasizing—in this post and others—that keeping user funds safe must be a top priority for all projects receiving Rootstock Collective grants. This means implementing robust security measures including multisigs, decentralized mechanisms like ecosystem guardians, and comprehensive audits.

1 Like
13

Thanks for the questions @DAOplomats, happy to clarify.

Coinspect scope / quote
Yes: the Coinspect quote we received is intended to cover the full TYKORA smart-contract scope for this proposal, including both vaults (DoC + USDRIF) and the BTC-anchored randomness flow via the Rootstock bridge integration (close → award-from-BTC-header → claim lifecycle and related logic). The quoted cost is $11,000 USD — we’ll attach a screenshot of the Coinspect email for full transparency.

image
image1316×357 16.4 KB

Quick clarification on Coinspect scope: the quote was based on an earlier TYKORA code version (smaller scope) than the current iteration. That’s why we requested $12,000 for Milestone 1 as a conservative buffer to complete the audit cleanly. If the final audit cost exceeds $12,000 due to added scope or a delta review, JXLabs will cover the difference. We’ll also tag/freeze the exact commit audited and publish the audited commit hash + report for full transparency.

Emergency multisig & external guardians
On the emergency / manual fallback path, we agree the best direction is to reduce centralization risk. For the production rollout post-audit, we’re actively evaluating a multisig model that includes external ecosystem guardians (reputable Rootstock ecosystem participants) alongside JXLabs, so no single party can unilaterally trigger emergency actions. Our goal is to define this before switching to production mode: signer set, threshold, which actions are gated, and a transparency commitment (public disclosure + on-chain references whenever any emergency path is used).

JXLabs team

2 Likes
14

@Axia Totally aligned. Fund safety is our top priority. Our plan is: (1) independent Coinspect audit with a frozen/tagged commit and public report/commit hash, (2) production ops behind a multisig and we’re actively evaluating adding external ecosystem guardians to minimize centralization risk, and (3) clear, transparent procedures for any emergency path usage (on-chain events + public postmortem/communication).

JXLabs team

1 Like
15

Thank you for the proposal and the thoughtful replies to other delegate comments. I have three items for consideration:

1. Aligning Incentives for Long-Term Savers
Could “last-minute” large depositors attempt to game the draws? To reduce timing-based advantages and fairness risk, have you considered:
• Introducing time-weighted ticketing or averaging mechanisms to better reflect duration of participation.
• Applying a minimum holding period before deposits become fully eligible for prize draws.

2. Building Trust through Draw Discipline
To give users confidence in draw liveness and perceived fairness, the proposal and team replies appropriately emphasize clarity and transparency. To further operationalize these principles, could more measurable commitments be considered, for example:
• Targeting Execution Liveness: Aiming for ≥ 95% of prize draws to execute within 24 hours of their scheduled time.
• Manual Intervention Limits: Keeping manual draw execution as an exception (e.g., ≤5% of draws over a rolling 90-day period).
• Transparency: Any manual intervention to include a brief public disclosure within 24 hours, followed by a short explanatory disclosure within 72 hours, confirming the reason and that randomness was already committed.

3. Qualitative Learning for Milestone 3
Beyond raw TVL metrics, there is significant value in understanding consumer behavior. To strengthen the learning value of Milestone 3, additional qualitative signals could be contemplated, for example:
• User Feedback: A summary of recurring questions and feedback gathered from community channels.
• Thematic Categorization: High-level insights into UX clarity, trust in draws, and prize attractiveness.
• Driver Analysis: Identifying key frictions or motivations influencing user participation and retention.

Hope this helps.

16

@jxlabs @ChronoTrigger That makes sense. I agree at current stablecoin yields, prize size matters more than a small baseline return, splitting yield could weaken the momentum you’re trying to build.

To clarify my earlier point, I wasn’t suggesting a permanent 50/50 model. I was thinking more about a very early or optional phase, where some new users might prefer guaranteed lottery participation while still earning a small amount of yield, just to ease into the product.

But yes I understand the added complexity this introduces, both technically or in terms of user behavior. Would be interested in reviewing user behavior analytics if the proposal is approved.

1 Like
17

@DAOstar_gov Thanks for the thoughtful suggestions. Responding point by point:

1) Aligning incentives for long-term savers (mitigating “last-minute” deposits)
Yes — without mitigations, a large depositor could try to “snipe” a draw by depositing shortly before close and withdrawing shortly after settlement. For TYKORA v1, we already have a minimum eligibility/holding-period (“cooldown”) mechanism ready (deposits become eligible only after 24 hours). This avoids timing-based advantages without introducing a “dead window”: the vault remains open for deposits/withdrawals, while eligibility for the upcoming draw is determined by whether a position has aged beyond the threshold at draw close.

For TYKORA v2, we agree the “correct” long-term approach is time-weighted ticketing (TWAB-style) so winning probability better reflects duration of participation rather than just end-of-period balance. This is the direction we’d take as the protocol scales, via a new versioned deployment.

2) Building trust through draw discipline (liveness + transparency commitments)
We like the idea of turning “trust” into measurable operational targets. Once in production mode, we can commit to publishing and tracking:

  • Execution liveness target: ≥ 95% of draws finalized (close → award → claim) within 24 hours of their scheduled end time, assuming the BTC header required for randomness is available after the configured confirmation window.
  • Manual intervention as exception: manual award is strictly a fallback path; we will target ≤ 5% of draws over a rolling 90-day window requiring manual intervention.
  • Transparency SLA: if manual intervention is ever used, we will publish (1) a brief public notice within 24 hours, and (2) a short follow-up within 72 hours explaining the reason, the exact drawId and transactions involved, and confirming what randomness/commitment data was used (or why the normal BTC-anchored path was unavailable).

We can include these commitments explicitly in the Milestone 2 runbook + monitoring checklist.

3) Qualitative learning in Milestone 3 (beyond TVL)
Agreed — TVL alone doesn’t capture whether users actually “get it” and stay engaged. In Milestone 3 we can add:

  • User feedback summary: recurring questions, confusion points, and requested features gathered from community channels and onboarding.
  • Thematic categorization: insights grouped under UX clarity, perceived fairness/trust in draws, and prize attractiveness.
  • Driver/friction analysis: what motivates deposits vs what causes hesitation or churn, plus the actions we took in response.

Thanks,

JXLabs team

1 Like
18

This could be beneficial for circular economy projects, and we see strong potential synergy between TYKORA and the [2601 Grant] Circular Economies proposal by @Seviramar

We find TYKORA an interesting idea, especially since similar models like PoolTogether have shown that the no-loss lottery concept can work. TYKORA focuses on the supply side by encouraging DoC/USDRIF deposits through prizes, while Seviramar’s project focuses on the demand side by onboarding communities to borrow and use those stablecoins.

We believe these two initiatives could strongly complement each other. If TYKORA succeeds in attracting TVL, it would help reduce the liquidity availability risk for those communities in circular projects—which was one of the key concerns we raised in the Seviramar proposal.

One question we have for TYKORA: Is TYKORA currently designed to rely on a single yield source, or is it designed to support multiple yield protocols over time?

1 Like
19

Thanks @Curia — we agree with your framing. TYKORA is intentionally focused on the supply side (sticky DoC/USDRIF deposits + transparent prize distribution), and initiatives like @Seviramar circular economy proposal can strengthen the demand side by onboarding real borrowers/users. If both grow in parallel, it creates a healthy loop: stronger demand supports utilization, and stronger supply reduces liquidity-availability risk for communities.

On your question: today TYKORA v1 uses a single yield source per vault — Tropykus. This is a deliberate choice for simplicity, audit scope, and operational clarity in the first production release.

That said, the design supports multi-protocol expansion over time . Not by “mutating” already-deployed vaults, but via:

  • New vault deployments that point to a different strategy (e.g., another money market)

So: single yield source per vault in v1 (Tropykus), with a clear path to multi-protocol support via new versioned deployments as the protocol matures — and we’ll prioritize safety/auditability over complexity.

1 Like