My comments on some of the open questions

[jtremback]

I'm very supportive of mesh security, but it needs to be done carefully. We absolutely need to avoid situations where the boundary between a secure state of the system and an insecure state is fuzzy, even if the insecure state is unlikely. This is because we are working on blockchains, and the whole point is to have (relatively) unquestionable security. Also, this module is supposed to make things more secure and this goal would be defeated by making it harder to tell if things are secure.

How to cleanly define limits for the providing chains on how much power they can have on the consuming chain? We start with a fixed number (# of JUNO), but better to do something like "max 10% of total staking power".

IMO you should keep it simple and use a single scaling factor. For example, a provider chain could have (up to) 10% of the power. This means that if 100% of the stake on the provider is cross-delegated, it contributes 10% of the voting power. If only 5% of the stake is cross-delegated, it contributes only 0.5% of the voting power.

If you do it in a way where, say, if 5% of the stake on the provider is cross delegated, it can contribute 10% of the power on the consumer (if this makes sense given the market caps of both chains), you open yourself up to a scenario where a single validator could take over the consumer chain in some situations.

Let's say that you have a consumer chain with $100mm staked natively, and provider chains with $1t collectively staked, and a collective power cap of 70% (to make an extreme example). If the consumer and the providers only have a single validator in common, this single validator will control the consumer chain, even if it has very little stake on any of the providers, simply because of the total stake size discrepancy.

Also, the dynamic scaling only really provides a benefit when not all provider delegators are cross-staked. This situation is not likely to persist for a long time since people want that yield.

I think you should use a simple linear scaling factor where power on provider * scaling factor = power on consumer.

Ensure a minimum voting power for the local stake. If we let 3 chains each use up to 30% of the voting power, and they all stake to the max, then we only have 10% of the power locally. We can set a minimum to say 40% local, and if all remote chains stake to the max, their relative powers are reduced proportionally to ensure this local minimum stake.

Seems like an unnecessary detail. Governance can just make sure that the total power of all providers does not add up to more than they are comfortable with.

How to normalize the token values? If we stake 2 million $OSMO, we need to convert that to the same $$ value of $JUNO before using it to calculate staking power on the Juno chain.

Again, this is solved by using a simple linear scaling factor decided on by governance, with enough of a margin of error that it is very unlikely that it could drop below the proportion of the provider's market cap to the consumer (the provider should always have way less power than it "deserves"). The thing that could be scaled automatically IMO is rewards sent to the consumer. This is what delegators care about.

How to properly handle slashing, especially how a slashing on JUNO triggers a slash on OSMO, which should then reduce the voting power of the correlated validators on STARS (that was based on the same OSMO stake). This is a bit tricky, IBC messages could be sent out to all consumer chains, but there could be performance implications for this.

You will need to send messages to each consumer almost every block to update powers anyway, right?