该用户的聊天记录定位。
I'm using a bot but I get an error that I need pUSD, I guess I need to wrap USDC. I know there are docs to do it programatically, don't we have this option to do it with one button on the website?
I'm using a bot but I get an error that I need pUSD, I guess I need to wrap USDC. I know there are docs to do it programatically, don't we have this option to do it with one button on the website?
Has there been any significant change in the API recently? Since 11:00 CET approx today my CPU usage in the VPS where I run my bot has spiked a lot
Has there been any significant change in the API recently? Since 11:00 CET approx today my CPU usage in the VPS where I run my bot has spiked a lot
But I can't withdraw yet, I cleared cache and restarted browser
But I can't withdraw yet, I cleared cache and restarted browser
Ok I just figured it out, in case it happens to anyone. I disabled V PN and it logged in
Ok I just figured it out, in case it happens to anyone. I disabled V PN and it logged in
I did that, now I can't even log in. I'm using phantom wallet in google chrome. I see some users have had issues logging in as well, could you please have a look? I get: Request Cancelled You cancelled the request. Please try again.
I did that, now I can't even log in. I'm using phantom wallet in google chrome. I see some users have had issues logging in as well, could you please have a look? I get: Request Cancelled You cancelled the request. Please try again.
<@930737463163494430> I'm trying to withdraw to USDC Solana, but I get "Something went wrong. Please try again or contact us."
<@930737463163494430> I'm trying to withdraw to USDC Solana, but I get "Something went wrong. Please try again or contact us."
btw I didn't get paid the level-up bonus
btw I didn't get paid the level-up bonus
since what date is it counting the wVolume? is it 30 days exactly, so from 23rd May?
since what date is it counting the wVolume? is it 30 days exactly, so from 23rd May?
ah I do see it now, it just appeared
ah I do see it now, it just appeared
I don't have any badge, but I should be at least bronze because I got paid taker rebates
I don't have any badge, but I should be at least bronze because I got paid taker rebates
where can I see my taker tier?
where can I see my taker tier?
Hello, anyone could have a look at this? Thanks!
Hello, anyone could have a look at this? Thanks!
Hello <@930737463163494430> , did anyone have a look at this? Thanks!
Hello <@930737463163494430> , did anyone have a look at this? Thanks!
Hello, anyone could have a look at this? Thanks!
Hello, anyone could have a look at this? Thanks!
Hello, anyone could have a look at this? Thanks!
Hello, anyone could have a look at this? Thanks!
Not exactly a bug, but most likely a non intended behaviour. "Above" markets https://polymarket.com/event/bitcoin-above-on-june-9-2026 and "between" markets https://polymarket.com/event/bitcoin-price-on-june-9-2026 should complement each other. By design, in all cryptos they exist, they have the same exact price points, which is very useful, but there is an significant "boundary risk". Let me explain with an example: I buy btc 62-64k/YES. Later I want to change this bet to btc above 62k/YES. I have two options: 1. Sell 62-64k/YES and buy 62k/YES (requires 2 trades with liquidity risk) 2. Buy above 64k/YES. With both positions I have 62-64k/YES + above 64k/YES = 62k/YES (just 1 trade in the more liquid market) In the second case, however, by the market rules I would win exactly 0 if the price falls exactly at the boundary, ie at 64k: 62-64k/YES would pay 0 because the winning market would be 64-66k (as per market rules: If the reported value falls exactly between two brackets, then this market will resolve to the higher range bracket.), and above 64k/YES would also pay 0 because the price is not higher than 64k. I'm pretty sure that the intention of these markets was to build continuous bets without these gaps. I can think of two solutions: 1. Change the "between" resolution rules: 62-64k/YES instead of resolving when price is (62, 64] it would resolve when price is [62, 64), ie instead of resolving to the upper range it would resolve to the lower range. Or, 2. Change the "above" resolution rules: instead of "has a final "Close" price **higher **than the price specified in the title" it would be "has a final "Close" price **higher or equal **than the price specified in the title. So 64K/YES would resolve as winning when price is exactly 64k I'm aware that this is a very low probability scenario, but would have huge impact if it happened, so I consider this to be a very high hidden potential risk.
Not exactly a bug, but most likely a non intended behaviour. "Above" markets https://polymarket.com/event/bitcoin-above-on-june-9-2026 and "between" markets https://polymarket.com/event/bitcoin-price-on-june-9-2026 should complement each other. By design, in all cryptos they exist, they have the same exact price points, which is very useful, but there is an significant "boundary risk". Let me explain with an example: I buy btc 62-64k/YES. Later I want to change this bet to btc above 62k/YES. I have two options: 1. Sell 62-64k/YES and buy 62k/YES (requires 2 trades with liquidity risk) 2. Buy above 64k/YES. With both positions I have 62-64k/YES + above 64k/YES = 62k/YES (just 1 trade in the more liquid market) In the second case, however, by the market rules I would win exactly 0 if the price falls exactly at the boundary, ie at 64k: 62-64k/YES would pay 0 because the winning market would be 64-66k (as per market rules: If the reported value falls exactly between two brackets, then this market will resolve to the higher range bracket.), and above 64k/YES would also pay 0 because the price is not higher than 64k. I'm pretty sure that the intention of these markets was to build continuous bets without these gaps. I can think of two solutions: 1. Change the "between" resolution rules: 62-64k/YES instead of resolving when price is (62, 64] it would resolve when price is [62, 64), ie instead of resolving to the upper range it would resolve to the lower range. Or, 2. Change the "above" resolution rules: instead of "has a final "Close" price **higher **than the price specified in the title" it would be "has a final "Close" price **higher or equal **than the price specified in the title. So 64K/YES would resolve as winning when price is exactly 64k I'm aware that this is a very low probability scenario, but would have huge impact if it happened, so I consider this to be a very high hidden potential risk.
This delay was live iirc before february, there was a 500ms. It's the strategy that gagabool probably followed, so it will become profitable again? Why did they decide to cancel the delay then, and put it back again?
This delay was live iirc before february, there was a 500ms. It's the strategy that gagabool probably followed, so it will become profitable again? Why did they decide to cancel the delay then, and put it back again?
<@707597210845446214> what's the reason behind the 250ms taker delay? Won't makers exploit this delay, placing orders and cancelling if the price goes against them within those 250ms?
<@707597210845446214> what's the reason behind the 250ms taker delay? Won't makers exploit this delay, placing orders and cancelling if the price goes against them within those 250ms?
Polymarket