CoinGatewayContract #75
Description
People are going to need a way to pay across communities, without holding INTER directly.
For example, a tourist with NYC Coin may want to visit a café in Paris which accepts Paris Coin. They should see all the prices in NYC Coin, and when it comes time to pay, they should have the following happen in a single transaction:
NYC Coin -> Intercoin -> Paris Coin
But, their NYC Coin community may whitelist only certain addresses to redeem NYC Coin for Intercoin. (Whereas anyone can buy Paris Coin.)
That is why we develop a simple contract and factory: CoinGatewayContract and CoinGatewayFactory
It will have method produce(struct GatewayLimits), which takes the following: uint16 fraction, uint16 duration, uint256 globalAmount, uint16 globalDuration. (Or whatever size int makes more sense). It will have buckets w that duration and allow each individual address to withdraw that fraction of their own balance per bucket. The global limits apply across all addresses. (The fraction, of course, is so an address cannot circumvent individual limits by first sending to multiple addresses.)
This gateway can be specified during CommunityCoinFactory.produce() with parameter GatewayLimits. So all members know the rules up front. Store gateway address and limits in variable “gateway” and “gatewayLimits” respectively.
There should be a method increaseLimits(GatewayLimits) called by owners/managers role which can increase gateway limits, but not decrease them. The point of Gateway Limits is to prevent capital flight (also known as Capital Controls)
It will have a method pay(address to, uint256 amount, address inCommunityCoin) which will receive an amount of NYC Coin and an address of the destination community.
It will be able to withdraw the coin (without needing allowance permission from CommunityCoin ERC20, because it will be in a variable address gateway. That address can always call tranferFrom() to transfer communityCoin to itself successfully, but it will only do so from msg.sender so it’s safe.
After transferFrom to itself, it will call redeem() in a pool and then stake() the INTER in remote pool, receive remote CommunityCoin and send it to the msg.sender.
There should also be a method payUsingPools(address to, amount, inCommunityCoin, redeemPool, stakePool) which can be used to specify both the outgoing and incoming pool, or at least one of them. Otherwise, pay() will try all the pools in order of increasing stake duration, until it finds one that has enough redeemable INTER to withdraw. And by default it would can use any pool in the other community, since it doesn’t plan to unstake. Those INTER tokens can only be redeemed, not unstaked, by a vendor in the Paris community.