I’d like to start a proposal for helping the Polaris integration move forward before we are able to upgrade the mainnet to v201.0.X. After the upgrade, we may be able to whitelist all tokens across a specified IBC channel connection with infinite rate limits with a single line of code, but before then a manual solution is required.
Fortunately, whitelisting about 116 tokens from the Osmosis connection (channel-1) would help get this integration off the ground without the bottleneck described, and it can be done easily in a single proposal.
I’m proposing to upgrade the mainnet with this code. It can be easily read to discern the tokens for whitelist. Furthermore, I’d like to whitelist USDC (Osmosis) for gas payment, which is important for Polaris’s fee UX. The rate limits are currently set to a generic high number, in this case 1B whole units of each token (e.g. 1B ETH, 1B BTC). This can be tuned more finely if desired.
This code has been tested on Housefire testnet with Proposal #83 and this code specifically. The same tokens we would like to whitelist for mainnet are currently whitelisted on Housefire testnet. You can query the rate limits for each one with namadac query-ibc-rate-limits --token $TOKEN and can test shielding, I’ve done so a bit myself.
It would be nice to get this proposal on-chain soon if there is agreement, so please share your thoughts!
In support. Re osmosis USDC I wonder if that could cause issues with Namadillo and ibc out to different networks (we need to perhaps distinguish between Noble-originated usdc and Osmo-originated USDC).
We support it, but, actually, Osmosis is using Noble USDC, so if we whitelist Osmosis USDC (coming from Noble) to be able to pay gas fees, we would ending up having two versions/denoms of the same USDC asset in Namada - it’s not an ideal scenario.
If it’s important for Polaris’ fee UX, I think we do need to find an alternative way
@Daniel why do you think this is not an ideal scenario? I see no reason why it typically matters that much. We don’t necessarily need to expose this token for gas payment in Namadillo, it can just stay as such in the protocol. Or at some point, we just tweak the design to make it super clear where all these tokens are from.
I ultimately see zero issues doing this @preto@Daniel
Well, if everything happens behind the scenes and that facilitates Polaris` fee UX, I don’t see major issues then - it was just that if the idea was to add it to Namadillo as well, that it would confuse users when it comes to use the correct USDC while interacting with the protocol. As you said, I think the best way would be tweak somewhat the design to be able to clearly distinguish the origin chains of overall assets in general, and perhaps restricting at UI level sending those to a chain that’s not the origin one.
We support the addition of tokens. Strong integration with Osmosis assets is currently a quick way to spread Namada technology to existing DEX solutions.
Data hash on-chain: f8caf64ba1131a59882e859d39d4272230bc643c6d696f24a2241bab5f06f880
Building manual_whitelist_polaris.wasm from commit 2f5636a using earthly +build: f8caf64ba1131a59882e859d39d4272230bc643c6d696f24a2241bab5f06f880
Result: hashes match
(in case any of you want to compare Housefire against Mainnet code, see: diffchecker – in short: OSMO minimum gas price set to None and Penumbra removed due to ambiguity.)
MathNodes voted yay in favor of this proposal. If osmo/USDC is integrated into Namadillo, just give it a better display name, even “osmo/USDC” would be appropriate. Shouldn’t be any issues really.
There are ways to fix it of course, the reason for bringing it up was that in earlier versions someone managed to send usdc from one network to another making it unusable before sending back. So just wanted to note that. (as per daniel’s comment too). I’m in favor of the proposal though.
We support the addition of tokens. Strong integration with Osmosis assets is currently a quick way to spread Namada technology to existing DEX solutions.