Yup, btc/cny is like 3% out of sync with cny/USD. Huge profit to be made for us if we can get it working right.
1 Like
yes, i just figure it out. how we (the custodians) profit by this mechanism?
forget my question, i guess this is the secret for us to find out.
(whoever finds it, wins 
)
Basically, by using a bigger spread. We are doing what we should be doing, but we need to “charge” a bigger “fee” for our service by using a wider spread. We want to keep up the trade volume but take out a bigger slice for our custodians. What’s happening on bter is unfortunate because we weren’t prepared. However, it’s not ‘wrong’ per say.
My solution: very high tolerance with automated shift parameter.
1 Like
yes, but this tolerane will not be accepted by the server. you mean that instead of getting the “fees” by the server, we get them by the high spread
take a 5% profit from 6.342cny/nbt 
You can’t have one wrong in nbt/btc, nbt/cny, and btc/cny at the same time. If one is wrong, another has to be wrong/broken. Since btc/cny is wrong, it was nbt/btc had a broken wall, now it is nbt/cny.
Yah, basically my statement is the thing that’s ‘wrong’ is btc/cny and our walls are getting eaten trying to make it right (like @mhps said)
A wide spread is currently not allowed (you can still use a wide spread, im just not going to pay you for it yet). I’ll be proposing a much wider tolerance in my next grant. That’s what I mean by using spread as a solution: I mean I’m going to change the server parameters soon.
1 Like
There is a good reason for that. It is called the USD peg. The wider the spread the less we keep the peg. With very wide spreads there is also no need for the shareholders to pay for it. We should only pay for limited tight pegs.
2 Likes
i agree with Cybnate here.
we either try to profit by keeping the peg (paying by NU) or profit by wider spread (paying by speculation)
i am afraid by “using” both is too greedy 
(and destroy the peg eventually)
As described above, it’s impossible to keep both nbt/cny and nbt/btc stablly pegged while having an abnormally high btc/cny (which basically is an result of abnormal cny currency control by the PRC government).
This insight should make us think how cn-nubit is going to work. Nu might never, at least seldom, have a peg for it inside China.
OK , NBT price base on BTC/USD market , but at CNY poon ,the price base on CNY/USD from yahoo
@mhps is correct. The issue here is that there is a black market cny price that differs from the yahoo price feed. What I will be doing with this pool I hope will be generally applicable and will usher in new waves of attempts at understanding what it means to offer a peg. I have yet to have a really good dialogue about the concept of the ‘shift’ parameter and I think the only way I’ll get that conversation is by implementing it and just seeing what happens.
We have a chance to make a lot of money here. Block consensus if you like, but I think enough shareholders understand that something here both has potential to be big news and is currently broken in this incarnation.
I don’t really care about what cmc thinks nbt are worth. What I care about is that people can buy and sell nbt at fair prices. If cny is really valued 3% lower than the price feed says it is, we should be selling our nbt for that much more cny. However, that’s the obvious part. The beauty is that we need to pick up the buy side as well.
Offset>shift. With a 1% SAF I can do a 0.65% shift for a 1.5% tolerance.
The other option for automating shift is to use more price feeds to dynamically find the black market feed and simply peg to that instead of yahoo. We would need to put the server on that feed, whereas the other option keeps the server feed the same and just lets the custodians shift around it within an envelope.
You can hardly convince any (none pool op) shareholders with these jumbomumbles.
Tolerance is something shareholders can understand: it is the allowed fluctuation for the price that shareholders support. If I run a 1.5% tolerance, I could potentially be paying custodians that are buy nbt at $0.985.
SAF is spread after fees. We’ve been calling this 1% for btc pools and I’d argue that my pool is the first fiat pool to really experience a good bit of volume. Asking for a 1% SAF should not be that out of the question.
Shift is a the shift an individual custodian applies to the price, making it shift from the server pricefeed. Automating the shift parameter is a way to decrease the actual spread we see on exchange. The idea is that custodians have incentive to rebalance funds under fixed cost conditions and this is away to smoothly apply pressure to rebalance.
With these parameters, a custodian with 0 sell side on the NBT/CNY pool would be putting up orders at:
sell $1.0135
buy $0.9995
Is this the deviation in the config file? If yes why is it changeable by the user?
It is in the server config file, it is not changeable by the user.
The user currently has two parameters for trading in their client config file:
Offset
Deviation
I will be adding a third parameter to the client config file:
Shift
I intend on providing 2 things in my grant application:
Tolerance
SAF
The thing is, the operator isn’t actually in control of SAF, the participants are (within the constraints set by the tolerance). However, there is a concept of defaults and it has been shown time and time again that the LPs will basically run whatever the operator either tells them or puts in the default config files. This may change in the future, but for now the operator basically has full control over what the clients are running simply because the LPs aren’t concerned enough to change them. That’s fine for me, because I’m doing my best to ensure optimal parameters in my default files anyway. That is one of my strategies for keeping LPs on my pools: provide better software than the other pools.
some time there are 0ppm
2015/11/07-03:20:06 INFO: bter - balance: 0.76676203 rate: 0.27% ppm: 0.00011274 efficiency: 100.00% rejects: 0 missings: 0 - btc - ask: 59.4200 x 0.27% - 835BA98B-E192-47A4-82C2-EDE006C44540
2015/11/07-03:21:06 INFO: bter - balance: 0.00000000 rate: 0.00% ppm: 0.00000000 efficiency: 0.00% rejects: 0 missings: 0 - 835BA98B-E192-47A4-82C2-EDE006C44540
2015/11/07-03:22:06 INFO: bter - balance: 0.00000000 rate: 0.00% ppm: 0.00000000 efficiency: 0.00% rejects: 0 missings: 0 - 835BA98B-E192-47A4-82C2-EDE006C44540
2015/11/07-03:23:06 INFO: bter - balance: 0.00000000 rate: 0.00% ppm: 0.00000000 efficiency: 0.00% rejects: 0 missings: 0 - 835BA98B-E192-47A4-82C2-EDE006C44540
2015/11/07-03:24:06 INFO: bter - balance: 0.00000000 rate: 0.00% ppm: 0.00000000 efficiency: 0.00% rejects: 0 missings: 0 - 835BA98B-E192-47A4-82C2-EDE006C44540
What offset and deviation are you running? For it to go smoothly from paying you to not paying you like that, the price probably changed and you went outside the tolerance. At least, that’s one possibility.
deviation = 0.0025
offset = 0.005
no shift? Your settings are actually tighter than normal. Still, I’m not sure why you’re having that problem. Anything in the logs?
I’m going to be upgrading a bunch of stuff later today, there will be a server restart (a bit more than just a restart hopefully).