dUSD setup on Kreivo

Kreivo-dUSD Integration Proposal

Executive Summary

This proposal seeks funding for three key developments to integrate dUSD into Kreivo’s payment infrastructure:

  1. Smart contract development for permissionless dUSD/KSM liquidity provision
  2. Cross-chain USDT/USDC to dUSD conversion API and frontend
  3. Virto-connect integration with Decent Partners’ Discourse

Technical Scope

1. Permissionless Liquidity Smart Contract

  • Purpose: Enable joint liquidity provision between Brale (dUSD) and KSM Community (KSM)
  • Implementation: Smart contract on pallet asset-conversion
  • Key Features:
    • Permissionless architecture to comply with Brale’s legal requirements
    • Automated liquidity matching between dUSD and KSM deposits
    • Integration with Kreivo’s existing payment infrastructure

2. Cross-Chain Conversion System

  • API Development:
    • Bidirectional conversion between USDT/USDC and dUSD
    • Support for Kreivo and Kusama AssetHub networks
    • Secure transaction handling and verification
  • Frontend Implementation:
    • User-friendly interface for conversion operations
    • Integration with Kreivo’s payment system
    • Real-time conversion rate display

3. Virto-Connect Integration

  • Implementation of Virto-connect authentication for DP’s Discourse forum
  • Single sign-on functionality
  • Secure user session management

Benefits to Decent Partners

  1. Enhanced dUSD utility through Kreivo integration
  2. Increased dUSD liquidity via permissionless pool
  3. Broader accessibility through cross-chain conversion
  4. Improved user experience with Virto-connect integration

Timeline & Deliverables

  1. Month 1: Smart contract development and testing
  2. Month 2: API development and frontend implementation
  3. Month 3: Virto-connect integration and system testing

Resource Requirements

  • Developer time for smart contract creation
  • API development resources
  • Frontend development
  • Testing and security audit resources

Success Metrics

  1. dUSD/KSM pool liquidity growth
  2. Cross-chain conversion volume
  3. User adoption of conversion frontend
  4. Virto-connect authentication usage

Budget

[To be determined based on DP treasury capacity and development requirements]

Team

Virto development team with proven track record in:

  • Kreivo parachain development
  • Payment systems integration
  • Cross-chain infrastructure
1 Like

In general lets just see this as very broad funding to be used as we need it… for priorities as they come up.

Following discussions / updates.

  1. We’ve had to go with the manual version of the LP side to expedite things after we discovered the issue with Asset Conversion Pallet only allowing liqudity to be added by a single account. See WFC: Update Kusama's asset conversion pallet to enable addition of single sided liquidity. This means we don’t need the smart contract to separate out dUSD and KSM LPs.
  2. Think we just need to get a little clearer on the cross-chain USDT/C to dUSD conversion and frontend. Does this plugin into the Virto US operation?
  3. Virto Connect is def needed asap.

Other things that we could prioritise with the funding.

  1. Issue KAB on Krievo Asset Hub (or have Kabocha as Krievo satellite chain). Tbh seems to me choice is really between minting KAB on Krievo or operating Krievo on Kabocha? The only difference is really whether KSM remains a fee token… w/ KAB on Krievo it does, with Krievo on Kabocha/KAB it doesn’t. If KAB is main trading pair for all other tokens on krievo + dUSD then it de facto becomes the main collateral of krievo economies, so perhaps this is best.

  2. Kusama burn and conditional buy backs. With 1.4.0 and burn parameters moving under OpenGov oversight we can experiment with kickstarting KSM:KAB pair with some burn derived liquidity on KSM side and same on KAB side. We then have Krievo smart contracts manage these two sides per original plan for KSM:dUSD. Additionally we develop conditional buy backs based on relative pricing of KSM and KAB. See Addressing Kusama’s alignment problem - Google Docs

Other priorities:

  • Add some sophistication to the Virto Connect integration with Discourse linking krievo memberships with forum permissions to enable organisations (beginning with Decent Partners) to set conditions on permissions. This should be reusable as research collectives emerge and each use the same basic tools / services.
  • Work on the Kabocha NFT reserve idea (cultural collateral) - e.g. research collectives pledge assets/original work to the network which then becomes narrative backing for the token.
  • Enable each research collective to easily issue their own meme token and make these all tradeable against KAB on Krievo’s asset conversion pallet. These tokens then represent the narrative potency of early stage research and development… kind of basic prediction market for new / emerging culture… like betting on a new music artist before they are famous.

How this fits together?

Taken Virto architecture and added in stuff - red stuff is new… hopefully it makes sense…

Polkadot has ‘solved’ blockchain scalability ahead of the market, but not multi-party incentive alignment.

Krievo pays for security from KSM (but KSM currently gets no exposure to any success on Krievo).

We issue KAB on Krievo and it becomes the main collateral token - e.g. every other asset on Krievo trades against either KAB or dUSD.

We give KSM access to ‘upside’ with conditional buy backs based on providing liquidity to KSM:KAB pair KAB has same model with experimental research projects it funds w/ dUSD loans setup as Krievo orgs.

Each research direction issues a ‘meme token’ that is like a simple prediction market.

Importantly this speculative token is not what the collectives rely on for spending or governance.

As the research direction is documented and evolves, it becomes more culturally impactful.

Think about this like being able to buy some stake in the future cultural impact of a unknown singer you see in a bar and fall in love with.

Kabocha makes conditional buy backs with KAB: MEMEx pairs using LP fees. What we have is a mechanism where value accrues to the parent token as/when the subtoken out performs it and this can waterfall down, ensuring growth is always supporting lower level development.

All of this drives adoption of dUSD which creates yield revenue back into Decent Partners which then completes the funding cycle…

1 Like

Really hope it would work!

1 Like