USDT trading not working
Closed this issue · 8 comments
When I try to use USDT as the base coin and BTC as target, I get an error about not able to calculate the quantity, doing a bit of digging, quantity.toFixed(quantitySigFig)
returns 0, So I hardcoded a 6 for decimal points, and I think it didn't sell at profit nor stop loss when it should during the hole night. My settings:
BUDGET=20
PROFIT_PERCENTAGE=1.2
TARGET_ASSET=BTC
BASE_ASSET=USDT
STOP_LIMIT_PERCENTAGE=1
Hi @pitxels,
I purposely made it return 0 if it was USDT. Can you report here the error?
Having the quantitySigFig
equal 0 is valid as it rounds the number to the nearest whole number.
I am currently working on the STOP_LIMIT_PERCENTAGE
issue as well.
You should also check in your repo ledger.csv
for checking if you're selling at a profit :)
The error is this:
Consuming queue... Orders in queue: 0
W.O.L.F is hunting...
Calculating quantity...
Quantity Calculated: 0
Watching watchlist... Orders in watchlist: 0
Consumed queue. Orders in queue: 0
PURCHASE ERROR: Error: Invalid quantity.
at /Users/Juss/wolf/node_modules/binance-api-node/dist/http.js:47:13
at process._tickCallback (internal/process/next_tick.js:178:7)
And the bot start the loop anyway but it does not create a buy order.
Let me put you this scenario:
I am going to trade USDT-BTC (base is usdt and target btc)
So I am going to expend 50 USDT and that will give me let say 0.006666 BTC
I will need to put BUDGET=50
and W.O.L.F calculates quantity ok ( lets say the 0.006666)
The problem is indeed what you say, you are getting a whole number out of that quantity with
quantity.toFixed(quantitySigFig)
So I am wondering now, why do you need to use whole numbers?
"So I am wondering now, why do you need to use whole numbers?"
I dont :)
My mistake. Let me give this a fix later this weekend. I need to change my logic for the significant figure rounding for quantity, rounding against the MIN_NOTIONAL filter worked previously for BTC and ETH. But not for USDT.
Here is the current logic:
get quantitySigFig() {
const sf = Number(this.filters[2].minNotional.indexOf('1') - 1);
return sf >= 0 ? sf : 0;
}
Here are the logs for the filters:
BTC: [ { filterType: 'PRICE_FILTER',
minPrice: '0.00000001',
maxPrice: '100000.00000000',
tickSize: '0.00000001' },
{ filterType: 'LOT_SIZE',
minQty: '1.00000000',
maxQty: '90000000.00000000',
stepSize: '1.00000000' },
{ filterType: 'MIN_NOTIONAL', minNotional: '0.00100000' } ]
ETH: [ { filterType: 'PRICE_FILTER',
minPrice: '0.00000001',
maxPrice: '100000.00000000',
tickSize: '0.00000001' },
{ filterType: 'LOT_SIZE',
minQty: '1.00000000',
maxQty: '90000000.00000000',
stepSize: '1.00000000' },
{ filterType: 'MIN_NOTIONAL', minNotional: '0.01000000' } ]
USDT: [ { filterType: 'PRICE_FILTER',
minPrice: '0.00001000',
maxPrice: '100000.00000000',
tickSize: '0.00001000' },
{ filterType: 'LOT_SIZE',
minQty: '0.01000000',
maxQty: '90000000.00000000',
stepSize: '0.01000000' },
{ filterType: 'MIN_NOTIONAL', minNotional: '10.00000000' } ]
found it:
(quantity-minQty) % stepSize == 0
https://github.com/binance-exchange/binance-official-api-docs/blob/master/rest-api.md#lot_size
this will be a fun weekend! looking at v3.5.0 woohoo
this branch fixes this bug.
going to merge the branch with v3.5.0
later this weekend. v3.5.0
will have better/cleaner logging and a wolf buy/sell mocha simulation test suite that will hopefully expose the STOP_LIMIT_PERCENTAGE bug at the same time.
good night fellas, see y'all sunday && monday
https://github.com/austinyearlykim/wolf/pull/56/files
view PR notes for more info! will merge in a bit.
merged, closing please oppen new bug ticket if issues persist! <3