Feature Request: flexible asset min and max amounts

[yuriescl]

Some Anchors might want to have different minimum and maximum deposit/withdrawal amounts for their assets, depending on the type of deposit/withdrawal.
For example, SEPA transfers might have a different deposit_min_amount than Cash deposits.

[yuriescl]

Asset.significant_decimals (and possibly more fields) would also require some flexibility. Depending on the transfer type, the Anchor might wanna do rounding differently.
Now I'm not sure if it's a good idea to change Polaris in order to allow those different configurations for assets.
Maybe it's better to leave Polaris as it is and let Anchors implement custom code for different transfer types.
Would Polaris be able to behave properly if the Anchor decides to use custom code for min/max amounts and also for significant decimals? Maybe there are core Polaris functions that would need refactoring to avoid conflicts related to this.

[JakeUrban]

Polaris has an assumption that there is one minimum and maximum limit for an anchored asset no matter the rails used or fee's incurred by the anchor, and I agree this is an assumption we should remove. Without thinking too hard about it, it seems like it would be a decent amount of work and involve breaking changes, at least to the data model.

This means that full support for multiple min/max pairs per asset would likely be slated for 2.0 unless we could make the change strictly additive. And unfortunately, Polaris would likely break or conflict in some way if the anchor tried forcing a different min/max pair.

Depending on the transfer type, the Anchor might wanna do rounding differently.

That seems like a red flag. The asset should always be counted in the same units and no precision should be lost.

[yuriescl]

That seems like a red flag. The asset should always be counted in the same units and no precision should be lost

You're right. The scenario I imagined doesn't really makes sense. Nevermind that.

[yuriescl]

Polaris has an assumption that there is one minimum and maximum limit for an anchored asset no matter the rails used or fee's incurred by the anchor, and I agree this is an assumption we should remove. Without thinking too hard about it, it seems like it would be a decent amount of work and involve breaking changes, at least to the data model.

The min/max amounts could be properties and call integration functions, passing both the asset and the transfer type (type parameter in deposit/withdraw calls) as parameters:

def asset_min_amount(asset, transfer_type)

This would allow the anchor to customize the amounts and not require much refactor in Polaris code.

But, Polaris is currently compliant with the SEPs, since both SEP-6 /info and SEP-24 /info return a single min/max amount for the asset no matter the type.
This discussion seems to target the SEPs, so it might be more appropriate to transfer the issue to stellar/stellar-protocol.

[JakeUrban]

I agree, reference this discussion there and we'll adjust Polaris according to the results of that discussion.