Proposal: Bancor Repatriation Act

@lesigh @foxsteven
this idea is great.
i think that limiting it to 1 month is also great. we need to have a small window to let the users return. they bailed on a panic move and should decide now if they want to return and give bancor a chance or not.

as for the implementation:

  1. it most likely require a smart contract. reason is that you basically want to “mint” bnTokens in a ratio which is NOT based on the current pool rate. this is a risky work.
  2. we should have some type of a snapshot with all the data. this will allow every user that wants to return to see how much bnTokens he/she should expect to receive.

as for the lock/guarantee option, i think this is a mistake.
we let users return, and give them their full bnTokens.
if they want to leave after 1 week with a haircut, fine, that is up to them.
since there are efforts to close the deficit but none of which can provide guarantee to the pace in which it is closed, there is no real viable option to give these users a favorite deal and guarantee making them whole while the other LPs are not receiving the same option.

3 Likes

The only reason I was talking about a lock was to avoid a situation where:

  • Deficit decreases
  • User redeposits
  • Immediately withdraws with more tokens - that are now coming from existing LPs

If the lock adds significant complexity though, let’s scrap it.

How risky is the mint function? Is it feasible to take a snapshot & use it in a contract that contains an array with each user’s position & the number of LP tokens they could receive? It seems like this could be verified to be correct & tested before enabling redeposits. Not my expertise though :smiley:

I think we should keep it as simple as possible in order to minimize dev time associated with it - we need to focus the dev resources on future features in order to expedite rocovery.
So I’d go with the simplest solutions in that case and refrain from complex mechanics.

2 Likes

Just adding that technically I believe (first glance) it’s feasible

1 Like

It should work similar to an airdrop contract, that has the details for each wallet, and then on top of that we can add some basic logic.
All in all in terms of implementation, the snapshot is probably more complicated than the actual contract, but of course it requires detailed verification.

1 Like

I’m a fan of this idea, and I believe the pros outweigh the cons. I’d personally like to see those that left be given the option to return and hopefully, in time, have their full stacks back. I also appreciate the specifications provided regarding Snapshot, Redeposit window, & Timelock. They’re completely reasonable considering the opportunity provided.

1 Like

I’ve removed the timelock to cut down the development complexity.

@yudi any ideas that could further cut down the complexity of this proposal?

there might be some difficult decisions to be made here.

  1. as an existing user → when a user return the funds, the pool deficit will increase. this means that i might want to withdraw my funds (with a haircut) considering the returning capital and liabilities.
  2. as a returning user → this model can be games somehow. i now have a 4 weeks window to plan my return and withdraw. this will result in a risk of additional deficit.

before making further progress, this needs to be outlined and defined in such way that there is no risk of abuse.

1 Like

I think that timelock in general isn’t a problem actually. But I’d keep it relatively simple.

Preventing abuse was the reasoning behind the timelock. If it isn’t a problem in general, great - we’ll just simplify it. Two months seems like a reasonable timeframe to prevent any abuse.

I agree this still isn’t ideal for existing users - especially if the deficit were to start decreasing.

if timelock is not an issue,
consider the following:

  1. qualify → only users that withdrew their bnTokens between june 19 - july 8 (i would include block numbers as well that match with times to avoid any timezone issues).
  2. timelock → whoever take this option and return, will have to stay in for a minimum of 7 days (this can be set to any number, but i think the 7 day cooldown reference make sense here as it eliminate most aspects of planned attack).
1 Like

Hi…i think this is a great idea…I for one withdrew usdc…not because i was fleeing the protocol out of fear …i had read on bancor twitter that withdrawals were up and running again and when i did the initial transaction on metamask it said it was for the full amount so i went ahead only to receive half the amount. I would be happy to reinvest it in the protocol as i trust the team and developers to come back with a better and stronger protocol than ever. I think a month window would be fair. Anyone that doesnt want to come back can choose not to but trust must be restored and as i have previously said somewhere, your best clients are your existing ones. anyway, good luck with everything…this glitch should be used to make the team and devs more driven to make a success and not to be deterred. take your time, get it right and onwards and upwards.

5 Likes

Thanks for sharing your situation @kontigo! I imagine there are also others out there in a similar situation too.

1 Like

I agree with this - I’ll add block numbers & the 7-day timelock sounds reasonable.

1 Like

Wondering if this proposal will get moved to Layer 1? I think it is a good idea to let people return when things hopefully turn around soon.

It needs more examination regarding its implementation.

The main issue is that we need to make sure this doesn’t come at the expense of existing LPs while still creating something that feels fair to LPs who left.

It’s difficult to come up with a solution to this that is easy to implement/doesn’t require a significant system change.

2 Likes

So this is just dead right? No one is getting their money back.