Proposal to Launch SHIBA INU Market

We move to propose the listing of SHIBA INU with a settlement asset on TUSDC

In a world ruled by the commodification of time, community-based projects are more than
just a change of pace, they are a way to practice the radical acceptance of others. When
success depends on the shared strength of the individuals who make up a collective, we
are forced to shift our perspectives to align with those around us. The Shiba Inu
The ecosystem is our way of recognizing the importance of tearing down a long-established
paradigm of a formulaic success and building a path to freedom and creativity in its place.

The strength of the community contributed immensely to the transition from a meme to an actual coin.

Currently ranked 16th on the coinmarketcap rankings With roughly over 1 million token holders at the time of making this proposal and a market capitalization of approx $6,500,000,000 and a fully diluted Mcap of approx $7,000,000,000.

Benefits

  • Broadening exposure, engagement, and liquidity to Injective from The Shiba inu ecosystem partners, projects, and the community.

  • Proposed Liquidity Campaigns

  • Deposit and Trade Campaign

Objective: To increase deposits of SHIBA inu and promote trading of SHIBA /TUSDC

• Deposit a minimum of $20 worth of SHIBA to the Vega protocol to qualify.
• Trade a minimum of $120 worth of the SHIBA/tUSDC to qualify.
• Winners will share a $5k TUSDC prize pool.

Market name
SHIB/tUSDC OCT22
Code
FX:SHIB/tUSDC/OCT22

Market Settlement Asset

id": “”,
“code”: “CRYPTO:SHIBTUSDC/OCT22”,
“product”: {
“__typename”: “Future”,
“settlementAsset”: {
“__typename”: “Asset”,
“id”: “993ed98f4f770d91a796faab1738551193ba45c62341d20597df70fea6704ede”,
“name”: “tUSDC”,
“decimals”: 5,
“totalSupply”: “999991277260731”,

Risk parameter

riskModel": {
“__typename”:“LogNormalRiskModel”,
“tau”: 0.00000190128526884173,
“riskAversionParameter”: 0.01, “params”: {
“__typename”.“LogNormalModelParams”,
“r”: 0.016,
“sigma”: 0.05,
“mu”: 0

Price monitoring

“__typename”: “PriceMonitoringTrigger”,
“horizonSecs”: 3600,
“probability”: 0.9999999,
“auctionExtensionSecs”: 600
},
{
“__typename”:“PriceMonitoringTrigger”,
“horizonSecs”: 300,
“probability”: 0.9999999,
“auctionExtensionSecs”: 60

This way we are able to control the market volatility and force it to auction mode.
The aim is to narrow the gap between the auction price and the market price but we don’t mind suggestions from the community with the sole intention to aid price discovery…

Oracle source( yet to be determined)

The oracle is still yet to be determined but we will be keeping our suggestion box open to the community…

Liquidity monitoring parameters

“liquidityMonitoringParameters”: {
“__typename”:“LiquidityMonitoringParameters”,
“triggeringRatio”: 0,
“targetStakeParameters”: {
“__typename”: “TargetStakeParameters”,
“timeWindow”: 3600
“scalingFactor”: 10

1 Like

The Objective?

I need to deposit 20$ worth of SHIBA to qualify to trade or provide liquidity in the market?

Explain please?

So basically when enacted the objective is to attract enough liquidity as possible by incentivizing… this is just one of our strategy to help with that…

Not exactly to qualify to trade on the vega DEX but to qualify for the SHIB reward/incentives

1 Like

Okay.

I understand.

When to vote?

This looks cool.

I vote for this proposal.

Oracle choice= open source?

1 Like

Once all proposal inputs pass validation, community token holders are then able to begin voting.

thanks!! that wiill be appreciated!!

Might be a good idea to go open source, cheers!

1 Like

yeah!! we welcome communities suggestions with open arms

1 Like

From the risk model, what do you think is the maximum leverage for this market? and how do you account for volatility?

In liquidity monitoring parameters, explain scaling factor?

2 Likes

Good one.
SHIBA INU🤖

1 Like

the scaling between the liquidity demand estimate, based on open interest and target stake

1 Like

Good question,

Currently we do not have leverage in place or defined yet but should decide this Moving forward and with the help of our community.

We basically went with default parameters which is pretty much help us strike that balance surrounding efficiency

2 Likes

Yeah, it’s important we consider this. As I would love to the the maximum leverage in can have in this market. To avoid Liquidation :smiley:

1 Like

Absolutely…this is necessary.

I agree on the proposal to create a Shiba/TUSC marketplace. However, I have a few questions

  • Price monitoring triggers, You are choose probability are 0.9999999 both triggers. Only difference in horizon 3600 vs 300 and Auction extension 600 vs 60
    I don’t understand what difference comes from this trigger. It seems to be almost the same. So I suggest probability at 2nd trigger change to 0.9

  • I have not seen the minimum liquidity commitment required to trigger the market after being voted on.

  • The estimated time for voting on the proposal has not been detailed yet

I understand maybe this is just the initial proposal and needs to get the community’s opinion to perfect it. But can you explain or suggest

Good question buddy,

The price monitor trigger difference was set up with high volatility concerns in mind… we would have just set a single trigger to help with that but we had to back it up just incase we experience a spike. So we had to tighten it up a bit…

Good eye by the way. We decided to
Leave that out as we were relying on the network default parameters…

Maybe not a good idea but we need you suggestions?

1 Like

I almost have the same thing to say about the Price monitoring triggers.

“__typename”: “PriceMonitoringTrigger”,
“horizonSecs”: 3600,
“probability”: 0.9999999,
“auctionExtensionSecs”: 600
},
{
“__typename”:“PriceMonitoringTrigger”,
“horizonSecs”: 300,
“probability”: 0.9999999,
“auctionExtensionSecs”: 60

There are no much difference.
From the proposal it says

trigger 1 says a surge in price of about 1% up or down within 3600sec(1hr) will trigger 600sec(10 min) auction.
trigger 2 says a surge in price of about 1% up or down within 300sec(5 min) will trigger 60sec(1 min) auction.

Virtually is saying the same thing just changing duration.

So I would suggest ;
Trigger1: a surge in price of about 5% up or down within 3600sec(1hr) will trigger 3-5 min auction.
Trigger 2: a surge in price of about 10% up or down within 21600sec(6hrs) to trigger a 10 min auction

1 Like