Skip to content

Add range bar visualization and enhance position data output#40

Open
faizalmy wants to merge 1 commit into
yunus-0x:mainfrom
faizalmy:position-bar
Open

Add range bar visualization and enhance position data output#40
faizalmy wants to merge 1 commit into
yunus-0x:mainfrom
faizalmy:position-bar

Conversation

@faizalmy

Copy link
Copy Markdown
  • Introduced a buildRangeBar function to create a visual representation of position ranges.
  • Updated position data output to include a formatted profit and loss (PnL) string.
  • Added bin_step to position data for improved range calculations.

Proposed Design

Range Percentage Format

Show the percentage distance from the current price to each edge of the position's bin range:

**HANTA-SOL** | Age: 79m | Val: $38.31 | Unclaimed: $0.34 | PnL: +$0.23 (0.59%) | Yield: 15.98% | 🟢 IN | STAY
[▓▓▓▓▓░░░░░] -34% / +5%

Interpretation (for IN range):

  • -34% = price needs to drop 34% to hit lower bound (negative = downside room)
  • +5% = price needs to rise 5% to hit upper bound (positive = upside room)

OOR below (price below lower):

◀[░░░░░░░░░░] +28% / +34%
  • +28% = price must rise 28% to hit lower bound (positive = upside needed to enter)
  • +34% = price must rise 34% to hit upper bound

OOR above (price above upper):

[░░░░░░░░░░]▶ -22% / -17%
  • -22% = price must drop 22% to hit upper bound (negative = downside needed to enter)
  • -17% = price must drop 17% to hit lower bound

Bar Format (Unicode)

Use a 10-segment Unicode bar:

  • = filled segment (in-range portion traversed from lower toward active)
  • = empty segment (remaining range ahead)

IN range — active price between lower and upper:

[▓▓▓▓▓░░░░░]

Filled ratio: clamp(round((active - lower) / (upper - lower) * 10), 0, 10)

OOR — price outside range: empty bar with directional arrow.

- Introduced a `buildRangeBar` function to create a visual representation of position ranges.
- Updated position data output to include a formatted profit and loss (PnL) string.
- Added `bin_step` to position data for improved range calculations.
mrichlaz added a commit to mrichlaz/meridian that referenced this pull request Jul 2, 2026
…in % check

The heartbeat was logged when \`_pollCount % 20 === 1\`, which only
fires on counts 1, 21, 41, 61, ... The first call after every
process restart would log tick yunus-0x#1, and subsequent heartbeats
should show tick yunus-0x#21, tick yunus-0x#41, etc. But in practice the log always
showed 'tick yunus-0x#1' across 2+ hours of runtime (27 PNL_TICK lines,
all tick yunus-0x#1).

Root cause: the poller fires every 3s, and cron cycles
(management every 10m, screening every 20m) also call
getMyPositions. The count advances by ~20 every minute. But the
heartbeat only logged on count=1, 21, 41 — and the actual count
shown was always 1, suggesting the module was being re-imported
between calls (e.g. by dynamic import(\"./dlmm.js\") in
tools/screening.js or smart-wallets.js).

The off-by-one (=== 1 instead of === 0) is also a bug:
- After a fresh restart, count goes 0 → 1, heartbeat fires
  showing 'tick yunus-0x#1'. But 'tick #0' on the very first call would
  have been more accurate, and subsequent heartbeats should show
  'tick yunus-0x#20', 'tick yunus-0x#40' etc.
- With === 1, if count happens to land on 20 (instead of 21), the
  heartbeat silently misses that cycle.

Switch to \`_pollCount % 20 === 0\` so the heartbeat logs at
counts 20, 40, 60, ... and the first heartbeat after a restart
shows 'tick yunus-0x#20' (which is correct since the count was just
incremented from 19 to 20).

Note: this is a cosmetic fix. The actual PnL data flow is working
correctly (2 positions tracked, trailing TP logic, etc.) — only
the heartbeat log was misleading.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant