Provide feedback here for Node & Token Upgrades

[DIMO-Foundation]

Provide comments here this proposal
https://github.com/DIMO-Network/DIP/blob/main/draft%20proposals%20for%20community%20review/dimo-nodes-and-token-upgrades.md

[JosephMilo]

These are my 3 minor concerns:

1. Charging for unpairing/pairing. (You'll piss off a bunch of people trying to fix broken devices)

2. Update Perms charge. (okay as long as this cost is covered by the connecting app)

3. Idk if I missed it but there should probably be some kind of cap incase the price of DIMO skyrockets so DC costs don't equate to like $10 to mint a vehicle or something. Instead of there being a fixed DCX amount, make it dynamic in relation to a fixed USD cost of each action.

[robertsolomon]

1. Charging for unpairing/pairing. (You'll piss off a bunch of people trying to fix broken devices)

At the end of the day, there's a cost to do anything onchain. Right now, DIMO mobile pays for it and can continue to do that. Or users can do it. There's no way to do things onchain for free though.

2. Update Perms charge. (okay as long as this cost is covered by the connecting app)

I assume this will be the case ya.

3. Idk if I missed it but there should probably be some kind of cap incase the price of DIMO skyrockets so DC costs don't equate to like $10 to mint a vehicle or something. Instead of there being a fixed DCX amount, make it dynamic in relation to a fixed USD cost of each action.

DCX is also in relation to the price of USD not $DIMO. If 1 $DIMO = $1 USD then spending 1 $DIMO gets you 1,000 DCX. If $DIMO goes to $100, then 1 $DIMO just gets you 100,000 DCX... but the DCX is still always gettable for $0.001 USD worth of $DIMO. Does that make sense?

[JosephMilo]

1. Sure, but do you want the blame to be pushed onto either DINC or the hardware developers. If this system was implemented today DINC would be to blame for not only a faulty device but also charging users for needing assistance for that device. At least if you play things out, hardware providers will probably need to offer their own support considering the range of devices and the DINC/DIMO name isn't tarnished (considering they are one of the same in the consumers eyes rn)

2. Yeah, I understand the conversions but the DCX cost per action is fixed right? Meaning no matter what the conversions are, as an app developer, you couldn't effectively forecast what cost would be for x amount of actions 2 years from now because of the fluctuating market.

[benruckman]

Are there docs on more information about running a node?

[robertsolomon]

Are there docs on more information about running a node?

Not yet. The software you'd have to run to run one is still in development.

[robertsolomon]

1. Sure, but do you want the blame to be pushed onto either DINC or the hardware developers. If this system was implemented today DINC would be to blame for not only a faulty device but also charging users for needing assistance for that device. At least if you play things out, hardware providers will probably need to offer their own support considering the range of devices and the DINC/DIMO name isn't tarnished (considering they are one of the same in the consumers eyes rn)

But there is a cost today and we do pay it. This cost is just higher, but it would likely work the same.

2. Yeah, I understand the conversions but the DCX cost per action is fixed right? Meaning no matter what the conversions are, as an app developer, you couldn't effectively forecast what cost would be for x amount of actions 2 years from now because of the fluctuating market.

Yes it's fixed so that it will always cost the amount in dollars shown on the right side of the table. Meaning that the cost to do anything on the DIMO network does not get cheaper or more expensive if the price of $DIMO changes.

[JosephMilo]

1. Couldn't you integrate these fees in with the over all "protocol fees"? It would mean a bit less burn but better optics.

2. Gotcha. I must have misunderstood. Seems great to me.

[robertsolomon]

I'm not sure I follow. They are integrated with the overall protocol fees.

Or are you saying the protocol loses money when people unpair and pair? That would be a substantial attack vector where someone could drain the paymaster. It should never have no cost to the user/app, one of them should pay.

[JosephMilo]

Good point, but as it’s written the paymaster is topped up with the 40% and the remaining amount is burned. Wouldn’t this top up circumvent any risk of draining?… the only way I could see this not working is if there is not enough $DIMO being brought in to cover the pairing and unpairing fees. Adding a pairing cap then time delay would remove any risk of a spam drain. Thinking of this as more of a temporary solution to save you guys some headaches until the project integrates successfully

[heatedlime]

So there’s no actual real burn, as it appears to be all reminted? I don’t like that. At least 20% should be permanently burned, or some sort of permanent burn mechanism in place.

[robertsolomon]

So there’s no actual real burn, as it appears to be all reminted? I don’t like that. At least 20% should be permanently burned, or some sort of permanent burn mechanism in place.

Not sure how you're seeing it that way. 40% of data access fees and 100% of protocol fees burned.

[heatedlime]

So there’s no actual real burn, as it appears to be all reminted? I don’t like that. At least 20% should be permanently burned, or some sort of permanent burn mechanism in place.

Not sure how you're seeing it that way. 40% of data access fees and 100% of protocol fees burned.

I may have read it wrong. So the paragraph below a small percentage of the 40% is used to cover service costs, while the rest is permanently burned?

“40% of all DCX spent on vehicle data access fees and 100% of DCX spent on flat protocol fees is reserved for the DIMO Protocol itself. Any $DIMO that is issued to the DIMO Protocol first replenishes the small amount of resources needed to maintain the paymaster service, and then the rest is burned.”