Open EGreg opened 2 months ago
https://github.com/Intercoin/CommunityCoinContract/issues/75 let make an example
we have communityCoin-NY, communityCoin-Paris, TradedToken
user1 have NY-coin and want to send to user2, but the last should receive Paris-coin under hood it would be like this: a. user1 redeem NY-coins and receive tradedtoken on communityCoin-NY Contract b. user1 stake tradedtoken and receive Paris-coins on communityCoin-Paris Contract c. and finally transfer it(Paris-coins) to user2 and automatically call redeem method to user2
the first question is what will we do with lockups? we can't redeem if traded tokens locked up. this contradicts the logic of the contract
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.