Skip to content

Latest commit

 

History

History
1715 lines (860 loc) · 228 KB

yuriy-menkov.md

File metadata and controls

1715 lines (860 loc) · 228 KB

2026-05-28 Thu: Continued development of the Site Generator service: added the admin panel with Basic Auth, OpenRouter settings, request logging, public sites gallery, improved the generated landing page schema/template/palette, and expanded e2e/unit test coverage. Also configured Docker/Fly.io deployment, added migration tooling, updated service documentation, and refined the product direction around the tribe-domain pivot.

2026-05-27 Wed: Started the ai.country repository and worked on the foundation for the Site Generator service: wrote the product vision, technical architecture, six-phase roadmap, detailed Phase 1 implementation plan, data model, API contract, and launch scope. Defined the core service flow: prompt → OpenRouter structured JSON → validation → HTML rendering → Postgres persistence → live /s/:slug page.

2026-05-26 Tue: Ran the initial ai.country brainstorm, defining the core idea of consumer AI services on premium .country domains. Explored prompt-generated websites, videos, payments, custom AI agents, affiliate storefronts, landing-page experiments, creator monetization, and the goal of retaining 1,000 users on each of 10 domains by September 1.

2026-05-25 Mon: Finished v15 wallet regime gate analysis (alternate v15) and decided not to promote it to production. The gate helped in some bear/benign windows, but failed the business bar because it hurt performance on bull recovery and missed part of the crash risk. Started v16 R&D to improve the detector, but kept production wallet hedge OFF.


2026-05-22 Fri: Fixed the backtesting issue that made earlier wallet hedge results unreliable, then re-ran validation on the production LP anchor. Confirmed the hedge logic now works and can be measured properly, but treated the feature as research-only until it proves consistent return and drawdown improvement.

2026-05-21 Thu: Closed out the v15 CBR (cost/benefit ratio) redesign with a STAY-on-v14 decision. Validated the current production setting (cb=0.030) against 14 alternatives across two market regimes (3-month bear and 9-month mixed): no configuration beat production by the required +0.5 pp NAV margin, and most bypass settings actively destroyed PnL — confirming the v14 filter is rejecting genuinely unprofitable trades, not noise. No production changes; no new risk introduced. The redesign apparatus (12 off-by-default knobs, structured bypass telemetry, 5-axis taxonomy) ships into main as a diagnostic primitive and a ready scaffold for any future CBR iteration, with the kill-criterion enforced cleanly (zero wasted compute on downstream batches). Also closed a latent backtest bug that had been silently invalidating CBR results.

2026-05-20 Wed: Drafted the v15 CBR redesign overview plan and nine sub-plans (P1 axis triage, K1..K5 P2 fine sweeps, composite verification, composite prod replay, winner inventory smoke). Defined the 5-axis taxonomy (threshold / drift / regime / time / mode) so each future CBR question maps onto exactly one knob, and scaffolded all P2 generators in TEMPLATE_ONLY mode so they can be re-armed without re-writing if a future signal motivates revisiting an axis.

2026-05-19 Tue: Fixed a BT init parity bug in the goldilocks_with_hedge backtest engine and added a regression test. Local smoke is now GREEN: the regime gate engages on the Nov 2025 crash, hard-OFF holds on benign cycles, and gated perp orders ≤ nogate. This invalidated all earlier cloud results (silent crashes in every wallet-target cycle) and unblocked re-launching the v15 canary and the five spec batches.

2026-05-18 Mon: Diagnosed the v15 validation blocker — v14 continuous wallet hedge emits 0 perp orders on the production LP anchor across 8 cloud runs / 2 LP anchors, so the gate cannot be validated end-to-end. A reserve_fraction sweep on extra_bear_oos confirmed the issue is anchor-level, not sizing. Recorded verdict RETIRE on prod LP anchor with two paths forward: re-target v15 on the v14 LP anchor with caveat, or close the v15 PR without prod deploy.


2026-05-15 Fri: Opened the v15 wallet-hedge regime-gate effort — a code-driven bear/benign detector that turns the wallet hedge OFF on benign tapes and lets continuous run only on bear tapes. Authored the Phase 0 detector research memo (three threshold candidates), expanded the validation matrix from 3 to 5 windows × 7 runs (adding fresh benign and bear OOS), and set up the local smoke scaffolding with explicit acceptance criteria.

2026-05-14 Thu: Finished the v15 "regime gate" feature for the LP-hedger strategy and got it ready for validation. The gate is a safety switch that automatically turns the wallet hedge OFF in calm/bullish markets and ON only in sustained bearish ones, so we stop paying the hedge cost when it isn't earning anything. Pushed the detector logic, the switch itself, monitoring fields, and three backtest configurations covering different historical periods (a long mixed window, a bull window, and a recent bearish window). Synced with the Aaron on the run plan.

2026-05-13 Wed: Implemented the v15 switch behind a default-off flag, so nothing changes in production until we explicitly enable it. When the market looks calm or bullish, the strategy behaves as if the hedge feature didn't exist; when it looks bearish, the existing v14 hedging logic runs as before. Walked the team through how the detector plugs into the strategy and agreed on which values to surface in logs and metrics so we can clearly see, both live and in backtests, why the gate flipped.

2026-05-12 Tue: Locked down the rules of the v15 detector before writing any strategy code. The detector decides "bear vs. not bear" from two simple market signals — the 14-day price return and the 30-day drawdown from the recent peak — with hysteresis (harder to switch into bear than out of it) and a short delay so a couple of noisy data points can't flip the regime. Reviewed the signal choices and thresholds with the team on historical data, confirmed the rule clearly distinguishes the recent bearish period from the calm/bullish ones, and deliberately picked this transparent rule over a black-box machine-learning model so the decision stays auditable.

2026-05-11 Mon: Synced with the team on the v14 strategy and agreed to put it on hold. The conclusion: the v14 wallet-hedge feature only pays off in clearly bearish markets and actively hurts performance in calm or bullish ones, and lower trading fees alone wouldn't fix that. We aligned on the v15 direction — make the strategy itself decide when the hedge should be active, with no manual market call from an operator — and wrote up the plan covering the detector approach, the historical periods we'll validate it on, and the criteria it needs to meet before going live.


2026-05-08 Fri: Closed out v14 wallet hedge redesign with a family-level memo across three windows. Verdict: PROMOTE conditionally — continuous mode gives +4.78pp funded return vs OFF on the recent drawdown tape and retains 77.7% of FULL's max-DD improvement at ~37% of FULL's perp-order count, available as an operator-driven drawdown-insurance overlay; state_table mode retired (fails the OOS_RECENT retention bar). Default stays OFF — no mainline change required.

2026-05-07 Thu: Aligned the v14 spec family 1:1 with v13 wallet_policy windows (insample / oos_bull / oos_recent, fixed hr050 / cb030 LP anchor, 5 runs per window) so v13 baseline drift can be cross-checked, and launched the three batches with Claude analysis supplements.

2026-06-06 Wed: Implemented the wallet hedge target/execution framework: residual-delta target (state_table and continuous modes) replaces the old effective_btc * scale sizing, with wallet-specific bands and cooldowns so the wallet leg no longer piggybacks on the LP hedge path or bypasses the cost/benefit filter. Added runtime visibility (wallet-target log + persistent attribution state) and ~1k lines of tests covering state precedence, the new gating, and divergence-from-FULL on benign tapes.

2026-05-05 Tue: Hit a data-access blocker on the prod-vs-backtest comparison: full prod logs are not available to us yet, so a direct log diff isn't possible. Working around it by parsing the public Telegram channel feed as the prod-side signal — extracting trade events, hedge adjustments, and regime transitions from the messages and aligning them against the corresponding backtest run's log lines. Coverage is partial (only what the bot posts to Telegram) but enough to spot the loudest divergences until proper log access is granted.

2026-05-04 Mon: Working on next leaderboard version — extending it to surface live-prod stats alongside backtest results so the current prod version is visible in the same view as its sibling backtest run, and to flag drift between the two (PnL, hedge cadence, regime distribution). Started wiring real-time analysis via AI agents to triage divergences as they appear instead of relying on after-the-fact manual diffing.


2026-04-29 Wed - 2026-05-01 Fri: Paid Time Off


2026-04-23 Thu: Finished the Leaderboard React Migration. The leaderboard now ships as a self-contained single-file build that drops into the existing deploy pipeline with zero changes — same URLs, same shareable links, same pinned sessions. Frontend and backend are now decoupled by an explicit versioned contract, so either side can evolve without silently breaking the other.

2026-04-22 Wed: Started the Leaderboard React Migration — moved the UI out of inline Python HTML strings into a proper React app, while keeping Python as the data producer and preserving the static hosting model (no backend, no asset pipeline changes). Achieved full feature parity with the old page on day one, so users see no regression.

2026-04-21 Tue: Released Leaderboard v3. Introduced a single explicit "winner" metric — Risk-adjusted APY — used as the default sort and the main chart's axis, removing ambiguity about which return column matters when comparing strategies. Made every metric self-explanatory in the UI (tooltips, formulas, glossary, inline warnings for counter-intuitive values like Cost Drag > 100% or negative Sharpe with positive return) so the leaderboard is now usable without tribal knowledge. Cut the default table from ~18 to ~10 columns, fully backwards compatible with old data and shared links.

2026-04-20 Mon: Strategy research on goldilocks_with_hedge with GPT-5.4 max. New sessions for 2025, analises, comparisions — walked through hedge sizing, rebalance triggers, and fee/spread assumptions, and asked it to identify regimes where the strategy is structurally weak (low-vol grind, sharp gap moves, funding-rate inversions) with concrete parameter adjustments rather than generic suggestions.


2026-04-17 Fri: Improved Leaderboard v2 — fixed edge cases in the new metrics (APY, ROC, fee share) on short / capital-light sessions and reordered the default columns so the most decision-relevant numbers fit on the first screen. In parallel, sliced the 2025 backtest comparison by regime (trending vs. chop, high vs. low vol) to understand where Naked Hedge's alpha actually comes from: most of the edge concentrates in higher-vol stretches, while flat regimes mostly recover fees — which framed the hypotheses for next goldilocks_with_hedge tuning.

2026-04-16 Thu: Finalized Leaderboard v2 — added test coverage for newly introduced metrics (APY, ROC, fee share) and ensured backward compatibility with historical data. Set up deployment: published dashboards now correctly resolve links to GCS folders and GitHub commits. Verified the migration path in production — existing backtest records are upgraded seamlessly without manual intervention. Opened a PR.

2026-04-15 Wed: Converted the static HTML leaderboard into an interactive single-file dashboard: added filters by version/strategy, a risk/return scatter plot, a session drill-down panel with links to GCS and GitHub commits, pinning of favorite sessions, and shareable URLs (any combination of filters, sorting, and selected session state is encoded in the URL).

2026-04-14 Tue: Tested the updated version of goldilocks_with_hedge_v11. Started work on Leaderboard v2. Introduced three new business metrics for strategy comparison: APY (annualized return — a unified basis across runs of different durations), ROC on actually deployed capital (independent of declared target size), and fee share in PnL (to quantify how much alpha is consumed by fees). These metrics are available in the CLI for sorting, and historical backtests are recalculated automatically.

2026-04-13 Mon: Ran backtests for top-performing strategies over the full year of 2025 and performed an AI-driven comparative analysis against each other and a HODL baseline (holding 100K USDC + 1 BTC without trading; NAV $193,640 → $187,631, −3.1%). All active strategies outperformed HODL in terms of total return, but only Naked Hedge delivered a positive absolute result (+$37.8K net alpha on $65.5K gross).


2026-04-10 Fri: Continued development of goldilocks_with_hedge_v10 — iterating further on the hedged LP strategy. Refined hedge adjustment logic and calibrated parameters ahead of running a full-year backtest for comparative analysis.

2026-04-09 Thu: Ran goldilocks_lp baseline backtest (5 LP variants, 10-month bear market) and analyzed results — unhedged LP returned -14.9% with 34.2% max DD, fee/IL ratio only 0.42. Compared head-to-head with hedged v9: hedge cuts drawdown 10.7× (34.2%→3.2%) and delta 91%, but adds $4.5K in costs — sole source of the hedged strategy's -2.1% loss. Both underperform USDC-only (+4.2%). Started v10 design focused on cutting transaction cost drag below 50% of fees.

2026-04-08 Wed: Completed goldilocks_with_hedge v9 — three targeted fixes over v8. Fixed the cost/benefit filter algorithm — v8 compared trade cost to notional (meaningless), v9 compares cost to delta-risk (size × price × daily vol from RV) and blocks trades where cost/risk > 0.15, filtering out rehedges that aren't justified by the exposure they correct. A/B/C/D test over 10-month bear market (BTC -29.4%): best run (Run D) returned -2.08% with 3.19% max DD. Improvement over v7-C control is modest (+0.04pp), but cost drag >100% confirms transaction costs ($4.5K) are now the sole remaining loss source.

2026-04-07 Tue: Rapid iteration — shipped v5→v6→v7 in one day. v6 added NAV drawdown guard and cost_drag_adaptive bands, cutting perp orders 46% and improving return +2.9pp. v7 replaced binary DD exit with graduated LP scaling (proportional size reduction instead of full exit), added daily cost cap and wider delta bands. Best result: v7-D at -1.94%, but v7-C (-2.12%, hedge_ratio=0.95) chosen as baseline for robustness. Key finding: transaction costs still consume 50–80% of LP fees across all versions.

2026-04-06 Mon: Built v4–v5 — core wallet hedge features: dynamic and auto wallet hedge (hedges on-chain BTC balance automatically), volatility regime scaling (adjusts hedge size by vol regime), trend-based scaling, and cost drag adaptation. Added 308 unit tests. In parallel on main: refactored batch extractor to NAV CSV as primary data source with three-basis risk metrics (portfolio/deployed/maintenance).


2026-04-03 Fri: Established the iteration workflow for hedge strategy optimization: one branch per version, each containing a batch spec + backtest analysis report committed to the repo. Switched from short 1-2 month backtests to 10-month full-cycle runs (May 2025 – Mar 2026) covering both bull rally and bear crash — this required upgrading GCP machine type due to OOM issues on smaller instances. Starting from v3 baseline which had basic vol regime gating and trend filtering but no wallet hedge, no drawdown protection, and no cost management — returning -5.7% over the test period.

2026-04-02 Thu: Ran out-of-sample validation of best goldilocks_with_hedge config on a severe bear period (Nov 2025 – Feb 2026, BTC −28.2%) using the v3 codebase. This validates the locked params (hedge_ratio=0.95, ema=0.10, wallet_hedge=0.75, trend_filter=down_only) on a different market window to confirm robustness after the v3 hedge-engine changes shipped yesterday.

2026-04-01 Wed: Released goldilocks_with_hedge_v3. Four new features: directional trend filter, cumulative LP drift tracking, regime-dependent rehedge cooldown, and regime-dependent hedge ratio. Tightened delta_band defaults based on sweep results. Added 15+ unit tests.

2026-03-31 Tue: Completed hedge optimization cycle. Best config validated on two 3-month periods: +30.3% and +20.2% portfolio returns (BTC −5.2% and −28.2%), +33–35% alpha vs buy-and-hold, NAV never below starting level. Key insight from hedge contribution analysis: 80% of realized PnL came from the perp hedge, not LP — the hedge exhibits convex payoff, turning from a modest bonus in mild downturns into the sole profit source in crashes. Identified delta drift (fixed hedge covered only 53% of exposure in crash) as the top priority to fix next.

2026-03-30 Mon: Ran first parameter sweep for goldilocks_with_hedge — 16 combinations across 4 variables. Identified winning setup: hedge_ratio=0.95, ema=0.10, cum_drift=OFF. Key finding: cumulative drift increased costs 3–4x without improving returns. Improved leaderboard sync pipeline with persistent skip-list for failed/interrupted sessions in GCS and --reset-skipped CLI flag, making batch sync recovery more reliable.


2026-03-27 Sun: Built leaderboard batch UI and sync infrastructure. Implemented sync CLI command for automated GCS session discovery with version grouping and batch save. Created Cloud Function HTTP entry point (regenerate_html) for server-side auto-refresh. Added auto-refresh HTML dashboard with meta-refresh and JS countdown timer. Wrote 9 tests covering HTML rendering and sync logic. This completed the core infrastructure for continuously updated leaderboard reporting.

2026-03-26 Thu: Tuned goldilocks_with_hedge strategy and ran batch backtest - 3-month period Sep 1 – Dec 1, 2025. Results: +17.44% portfolio return while BTC dropped 16.5%, Sharpe 1.56, Sortino 5.31, max drawdown 12.39%. Hedge was the critical component — turned a probable. Identified next improvements: hedge_ratio to 1.0 to reduce residual delta from 0.246 to ~0.10, LP regime hysteresis (2-4h stay-out), cold-start guard to eliminate day-1 churn.

2026-03-25 Wed: Leaderboard refinements (grouping edge cases, CLI help). Main focus: worked through the batch backtesting workflow following the onboarding guide (docs/batch-backtest-guide.md) -- set up GCP environment, ran local and cloud backtests, tested parameter sweeps, LLM analysis integration, and code version pinning.

2026-03-24 Tue: Finished Leaderboard implementation. Built Click-based CLI with 6 subcommands: add, list, remove, versions, html (static HTML dashboard with sortable columns, dark/light mode, group switching), benchmark (multi-strategy sequential orchestrator). Added --local mode for offline work without GCS. Registered entry point in pyproject.toml. Backward-compatible with old status CSVs.

2026-03-23 Mon: Continued Leaderboard implementation. Built GCS persistence layer for read/write entries, session discovery, and status CSV download. Implemented grouping logic — runs grouped by (start_date, end_date, target_asset) within a version, with ranking and consistency validation. Added get_release_version() to utils/version.py for git-tag-based versioning. Extended bt_output.py with 6 new metadata fields.


2026-03-20 Fri: Fixed items from Aaron's code review on goldilocks_with_hedge. Fixed 8 items: engine inheritance chain, race condition via MonitorsMixin, hedge cooldown, retry in _close_hyperliquid_positions, user_state pass-through, risk tracker labels. Deferred 12 inline items (legacy naming, config overrides duplication, BT/live signature mismatc).

2026-03-19 Thu: Fixed code review comments from Aaron on the hedge strategy — cleaned up adjustment logic and logging in check_and_correct_hedges. Pusged final version for hedge strategy. Continued Leaderboard work. Added filtering to exclude incomplete/cancelled runs from comparison.

2026-03-18 Wed: Started designing the Leaderboard feature for backtesting results comparison. Researched approaches for strategy versioning — hashing algorithm configs to identify unique strategy versions and enable comparable runs across team members. Drafted initial schema for organizing backtest runs into named session folders with metadata (date range, strategy hash, completion status).

2026-03-17 Tue: Continued tuning the goldilocks_with_hedge strategy parameters. Experimented with different delta_band_entry_mult / delta_band_target_mult ratios and lp_base_ema_alpha values to reduce unnecessary re-hedging while maintaining hedge accuracy. Ran backtests across multiple monthly periods to compare hedge PnL contribution. Investigated cases where hedge adjustments were being triggered by noise in LP base amount readings — the EMA smoothing helps, but alpha sensitivity needs further calibration.

2026-03-16 Mon: Added an option to use passive limit orders instead of market orders for hedge trades on Hyperliquid, aiming to reduce slippage costs. Implemented config fields (lwh_use_limit_order, lwh_limit_order_timeout_seconds) with TOML/env support. Backtest comparison showed a small improvement in hedge PnL with limit orders on liquid pairs.


2026-03-13 Fri: Fixed backtest freezes that occurred when closing very small residual hedge positions (floating-point dust). Applied the near-zero size check (_position_size_is_effectively_zero) consistently across all position closure code, not just the wait loop. Added notifications for successful close trades.

2026-03-12 Thu: Investigated backtest issues and resolved freezes occurring during the closing of micro-positions by adding handling for floating-point dust. This prevents the closing loop from triggering false timeouts when the hedge is already effectively closed. Currently debugging and analyzing the causes of lower PnL compared to the original strategy.

2026-03-11 Wed: Implemented a draft version lp_with_hedge strategy as an extension of goldilocks_steady_lp. The steady LP entry/exit logic was preserved, while adding an automatic delta-hedge via Hyperliquid perpetuals when the position moves outside the configured delta_band. In parallel, added configuration and strategy registration for both live trading and backtesting, restored the missing hedge logic, and separated the final performance statistics into two components: LP fee income and hedge PnL (both components are still included in the overall PnL/APR).

2026-03-10 Tue: Discussed new goals with the team: developing an LP strategy with an integrated hedge. Conducted research on the current hedging approach used in the latest versions of the strategy.

2026-03-09 Mon: Observed the live lp-heger service stats and tracking its performance. Running backtests over the same date ranges as the live service to compare results and validate strategy behavior. Conducting parameter searches to identify the best configuration for the goldilocks steady strategy.


2026-03-06 Fri: Wrote a test that runs the goldilocks steady strategy with several presets derived from earlier sweeps, mainly varying entry/exit percentiles (around 0.20/0.60), the RV window (36h), and the drift exit threshold (20–30%). Other features such as trend filters, pnl_stop, and fee_il were disabled since previous tests showed no improvement. The test runs month-by-month to compare performance across different market periods.

2026-03-05 Thu: Added a script to generate parameter presets for each of the four top strategies. Currently running 48 sessions to collect parameter performance statistics. After the backtest server update and LP hedge update, strategy execution time increased to ~1 hour. Investigating and working on a fix.

2026-03-04 Wed: Implemented a script that automatically runs the top strategies monthly and generates a report with PnL, APR, and execution time. Current results show ~1–2% APR, despite positive PnL each month. The current top-performing strategy is Goldilocks LP.

2026-03-03 Tue: Running backtests for all strategies for the month of September and comparing results by profit and APR. So far, Goldilocks Plus is leading with approximately 5% APR. Hedge Optima is showing a positive PnL, while Naked Hedge remains consistently negative.

2026-03-02 Mon: Synced with Aaron regarding missing Aerodrome price data in the remote database. Local backtesting for the Naked Hedge strategy has been restored. Continuing development and testing of the Hedge Optima strategy.


2026-02-27 Fri: Investigating errors during local strategy execution during backtesting. The Goldilocks LP strategy is currently being tested. The issue with local execution of strategies dependent on Aerodrome price feeds remains unresolved.

2026-02-26 Thu: Researched issues affecting strategy execution in the local LP backtesting environment. Part of the problems were resolved by switching the pricing source from Aerodrome pool prices to Hyperliquid prices, but the strategy is still producing zero PnL. Re-synchronized the local database and continue testing.

2026-02-25 Wed: Started migrating the hedger manager service strategy to the backtesting engine. The strategy is able to run, but currently produces errors, resulting in zero PnL across all backtest runs.

2026-02-24 Tue: Synced with Aaron and the team on local setup of the LP backtesting framework and the LP hedger. Updated the system environment and installed required utilities to support the new version. Familiarized myself with the core strategies and their intended behavior.

2026-02-23 Mon: Improved the gov indexer. To enable full Docker integration, added a feature that persists the latest synchronized block into a dedicated database table upon receiving a shutdown signal. Error handling was refactored, and additional validation for detecting and recovering missing blocks was implemented. The final version has been launched for testing using the standard startup command.


2026-02-20 Fri: Indexer improvements for gov.harmony.one. Researched issue causing the indexer to restart and crash when a block could not be fetched from a public RPC. Configuring fly.io to save latest sync status to speed up sync tyme after reboot. Researched auto restart issue. Research of Aaron’s updates related to the new LP backtesting dashboard.

2026-02-19 Thu: Published a basic, fully functional open-source version of gov.harmony.one to enable further development by the community. The goal is to keep a minimal working version and allow the community to add new features. UI connected to smart contracts and the indexer API. Current deployment status: UI — production, Smart contracts — deployed, Indexer — running on Fly.io. Community members can also submit UI changes for us to deploy.

2026-02-18 Wed: Comparison of backtesting statistics vs live copy-trading bot performance. Performed a step-by-step transaction analysis together with Rika. Identified the root cause of discrepancies: positions that are opened and closed within the same block are ignored in backtesting, while in the live bot they are executed with a delay.

2026-02-17 Tue: Analyzed the statistics for 3 days collected from the copy trading bot. The number of positions, average holding time, and average position size are all in line with expected values. Action execution delays range from 1 to 3 blocks depending on the specific scenarios. Alchemy was disabled due to excessively high costs. Switching to quick node rpc.

2026-02-16 Mon: President's Day


2026-02-13 Fri: Complete several fixes to the copy trading bot, focusing on optimizing Alchemy RPC requests to reduce traffic and operational costs. A new version was deployed to the production environment for testing over the weekend. Also researched community-reported issues related to the Harmony Snapshot X voting service and reconfigured the indexer accordingly.

2026-02-12 Thu: Completed another iteration of fixes for missed positions in the copy-trading bot: unified transaction submission through a single shared NonceManager, added serialized transaction sending, implemented automatic resetNonce + retry logic for nonce/fee-related errors, and introduced a more aggressive and configurable EIP-1559 fee policy to eliminate replacement fee too low errors and reduce the risk of gapped nonces. Tested the changes using a new target wallet.

2026-02-11 Wed: Synced with the team on recent updates from Aaron. Discussed the possibility of migrating the LP hedger script to the backtesting infrastructure. Reviewed new backtesting updates and documentation provided by Aaron.

2026-02-10 Tue: Investigated the root cause of partial position losses in the copy-trading bot. The issue affected less than 1% of positions but caused discrepancies between live results and backtesting. Fixed the mechanism for determining the maximum gas per transaction and added a nonce queue.

2026-02-09 Mon: Analyzed the copy-trading performance over the weekend. Compared backtesting results with the real script execution by manually reviewing transactions. Conducted a code review of the backtesting script. Investigated an issue related to creating a new proposal in the Snapshot-based voting service (Snapshot X).


2026-02-06 Fri: Tested a new operating mode of the copy-trading bot with token rebalancing based on fixed limits. Prepared a build for weekend testing. Synced with Rika on the source code to adjust event-based backtesting logic to better approximate real copy-trading behavior.

2026-02-05 Thu: Reviewed Aaron’s new backtesting documentation and configured integration with the shared backtesting service via the public API. Tested basic hedging scripts. Deployed the fixed version of the copy trading bot with a new target address. Ongoing testing and continued comparison against backtesting results.

2026-02-04 Wed: Researched available OpenClaw capabilities and explored the feasibility of using OpenClaw as an execution layer for the automated trading system on Aerodrome Finance. Compared live copy trading bot results with backtesting outcomes; performed a manual transaction-level analysis of discrepancies together with Rika.

2026-02-03 Tue: Continued work on the copy trading bot: fixed an issue causing token imbalance in the contract deposit after several hours of opening deposits with non-proportional ratios. Added new limit-based swap logic.

2026-02-02 Mon: Reconfigured and relaunched the copy-trading bot services with new parameters to mirror Rika's address based on backtesting results. Researched documentation and repositories for the OpenClaw AI agent and x402, and explored potential integration options for trading using the ONE/USDC pool on Aerodrome (Base mainnet). Compiled a list of questions covering both implementation details and overall system architecture.


2026-01-30 Fri: Continue testing hedge manager service on Hyperliquid testnet with multiple instances. Configured deploy on fly.io, working on api to load real time statistic. Received updated backtesting setup instructions from Aaron and am currently reviewing them.

2026-01-29 Thu: Completed the setup and integration of the hedge manager service with the Hyperliquid testnet, running multiple strategies in testing mode. Deployed the strategy on the staging environment. Reviewed backtesting results provided by Rika.

2026-01-28 Wed: Evaluated data synchronization approaches (QuickNode streams, RPC, Alchemy) to improve local sync performance; Alchemy performed best for historical event ingestion via getLogs. Waiting for LP backtest updates from Aaron. Continued testing the hedging strategy on the Hyperliquid testnet.

2026-01-27 Tue: Switched the local LP backtest server build to a new RPC endpoint provided by Aaron, along with an updated configuration set. Snapshot synchronization of LP positions is still excessively slow, which prevents obtaining a complete dataset for local strategy testing. Currently discussing with Aaron the possibility of running a shared lp backtest instance on a virtual server.

2026-01-26 Mon: LP backtest server improvements for local execution: replaced Etherscan API calls with Alchemy Base RPC and tuned parameters to resolve synchronization issues. Tested running LP backtest against a remote database with preloaded data. For this, session logging logic was modified to avoid any database writes and comply with a read-only access policy. There is still insufficient data to compare the results of real hedging with backtesting.


2026-01-23 Fri: Exploration of using lp_hedger together with the backtest server to emulate strategies. Review of existing adapters and porting them into the hedge manager service project to validate a baseline strategy on the LP backtest server. Initiated historical data export for the backtest server covering the last month.

2026-01-22 Thu: Researched lp_backtest and lp_hedger repositories received from Aaron. Configuration and setup of the LP backtest server for local execution. Launch of lp_hedger against real chains, including account and wallet configuration.

2026-01-21 Wed: Explored the possibility of using platforms with test wallets (Hyperliquid testnet, Bybit) to perform hedging service while testing multiple strategies in parallel without risking capital. The hedging service was optimized to support running multiple strategy instances in parallel using a shared dataset.

2026-01-20 Tue: Monthly backtesting of the updated hedging strategy was conducted for the period from July to August. The results showed a negative average monthly PnL of approximately -4%. Further AI-assisted analysis recommended increasing the tick range and buffer width, as the losses were primarily driven by an excessive number of small trigger events that were frequently closed at a loss. Working on encapsulating the strategy logic so that AI agents can change and restart it automatically and check backtesting results.

2026-01-19 Mon: MLK Holiday


2026-01-16 Fri: Improved hedge strategy to better emulate real-market conditions. The main adjustments included price latency simulation (price divergence relative to Hyperliquid) and funding costs — modeled as an hourly fee for maintaining an open hedge position. Testing and comparison against results from real trading sessions.

2026-01-15 Thu: Investigated the issue where the Hyperliquid position entry price differs between live trading (market execution) and historical backtesting. To make backtesting more realistic, introduced an execution delay (2-block delay). Historical backtests now assume the worst-case execution price. Updated backtesting scripts.

2026-01-14 Wed: Sync with the team, researched Aaron's updates. Also investigated the case of hedging deposit loss during prolonged price consolidation within the range. It appears that profits are generated only when the price moves unidirectionally toward one edge of the tick range. In all other scenarios, losses occur due to repeated position openings and closings. Exploring ways to improve the strategy to mitigate this problem.

2026-01-13 Tue: Conducted an additional testing session with the LP amount parameter increased to 2,000. Calculated the exact delta corresponding to the hedged position. Exiting the range requires hedging approximately half of the LP deposit, while the PnL from this position is about 0.2%.

2026-01-12 Mon: Published a service update enabling historical data extraction via RPC and its integration with analytical scripts. Conducted in-depth research with the assistance of AI, investigating the root causes of PnL discrepancies when analyzing data across different strategies and real data. Additionally, analyzed the reasons behind the low or near-zero PnL observed in the latest test with 1× leverage. Merged strategy fixes from Rika into the main service.


2026-01-09 Fri: Exported historical data for the duration of a real trading session and performed analysis using analytical scripts from both the legacy strategy and the real-time strategy. The results were compared against actual data from Hyperliquid, revealing a 20–30% discrepancy in PnL.

2026-01-08 Thu: Hedge manager service was relaunched for 20 hours with x1 leverage and increased deposit $1000. Comparison showed that the strategy is fully replicated in terms of: number of opened positions, position direction, entry timing. The only differences observed were the hedge entry prices and the resulting total PnL.

2026-01-07 Wed: Partial fixes applied and hedge manager relaunched for two 9-hour sessions to collect statistics: $90 PnL from Hyperliquid (x10 leverage), $37 theoretical PnL (x1 leverage), 6 LP positions, 78 hedge positions. Further debugging and analysis were performed to identify the root causes of the PnL discrepancies.

2026-01-06 Tue: Continue work on hedge manager improvements: fixed a bug related to position closure when exiting the range, exntended logs, corrected model settings to stay within the deposit limits. Continue real time testing.

2026-01-05 Mon: Team sync and investigation of long-term issues in the service’s hedge manager. Identified problems include: the strategy calculating an excessively large delta, exceeding deposit limits, and discrepancies in BTC pricing originating from Hyperliquid swap executions.


2025 Q4 Review

Copy Trading Bot

The primary development focus this quarter was the copy-trading bot. First built a basic version that replicated position openings and closings, and then an advanced version capable of copying staking actions and operating through a smart contract. The smart contract enables efficient batching of multiple actions—such as opening a position, approving a token, and staking—into a single transaction. Also conducted research and optimization to ensure the bot operates reliably with flash blocks and accelerated event processing, resulting in the ability to react to target-strategy events within the same block.

A large amount of statistical data was also collected from various wallets as well as during the testing of the copy-trading bot. Together with the team, we performed an in-depth analysis and refined our understanding of the optimal wallet for copy — specifically, the parameters related to position duration and the amount of capital managed by a wallet. At this stage, we have identified a target wallet to copy, currently demonstrating a positive APR of 120%.

A statistical analysis identified a set of parameters for filtering wallets suitable for copy-trading: median position duration of 10–100 blocks, deposit size no greater than 5% of the pool’s liquidity, and an APR above 50%. Several wallets matching these criteria have now been found — we are currently using one with an annual APR of 150%. Additional tools were also added to compare wallet operations in real time.

Q1/2026 plans: Adding hedging functionality to the copy-trading bot and integrating it with a hedging-analytics service to enable real-time long and short position generation. Expanding the collection of hedging-related statistical data to develop a more robust and profitable strategy.


2025-12-31~2026-01-04: New Year's, no team sync

2025-12-30 Tue: Synced with the team on the latest version of the hedge manager service. Log analysis: reviewed basic scenarios with price increases/decreases and corresponding delta position adjustments. Also analyzed the discrepancy between theoretical and realized PnL caused by theoretical delta values going out of the acceptable range for opening hedge positions via the Hyperliquid service.


2025-12-26 - 2025-12-29: Christmas, no team sync.

2025-12-25 Thu: Launched hedge manager in a 24-hour test and identified an issue: when the price trends strongly in one direction for an extended period, the hedge position keeps increasing, eventually exhausting the Hyperliquid margin balance. This leads to desynchronization between theoretical and actual hedge data. To address this, I adjusted the strategy to operate within a narrower range so that LP and hedge positions are reopened more frequently, allowing profits to be realized more often. Testing is ongoing.

2025-12-24 Wed: Hedge manager improvements: enhanced the hedge manager by implementing extended logging logic, including a comparison between delta exposure and the calculated hedge position size (both theoretical and actual). Performed testing with 10x leverage to improve responsiveness to strategy-generated events.

2025-12-23 Tue: Reviewed Rika’s merge request and applied fixes related to leverage handling. Fixed the BTC position size calculation, corrected the position-closing logic when the trade direction changes. Calculated optimal liquidity usd amount compatible with hypeliquid deposit.

2025-12-22 Mon: Added separated logging in the hedge manager service for: hedge positions opened via Hyperliquid, and positions calculated theoretically based on swaps using the original hedging strategy. Project files and logs were exported and uploaded to AI for further analysis and discussion with the team.


2025-12-19 Fri: Fixed the position opening logic. Applied updates to the hedging strategy and extended the hedge manager service to support containerized execution on fly.io. Configured deployment and persistence of statistics in the database.

2025-12-18 Thu: Tested the new hedge manager service and fixed issues related to hedge delta calculation and the timing of Hyperliquid API calls. Shared the source code with Rika. Added file-based logging with a 30-second interval.

2025-12-17 Wed: Completed the first version of the Hedge Manager service — a full real-time hedge position management loop based on the core hedge strategy. Swap events are received in real time via Alchemy WebSockets; the strategy then calculates hedge delta and other metrics and decides whether to open or adjust positions, after which the Hyperliquid API is called.

2025-12-16 Tue: Implemented a real-time version of the hedging strategy (analytics engine only, without position execution). The strategy is now an isolated service that processes swap events sequentially and makes hedging decisions on every step. Testing is still performed on historical data. Continued general code refactoring. Conducted research on the Hyperliquid API for real-time position execution.

2025-12-15 Mon: Continue working on migrating the current hedge strategy from historical backtesting to real-time execution. Several critical issues were identified in the hedge position handling logic: open positions were ignored when price moved out of range, positions were not closed when price direction changed, and other related edge cases. Began refactoring the hedging script into a class-based architecture to enable integration with external services.


2025-12-12 Fri: Synced with Li regarding new steps. Started working on adapting the hedging script for real-time operation — consuming all swap data via WebSocket, constructing virtual positions, and making hedging decisions using the median strategies that demonstrated the best performance.

2025-12-11 Thu: Reviewed Rika's latest hedge script version. Tested median strategies with different window parameters (10 / 20 / 50) and compared monthly statistical results. The most effective configuration was the median strategy with a 50-swap window, which almost completely filters out random price spikes.

2025-12-10 Wed: Researched new median and spike strategies for swaps filtering; hedge script review and data output validation. Analysis of September hedging data.

2025-12-09 Tue: Investigation of the incorrect IL calculation issue. Testing of the new hedge-log script. Work on an alternative version of position generation based on a given set of swaps.

2025-12-08 Mon: Review of the new hedge-log script version. Data export for August–July and generation of IL and hedge PnL estimates. Debugging and analysis of the causes behind the inflated results.


2025-12-05 Fri: Completed the test suite for the hedging sprint: generated a set of swap events with predictable outcomes for creating long and short positions, as well as pre-calculated PnL results. Performed a final validation of the scenario where market direction switches from upward to downward movement. Identified several problematic areas in the script.

2025-12-04 Thu: Continued working on tests for the hedging script and expanded logging to better understand the conditions and timing of position openings and closings.

2025-12-03 Wed: Reviewed Rika’s PR introducing new columns. Verified the generated data with the team. Analyzed the new logs, including values for current price tick, center price tick, buffer size in ticks, hedge step size in ticks, and distance from buffer.

2025-12-02 Tue: Conducted a deeper investigation of the hedging script’s source logic. Identified a condition where a change in price movement dynamics causes PnL to be recorded as positive instead of correctly registering a loss. Began writing tests to validate this hypothesis.

2025-12-01 Mon: Launched the script using Aaron’s database to collect data for October. Compared the resulting outputs with the team and performed a detailed log review.


2025-11-28 Fri: Received an updated instruction set from Artem and attempted to run the hedging scripts. Fixed several technical issues to started scripts localy related to the migration process and database connectivity. Currently diving into advanced hedging cases involving multiple rebalances as BTC price direction shifts.

2025-11-27 Thu: Studied the portfolio manager repository and the hedging scripts. Received updated wallets statistics from Rika. Selected a wallet with medium traffic intensity and a long duration time for copy trading - testing now.

2025-11-26 Wed: Switched to studying the hedging project. Looked at theoretical documents provided by Artem and reviewed simple hedging cases using real positions.

2025-11-25 Tue: Investigated why some copy-trading bot transactions are not included in the same block as the target transaction. One major reason is that the target transaction often appears near the end of the block. In some cases, even when both transactions land in the same block, there is still a gap between them, during which swap events may occur and change the ratio. There is also a suspicion that Alchemy’s flash-block pool does not include transactions from all wallets in the chain (since some wallets appear with a larger delay). Currently researching this issue.

2025-11-24 Mon: Continue testing copy-trading bot with high-traffic wallet. Test results showed only noticeable difference is the IL-to-total-capital ratio, which, comes from the minimal fees incurred when sending funds to the staking contract. Also conducted research on APR wallets statistics from Rika, including wallet comparison and manual APR calculation verification.


2025-11-21 Fri: Completed a new version of the copy-trading bot using flashblocks and maximum priority fees. Testing on high traffic wallet (0-3 blocks duration) shows that in 80% of cases the transaction lands in the same block. Continuing testing with the target wallet with middle position duration (10-100 blocks).

2025-11-20 Thu: Completed a prototype script that uses flashblocks to receive block events every 200 ms via Alchemy RPC. Currently working on integrating it into the copy-trading bot.

2025-11-19 Wed: Added a script to monitor position duration in real time and confirmed that none of the observed wallets keep positions open for more than 30 blocks while staying under 100 blocks. Also continue researching flashblocks, which update every 200 ms via websocket (confirmed that the main source of latency was that any log or event queries return data only from already-mined blocks, whereas flashblocks provide access to block data while the block is still being assembled).

2025-11-18 Tue: Switched to a wallet with longer position duration to minimize liquidity ratio divergence and mitigate the one-block delay. Synced with Aaron regarding methods for achieving same-block transaction inclusion and started researching flashblocks on Base.

2025-11-17 Mon: Explored different approaches to reducing transaction execution time on Base and achieving inclusion in the same block as the target transaction. Included testing various RPC (alchemy and custom node) endpoints and adjusting transaction fee parameters.


2025-11-14 Fri: A detailed analysis of bot events and transactions, along with a study of the contract source code to understand the reward distribution logic and ratio formation. Conclude that the main design issue is the one-block delay — during that block the ratio and TVL change, and high traffic amplifies this effect. Together, these factors cause the APR and IL deviations. Potential solutions include submitting transactions in the same block and using a pool with lower traffic.

2025-11-13 Thu: Collecting statistics and analyzing the trading bot’s performance with the new settings — less frequent swaps result in lower loss of the initial deposit. There is a one-block delay relative to the target wallet, and sometimes the ratio doesn’t match. Transacrions and events count is the same. The total APR and IL differ from the target wallet — currently investigating the reasons.

2025-11-12 Wed: Updated the rebalance smart contract and launched a copy-trading bot with new settings: rare swaps to preserve liquidity. The bot checks the difference between the current ratio and the target wallet ratio, executing swaps only when the deviation exceeds 50%. Also switched to a new target wallet with lower transaction activity to reduce fee expenses.

2025-11-11 Tue: Daily performance analysis for copy-trading bot: due to overly frequent swap operations, liquidity losses reached around 5% ($50), with about $30 spent on fees and roughly 0.03% APR earned in AERO ($3). Working on optimizing the strategy to offset these losses.

2025-11-10 Mon: Launched copy-trading bot instance with built-in swaps for every action to precisely match the target wallet’s ratio. The bot was started with a $1,000 deposit and configured to mirror a high-traffic target wallet (up to 10 transactions per minute).


2025-11-07 Fri: Tested the updated contract with tokens rebalance logic (balances ratio scaling) before opening each new position, in conjunction with the copy-trading service. Transactions history analysis and bug fixes.

2025-11-06 Thu: Implementation of the ratio determination logic in the copy-trading bot service — added ratio calculation and integration with the updated contract methods. Testing different RPCs to maximize transaction submission speed — achieving a reaction time of 1 block.

2025-11-05 Wed: Added ratio scaling logic at the contract level to fully replicate the strategy of the original contract. The rebalance method was extended, and a new ratio parameter was introduced — it is sent by the copy-trading bot service, after which a swap is executed to adjust the token proportions before each new position is opened.

2025-11-04 Tue: Stability improvements to the copy trading bot: redundant collect calls from the contract were removed, the event aggregation algorithm was optimized, and a case for closing positions without rebalancing was added.

2025-11-03 Mon: Verification of varience in the copy trading bot’s performance compared target wallet based on transactions collected by Rika. Research revealed several discrepancies: a 3-block delay when opening positions, missed closures of some positions, and extra collect events.


2025-10-31 Fri: Tested copy-trading bot version connected to the rebalancer contract and staking system. Fixed several bugs and started collecting performance statistics. Added missing methods for reward withdrawal and contract ownership transfer. The latest version of the bot is deployed here.

2025-10-30 Thu: Integrated rebalance contract with the copy-trading bot — the rebalance is now triggered automatically upon receiving events from the monitored strategy contract. Added logic for auto-funding the contract deposit during bot initialization. Currently testing the contract in combination with the bot.

2025-10-29 Wed: Published the first draft version of the Rebalancer contract, which includes four main methods — deposit, withdraw, rebalance, and close positions. The rebalance function closes all current positions and opens new ones with staking, fully replicating the target strategy in a single transaction.

2025-10-28 Tue: Conducted a deeper analysis of the target (copied) contract’s events — to fully replicate the strategy, the position creation and staking actions must be executed within the same transaction. To achieve this, we decided to develop a Rebalancer contract that manages deposits and positions, combining multiple actions into a single transaction.

2025-10-27 Mon: Testing and debugging the copy trading bot. Started working on implementing a multisig contract to combine position closing and opening operations within a single transaction to copy strategy with the same speed.


2025-10-24 Fri: Analyzed bot logs over a 24-hour period — following a sync with Artem, implemented several optimizations, including improved WebSocket stability, event aggregation algorithm updates, and faster position-closing operations by reducing redundant requests.

2025-10-23 Thu: Deployed the MVP version of the copy-trading bot on the fly.io service. Added logging and a comparison table showing actions of the tracked address vs the bot’s address.

2025-10-22 Wed: Tested the copy-trading bot by replaying operations over a historical period. Added scaling logic — the bot now opens positions proportional to the tracked wallet’s positions but within the limits of its own deposit.

2025-10-21 Tue: Added 2 modes for copy-trading bot: live and historical mode, which allows reconstructing the trading history of a tracked wallet within a specified time range. Implemented position creation and closing methods — the core event handler and event generation for the bot are now in place.

2025-10-20 Mon: Started working on a copy trading service based on Artem's bot repo. Developing an service engine that monitors a position manager and staking contracts events through websocket in real time and reconstructs the lp position lifecycle and wallet's trading activity based on aggregated data.


2025-10-17 Fri: Selecting top wallets for strategy copying based on multiple metrics and stats by september. Synced with Aaron regarding the correct method of linking claim rewards to positions in cases with multiple staked positions, etc. Updated the scripts and data — exported claim rewards data for September from Aaron’s database for comparison.

2025-10-16 Thu: Worked on detailed position statistics — encountered an issue linking staking claim rewards events to specific token IDs, since the event itself doesn’t contain the position ID and can be triggered when multiple positions are held in the staking contract simultaneously. Researching Aaron’s scripts to find similar solutions.

2025-10-15 Wed: Expanded the wallet statistics for the period from September 4 to 30 — added data on deposits, withdrawals, number of events, etc. Compared the results with Artem’s data — they match with a small discrepancy, since my statistics include only positions with staking.

2025-10-14 Tue: Worked on consolidating september data for positions using both RPC event logs and subgraph data. Compared key profit metrics from fees and staking rewards with Aaron’s position data with fixed price.

2025-10-13 Mon: Exported all events from the gauge (staking) contract via RPC for the month of september, aggregated events by wallet address, and calculated the number of reward claims per wallet. Compared the results with the data provided by Artem and Aaron. Identified the top-performing (most profitable) wallets.


2025-10-10 Fri: Synced with Aaron and the team regarding XIRR calculation methods, price determination, and approaches to using Aaron’s database for data verification. We agreed to apply multiple XIRR calculation methods in parallel for subsequent comparison of the results. Continue working on updating the aerodrome monitoring service to calculate metrics using new methods.

2025-10-09 Thu: Implemented the new calculation formulas (impermanent loss, xirr, hodl) into the aerodrome monitoring service. Generated an updated position export reflecting the revised algorithms. Started researching stats by top 2 wallets.

2025-10-08 Wed: A deeper review with the team on the correct methods for calculating XIRR and HODL using new algorithms. Updated logic for searching open and close btc price in aerodrome monitoring service based on btc price by swaps history (still working on small interval).

2025-10-07 Tue: Studied four XIRR calculation methods from Rika and performed calculations using methods 1 and 3 based on data from Artem’s bot wallet — the results matched up to the tenth decimal place.

2025-10-06 Mon: Reviewed Li’s XIRR and HODL calculation and explored different approaches to measuring returns, including methods that account for impermanent loss. Recalculated XIRR using Artem’s approach. Integration of new calculation methods into aerodrome service scripts.


2025-10-03 Fri: Began reviewing materials on yield basis. Revisited XIRR calculations using the HODL approach. Recomputed PnL across cycles for HODL, LP, and new capital scenarios. Сompared to Theo’s results.

2025-10-02 Thu: Worked on adjusting the analytics script for cases when position opening/closing and swap operations occur within the same block — it’s necessary to take transaction index into account, and ensure that the swap event log index comes after the mint/burn/collect events.

2025-10-01 Wed: Updated the analytics script with functionality to find and load the initial cbBTC price from the closest swap event to the mint event of position creation. Currently testing and comparing results with the team’s outputs.


2025 Q4 planning

Continue development of analytics scripts for precise calculation of IL, profit, IRR, and optimal strategy search. Testing through running multiple bots, collecting statistics, as well as using historical data and simulations.

Development of the Aerodrome monitoring service for dynamic monitoring and analysis of bot performance, as well as real-time comparison of multiple bots/wallets. Adding a user interface and report visualization for strategy comparison.

Further development and improvements of the Snapshot x Harmony project. Adding new features such as automatic exclusion of low-activity validators from quorum, integration of governance voting into the staking interface, and more.


2025 Q3 Review

Aerodrome Monitoring Service

Snapshot X on Harmony

Aerodrome Base data verification, including fee checks, dataset validation. Developed and launched the Aerodrome Monitoring Service, which aggregates contract event and subgraph data into wallet- and position-level statistics. Integrated the service with a custom RPC node and subgraph, and validated its results against external sources such as Dune and custom transaction-level calculations.

Testing of different approaches to identify the most effective strategy: Testing different approaches to identify the most effective strategy: Based on a 3-month analysis of aggregated data (staking events and subgraph positions) from the Aerodrome service, I found that the highest APR is achieved by wallets that open very short positions (typically under an hour) within a narrow range of 100, with most activity concentrated in just a few wallets, while the majority of overall profit is generated through staking. The problems I encountered were that some of the data did not fully match the data from Dune, different method for calculating IL, and it was not entirely clear how to detect a strategy based on list of positions and whether other wallets were using hedging.

Migration and launch of Snapshot X on Harmony: deployed contracts, refined and launched the API service, updated and adapted the UI along with related libraries. The project also gained new features — including a validators-only whitelist strategy, a two-stage voting system with an off-chain second phase, integration with the staking dashboard, customizable quorum rules, and more.


2025-09-30 Tue: Updated the script to include retrieval and calculation of the sbBTC price from the nearest swap event at the time of position closure. For IL calculation, I now apply the individual cbBTC price specific to each position at its closing moment. Exported the results into a summary table for further analysis with team.

2025-09-29 Mon: Upgraded the script for calculating IL both by individual positions and for the entire wallet, using a fixed BTC price across all positions, followed by a comparison of the results with the team’s data. Current result is


2025-09-26 Fri: Researched Aaron’s data with fees by positions — overall, results matched completely except for minor discrepancies caused by rounding differences. Explored different approaches to loading the BTC price for IL and profit calculation in USD. Created a script that takes the price from the pool based on the swap event closest to a given date or block. Encountered an issue with pool indexing in the custom version of the subgraph — it seems that the official sources are partially outdated and no longer relevant. Worked on fixing the problem.

2025-09-25 Thu: Investigated the reasons for the discrepancy between the collected fees in Aaron’s and Rika’s data and the subgraph data (used events fron different contracts with different rounding). Wrote a script to calculate wallet balance changes based on deposit and withdraw position events.

2025-09-24 Wed: Completed a script to calculates the total fee profit per wallet per date range. Tested with Artem’s wallet and conmparing with Dune data. Result: 0.00059325 cbbtc + 68.531645 usdc.

2025-09-23 Tue: Added statistic by wallet and script to get all positions with fees by address using etherscan api and subgraph. To link addresses to subgraph positions, we first obtain a list of transactions via the etherscan API and then download the positions based on them.

2025-09-22 Mon: synced on team progress over last week, working on wallet statistic by subgraph data with subgraph query.


2025-09-15 to 2025-09-19: paid time-off

2025-09-12 Fri: Updated the gov.harmony.one service vote counting algorithm: changed to 50%+1 of total stake wight to reach quorum, and 66.67% of those to vote. Checked the conclusions and statistics for wallet 0x751140b83d289353b3b6da2c7e8659b3a0642f11 (especially for staking indicators) - to confirm the conclusions on the strategy.

2025-09-11 Thu: Studied the strategy text on fee optimization and delta hedging. Looked on the challenges of managing delta drift and ways to smooth it to avoid excessive hedge adjustments. Reviewing new inputs from Steven and Philip; The improvements for the gov.harmony.one release: the disclaimer, favicon, texts etc have been updated.

2025-09-10 Wed: Improvements to customize the graph for indexing selected pools. Studied the mechanics of fee calculation for virtual positions and how state tick values are emitted in swap events, based on Aaron’s new inputs. Tried a new calculation approach using indexer data.

2025-09-09 Tue: Synced with Artem regarding bot improvements. Researched the issue of updating LP state. When closing a position (closeLpPosition), it is necessary to take data from the emitted events (Collect, Burn), as they provide the most accurate information (instead of monitorPosition).

2025-09-08 Mon: Improvements to the subgraph on a custom RPC node — worked on fixing the issue of excessively long indexing by optimizing the code with a filter for specified liquidity pools (cbbtc only). Configured outline client on aerodrome monitoring service to have direct rpc node connection.


2025-09-05 Fri: Harmony napshot x has been deployed on gov.harmony.one, and we’ve started beta testing with validators and community. Also updated and released a new version of hmy-snapshot-cli with the ability to create proposals.

2025-09-04 Thu: Expanded the aggregated data of the aerodrome statistic service with a new formula for calculating impermanent loss. Testing the service data against Artem’s bot statistics. Bug fixing for snapshot x.

2025-09-03 Wed: Worked on launching snapshot-x to production — set up the project and deployment via netlify, updated the contracts, updated and redeploy api serivice on fly.io.

2025-09-02 Tue: Added support for displaying staking validators in the snapshot-x interface: auto-detecting the validator’s image and name from the participant’s address, link to the staking dashboard, etc. Working on migrating the Aerodrome stats service indexer to a server with a Base node to improve performance and enable the use of verified data.

2025-09-01 Mon: Added a role-based system for snapshot x: a manager who can create spaces; validators who can create proposals and vote; and regular users who can only vote in the main space. Also added role support in the interface and set up separate deployments/domains for different participants.


2025-08-29 Fri: Attempted to integrate the Aerodrome statistics service with a subgraph on a custom node: updated the request format and data interfaces. Downsides: access only via VPN and slow load speeds; to resolve this, the service needs to be moved to the same server.

2025-08-28 Thu: Tested a subgraph deployed with a custom base node and compared historical data with Dune. Swaps match, but daily profit still doesn’t. Also worked on adding new features for Snapshot X — convert voting power to ONE and display the real validators’ total stake as VP.

2025-08-27 Wed: Comparison of statistics for cbbtc pools by swap/day and all-time between Dune and Aerodrome’s official subgraphs. At a high level the numbers don’t match — analyzing simple swaps and fees, as well as the counting methodologies, to determine the causes of the discrepancies.

2025-08-26 Tue: Testing a custom Base RPC node; researching and selecting subgraphs and indexers to collect position data for Aerodrome Finance pools on a dedicated server: researching and testing the official indexer for Aerodrome and Velodrome; the official “aerodrome-base-full” subgraph.

2025-08-25 Mon: Snapshot-x feature tweaks: display the quorum block as a progress bar for both voting steps; add icons and links to the validator list; fix the recalculation of voting results for the 2nd off-chain step.


2025-08-22 Fri: Added a new space for snapshot-x with the ability to vote using the “vanilla” strategy and to create proposals using the “validators only” strategy. Synced with Artem on the core of the APR simulation model.

2025-08-21 Thu: Worked on launching verified subgraph for complete ingestion of aerodrome pools swaps and positions, enabling reliable verification and fully transparent computation of fees and trading volume. Synced with Ulad to connect to our own Base archival node and to accelerate the subgraph sync and ingestion of data from Aaron’s scripts.

2025-08-20 Wed: Collecting statistics on aerodrome positions via Aaron’s scripts — tried locally, but the process is too long due to the large number of requests to the RPC node. Working on deploying the service on a separate server with a connection to a custom Base RPC node. Sync with Artem regarding development of a simulation model for Uniswap v3 LP positions’ APR: calculating APR depending on range, trading volume, price volatility, etc.

2025-08-19 Tue: Comparison daily statistics (lp liquidity volume and total profit in USD) between the aerodrome monitoring service and the dune service. Researched the possibility of extending the Snapshot X engine to add statistics on validators who didn't voted, with subsequent exclusion of them from voting to enable reaching quorum without inactive participants.

2025-08-18 Mon: Exported positions data and converting it to a new format with preserved significant digits to enable verification of APR calculations in Excel spreadsheets. Also working on a script to compare data from the aerodrome monitoring service with data obtained from Aaron’s scripts and stats from Dune service.


2025-08-15 Fri: Made several improvements to the aerodrome monitoring service: expanding the API with filters by event name to exclude unnecessary events when integrating with the backtesting service. Worked on creating indexes to speed up database queries. Synced with Artem about developing a time-series simulation model of positions APR and impermanent loss (IL) based on input parameter set.

2025-08-14 Thu: Worked on calculating APR and other per-wallet statistics for the pool with tick 100, using a year of data (over 3 million events). Also attempted integration with Aaron’s lp data—computing fees from transfer/mint/burn events—for more accurate, ground-truth results without relying on the subgraph.

2025-08-13 Wed: Researched backtesting scripts and repositories from Aaron. Comparing the results of the exported aerodrome pools date by Aaron and the results of the monitoring service.

2025-08-12 Tue: Finished configuring a new instance of the aerodrome service monitoring service for the usdc/cbbtc 100 pair for full unloading of historical data of position events for the year. Was engaged in optimization for real-time calculation of data on positions - since the number of positions for the year is more than 3 million and it is impossible to make calculations through a one-time loading into memory - used the approach with unloading by batches and saving intermediate results in the database.

2025-08-11 Mon: Worked on exporting and aggregating by wallet data, including calculating average APR, average position duration, etc. Deployed a multi-indexer for events across multiple gauges. Working on an API extension for the aerodrome monitoring service.


2025-08-08 Fri: Started working on extending the Snapshot X voting engine to add a second off-chain voting step, based on an online calculation of votes proportional to the share of tokens delegated in staking.

2025-08-07 Thu: Worked on exporting and preparing data for USDC/cbBTC positions over the past 90 days, followed by daily breakdowns and compilation of statistics such as average APR, number of positions, average holding time, etc. Most positions open within a minute with fast withdrawal of staking rewards.

2025-08-06 Wed: Reviewed and researched repositories and tasks related to Harmony multisig from Gnosis Safe. Enhanced Snapshot X functionality to enable adding a custom quorum expressed as a percentage proportional to the total stake.

2025-08-05 Tue: Researched and designed the architecture for a two-stage voting system based on Snapshot X: the first stage is on-chain, and the second stage is off-chain, with real-time vote result updates proportional to the distribution of validator delegations.

2025-08-04 Mon: Synced with Artem regarding backtesting service. Added new settings to the monitoring service (including filters and sorting by APR, deposit size filter, etc) to export top Aerodrome pool positions to generate realtime stats.


2025-08-01 Fri: Synced with Artem on the latest version of the bot and backtesting, tested the latest version of the portfolio manager using docker-compose, and verified position profit via the monitoring service. Also worked on testing and fixing UI bugs for snapshot x.

2025-07-31 Thu: Explored the possibility of modifying the voting strategy at the contract level to replicate the original Harmony voting behavior — specifically, allowing for a stake check on validators at the end of the voting period. (This enabled users to re-delegate their stake during the two-week voting window to validators whose views aligned with their own). Continuing to work on custom execution strategy.

2025-07-30 Wed: Adding new filters to the Aerodrome Monitoring Service API: classic pagination and date/epoch filters for positions and events api's. New parameters have also been added to the pool hours data.

2025-07-29 Tue: Fixed a data indexing bug for proposals in the Harmony Snapshot X indexer. Continuing work on a custom execution strategy to finalize voting upon reaching quorum.

2025-07-28 Mon:Worked on expanding the aerodrome monitoring service by adding indexing for another cbbtc pool. Currently working on filters for the monitoring service API. Also conducted research on developing custom execution strategies for Harmony Snapshot X — the goal is to enforce quorum checks (50% of total stake weight at the time of the snapshot).


2025-07-25 Fri: Updated the Harmony Snapshot X interface: added restrictions on selecting networks and voting strategies when creating a space, and introduced a custom "Validators Only" strategy. Now, a one-time snapshot of validators and their voting power is taken when the proposal is created.

2025-07-24 Thu: Tested a new validators voting strategy integrated with the interface and relayer. Fixed errors in synchronization and contract logic. Started working on a custom snapshot-x harmony CLI.

2025-07-23 Wed: Updated smart contract for the validator voting strategy — new methods were added for data storage (called via the relayer), role-based access control was implemented, and array value retrieval was added. The new voting strategy was tested via the ui interface.

2025-07-22 Tue: Development of a relayer service for the Snapshot x Whitelist strategy — required for fetching validator list and their amounts. The service queries data via the Staking Explorer API and uploads it to the strategy smart contract.

2025-07-21 Mon: Deployed aerodrome finance pool monitoring service on a dedicated server. Worked on autostart and status check scripts. Worked on the client side for convenient integration of methods into other applications and bots.


2025-07-18 Fri: Tested the read-only functions of the Harmony staking precompiles to get validators data via a contract. Based on this reward and this pull request. Tested contract deployment and method calls from solidity as well as via web3. The goal is to use read methods in snapshot x voting contracts.

2025-07-17 Thu: Deploying the aerodrome monitoring service on AWS machines with a configured PostgreSQL database (since fly io's capacity is insufficient to load and calculate current statistics). Performed local testing of sx-cli and attempted to implement wallet usage from a file, similar to hmy-cli.

2025-07-16 Wed: Worked on a corrected AERO rewards calculation — previously, rewards claimed before a withdrawal were not accounted for. Added logic to track intermediate claimRewards events and allocate their amounts across active positions.

2025-07-15 Tue: Extracted the Aerodrome analytics service into a separate repository. Added features for local deployment, including commands for starting and configuring the database, displaying load statistics, and in-memory analytics of loaded data. Shared the setup with Artem for joint testing.

2025-07-14 Mon: Researched the Snapshot X ecosystem for CLI-based voting — including ready-made MVP solutions and custom implementations using the SDK. Also explored the possibility of accessing validator stake weight within a smart contract for a custom voting strategy, based on the Harmony Read-Only Staking Precompile.


2025-07-11 Fri: Reviewed the optimal LP Rebalancing Strategy for Aerodrome cbBTC/USDC added by Artem, and discussed key integration points. Made improvements to the Aerodrome analytics service — fixed position close date detection and optimized the performance of the analytics generation function.

2025-07-10 Thu: Synced with Artem regarding the analytics API service and the required analysis. Worked on setting up filters to obtain more accurate median values (since there are many noise positions with 0% APR or very small deposits). Added APIs for retrieving tick-level statistics and grouping by ticks, including min/max price boundaries.

2025-07-09 Wed: Splited the analytics system into three services (to support a larger number of pools and positions): data collection, data aggregation and computation, and an API serving statistics based on the processed data. Deployment setup and testing are in progress.

2025-07-08 Tue: Setting up and deploying the service with the database on Fly.io, testing and refining based on core use cases. Additional improvements for Snapshot X.

2025-07-07 Mon: Started work on integrating a postgress db into the analytics service (for storing events and positions data) to speed up analysis and enable fast loading of historical data, as fetching directly from on-chain events and subgraphs can take up to an hour and is limited.


2025 Q2 Review

Development of Shadow/Aerodrome positions stats tracker scripts

Advanced analytics and research on yield strategies.
Collected and analyzed extensive statistics across USD and BTC pools (Aerodrome, Beefy, SwapX, Shadow, Spectra). Developed multiple scripts to calculate APR, impermanent loss, and time-in-range per wallet. Built datasets with over 50,000 positions. Exported and organized raw data from subgraphs and contract events. Grouped LP strategies by parameters (cutoff, buffer, rebalancing gap), including VFAT and Ichi Vaults. Shadow and VFAT strategy tracking services. Launched shadow-pool-analytics with real-time wallet stats and APIs. Built backend tools (NestJS + Swagger) for LP tracking and rebalancing analysis.

Estimated APR sources for high-yield Aerodrome pools (cbBTC/USDC, cbBTC/WETH). Separated APR sources: trading fees, staking rewards based on contracts events. Explored delta-neutral BTC strategies with Theo & Artem; initiated integration plans with Hyperliquid perps and CLI MVP spec.

Tools for calculating pool shares and dynamic yield (aerofrome): based on the combination of historical data (contract events, subgraph data) and data retrieved from the contract at the time of the request (wallet positions, staking earned, swap fees) - then averaging across positions, or analytics for specific positions. Available through the application or API (under development).

Improved bridging: resolved stuck assets and redeployed contracts (e.g. $AXS, USDC.e) for Unify Bridge. Researched BSC RPCs and began debugging LayerZero V2 universal bridge with dynamic token mapping.


2025-07-04 Fri: Made improvements to the extended validator voting strategy (put it on pause for now until sync with Theo. Switched to working on backtesting tools for Artem's bot application.

2025-07-03 Thu: Completed the basic version of Snapshot X for Harmony. Improved the indexer to run through a Docker container and connected it to the internal Fly.io database. The indexer and GraphQL API are available here. Deployed the frontend demo app — with all basic strategies and core functionality: creating spaces, proposals, voting, etc.

2025-07-02 Wed: Sync with BTC strategy team. Resolved issues with the snapshot x indexer - added compatibility with harmony chain in the core library (the number of requested logs was adjusted). Setting up deployment on fly.io, there is still a problem with resource limitations, it may be necessary to set up deployment on an aws machine.

2025-07-01 Tue: Synced with Artem regarding the integration of analytics tools with other strategy management services. It was decided to make a number of improvements to provide API in a specific format: custom LP range, backtesting with rebalancing, support of different pools to test. Continue work on custom validator voting strategy contract.

2025-06-30 Mon: Finished improvements for the indexer and API services. Worked on deploying the postgreSQL database and the indexer to fly.io. Started developing a contract with a custom validator voting strategy based on a whitelist strategy contract.


2025-06-27 Fri: Paid time off

2025-06-26 Thu: Worked on adding Harmony chain support to the indexer service and graphQL api. Set up the indexer deployment. Synced with Theo regarding custom voting strategies for validators - the working approach seems to be extending the on-chain whitelist strategy contract, with the validator list being stored via a contract method call.

2025-06-25 Wed: Added support for the Harmony chain to the UI frontend repository. Deployed a demo version of the frontend. Currently, the available functionality is limited to creating new spaces using four strategies. Displaying the created spaces requires an indexer and API, which are still being configured and deployed.

2025-06-24 Tue: Finished deploying Snapshot X contracts on the Harmony chain. Currently working on setting up and integrating the remaining services — frontend and backend.

2025-06-23 Mon: Researched SnapshotX repositories and documentation. Checked these two repos: sx-monorepo and sx-evm to evaluate the possibility of deploying and configuring them on the Harmony side. It looks like some interface tweaking will be required, but overall, everything should work out of the box.


2025-06-20 Fri: Researched Aaron's project and souces. Tried to use and test on main cases: hyperliquid real-time position and price tracking, end-to-end strategy execution. Checked real-time price monitoring modules for Deribit, Aerodrome.

2025-06-19 Thu: Researched portfolio manager app by Artem: testing cases for hedging impermanent loss using Hyperliquid perpetual futures and automating position management. Reviewing the code for potential integration into the delta hedge CLI.

2025-06-18 Wed: Sync with Theo and Li for the next goals. Started diving into Artyom's and Aaron's projects. Look at the main user cases of the MVP delta hedge CLI. Planning the architecture for integrating Aerodrome and Hyperliquid.

Expectations, complete deep dive into Artem and Aaron's code and putting the Hyperliquid and Aerodrome implementations together. Completed product requirement document for our DeltaHedge minimal product, with CLI interface.

2025-06-17 Tue: Research and bug fixing of the bridge explorer related to RPC polling and integration with the LayerZero API. Switched to reviewing and refining the LP tracking scripts and open hedge on Hyperliquid.

2025-06-16 Mon: Made several fixes in the stats calculation scripts related to accounting for impermanent loss during price increase. Published a new version and shared it with Philipp. Continuing work on the API wrapper service for dynamic user position calculation.


2025-06-13 Fri: Updated the reports with statistics for the aerodrome btc pool: added data from the last two weeks (good volatility for calculating impermanent loss), split the APR into several columns — from staking, from trading fees, and from price appreciation/depreciation. Working on the report description for Philipp.

2025-06-12 Thu: Finished the script for dynamic analysis of status, data, and APR of staked positions by user address. Currently working on an API wrapper service to enable calls by rest requests.

2025-06-11 Wed: Continue develop a service for dynamically tracking a user’s aerodrome finance position status: potential APR based on their share in the pool’s gauge, the gauge’s total yield, and the amount of impermanent loss.

2025-06-10 Tue: Researched the issue with the Binance Smart Chain RPC used in the bridge explorer (as requested by support). I reviewed both public and private BSC RPC options, but unfortunately, they are not suitable due to limited request quotas and reliability. Setting up a dedicated node via QuickNode appears to be the best solution.

2025-06-09 Mon: Developing scripts to calculate real-time APR for a wallet on aerodrome. The idea is to estimate the user’s expected share of the weekly AERO rewards distributed to the pool’s gauge, based on their proportion of the total staked liquidity.


2025-06-06 Fri: Synced with Theo about best range and BTC yield strategies - that another iteration of the analysis of the Aerodrome pools is required, along with a partial modification of the scripts for aggregating positions by wallets, in order to obtain more accurate statistics closer to the platform's data, with over 100% APR to to understand more precise parameters of the strategy.

2025-06-05 Thu: Continue the analysis of Hyperliquid to check positions to profitable based on short and long rates: comparison of rates, calculation of break-even point, time horizon consideration. Creating new positions without analyzing historical data.

2025-06-04 Wed: synced with Theo regarding the stats we're getting for the USDC/cbBTC positions — the most popular tick range is from -68,000 to -66,000 (20% range), with an APR of 5.3% and an average position duration of ~8.70 days. However, the biggest USD profit comes from price changes due to high volatility. Working on the issue of merging user positions when different staking mechanisms are used.

2025-06-03 Tue: Added more stats and raw data on the liquidity pool. Switched focus to researching long and Short BTC perp via Hyperliquid.

2025-06-02 Mon: Fixed the issue with APR calculation by anchoring it to the token prices at the time of deposit and withdrawal, as well as accounting for changes in the reward token’s price at the time of withdrawal. Made adjustments for both types of positions — those staked in clGauge and those held directly by the user.


2025-05-30 Fri: Working on a mechanism to determine how rewards relate to specific positions and to organize positions by timeframe, in order to identify entry and exit positions times with reference to BTC prices and calculate impermanent loss. Switched to reviewing and testing the scripts for creating BTC liquidity pools from Li.

2025-05-29 Thu: Additionally exported the reward events for staked positions in clGauge. Since the contract sends rewards for all of a user's positions at once, it's only possible to accurately determine the APR for individual staked positions. Working on updating the calculation scripts for the statistic based on additional events.

2025-05-28 Wed: Synced with Theo regarding the target strategy: Outperform passive BTC by ≥ 15% annual alpha while maintaining near-zero BTC delta. Continuing to work on tracking the owners of positions staked in CLGauge by tracing the position token’s path through events.

2025-05-27 Tue: Exported the raw position data for the cbbtc-usdc pool for the entire period. Discovered an issue with the reward calculation for positions — since some of them participate in staking, the owner is actually the CLGauge contract, which makes it harder to identify the real owner and their yield.

2025-05-26 Mon: Worked on tracking the optimal strategy for the cbbtc/USDC pool on Aerodrome. Researched the Hyperliquid platform — for perp shorts, long BTC via perps or spot wallet, etc. Also explored the ecosystem to assess opportunities for building analytics and yield evaluation.


2025-05-24 Sat (3.0h): Exported the raw data for the S/USDC pool, finished report and shared the final statistics for the pool.

2025-05-23 Fri: Loaded all the data and completed the analysis of the statistics for the Shadow pool S/USDC from 05.15 to 22.15 (17th epoch). Currently working on the final report. Synced with Theo regarding new focus on the cbbtc/usdc position analysis from Aerodrome wallets to find the best range for our LP.

2025-05-22 Thu: Switched to analyzing statistics for the Shadow pool S/USDC: wallets with earnings over $1000, top 10 earning wallets, breakdown of the 327% APY for the 7.5% range, total trading fees, rebalancing frequencies.

2025-05-21 Wed: Synced with Artem regarding the Beets Protocol tracker and the optimal calculation of strategy profitability. Reviewed the pull request for beets-protocol in shadow ccaper. Currently working on the updated APR calculation and other parameters for all wallets stats.

2025-05-20 Tue: Analyzed the Balancer V3 Gyro Pool contracts to collect missing event data for the following beets.fi pools: scETH/scBTC, SolvBTC.BBN/SolvBTC, and scBTC/LBTC on sonic. Additionally, developing new scripts to aggregate data and compute wallet-level statistics.

2025-05-19 Mon: Opened several positions on beets.fi and spectra for yield testing, as well as event tracking and verifying the accuracy of information from the pools against real data. Started researching contracts, events, and subgraphs to collect data on beets.fi based on the docs.


2025-05-16 Fri: Updated and expanded the data on swapx ichi wallets stats. Completed the general comparison of btc pools on vfat, shadow, and swapx based on the collected statistics. Continuing research on the Spectra platform for data export and analytic.

2025-05-15 Thu: Finished exporting data and analyzing wallet statistics from the pools of Beefy and SwapX Ichi: wbtc-scbtc, scbtc-wbtc, ws/scbtc, usdc.e/scbtc. Researching the Beets and Spectra platforms for data export and wallet analysis, as well as strategies for btc pools.

2025-05-14 Wed: Added statistics for positions and wallets for several pools WBTC_scBTC (914 positions) and scBTC_LBTC (98 positions) - for vfat and shadow exchange. Working on data collection and analysis of BTC pools in Beefy Ichi Vaults.

2025-05-13 Tue: Added a separate export for big wallets with a deposit value of more than $1000. Finishing the analysis of BTC pools – the issues with reward calculations have been fixed, and an alternative subgraph is being used to re-collect the rewards data. In total, the analysis is being conducted for 50,000 positions.

2025-05-12 Mon: Finished extracting data for the aerodrome pools cbBTC/USDC and cbBTC/WETH with the promised APR of over 100%. Working on a script for analyzing the new data and a scheme for determining real impermanent losses.


2025-05-09 Fri: Exploring yield strategies for Bitcoin on the Aerodrome Finance platform, focusing on the cbBTC/USDC and cbBTC/WETH pools — following a similar research approach used for other platforms: collecting data through the subgraph and reward information via contract events, followed by analysis and calculation of actual APRs per wallet.

2025-05-08 Thu: Made several adjustments to the data format for the ichi vaults sources / vfat: switched from csv to tsv and corrected an error that caused some amounts to be misinterpreted as dates. Additionally, begun researching yield strategies for bitcoin.

2025-05-07 Wed: Fixed issue with transfers USDC.e from Harmony to Linea: the problem was with the version update on the unify bridge assets (error in contract sources). The contract was fixed and redeployed, also updated the related frontend and backend services. Users in the community have been notified.

2025-05-06 Tue: Added export of an extended version of the raw data for all pools used to calculate the vfat position metrics. Switched to supporting the bridge (upon request from support) — investigating an issue with transferring funds from Harmony to Linea. It looks like there is a problem with some contract settings on the harmony side"

2025-05-05 Mon: Synced with Theo regarding the final comparison between VFAT and Swapx ICHI vaults — we agreed that the most accurate approach is to compare the USDC.e/USDT and frxUSD/scUSD pools separately. Accordingly, I generated the data for the USDT pool on Swapx ICHI and wrote the final report — it's currently under review with Theo.


2025-05-02 Fri: Exported data for all swap operations in the frxUSD/scUSD pool to more accurately determine price changes and calculate the average in-range time for wallets, as well as impermanent loss. Working on the final analysis and conclusion comparing vfat and beefy swapx ichi vaults.

2025-05-01 Thu: Finished generating statistics on closed wallets based on data from the Ichi subgraph and gauge contract events. The challenge lies in the fact that a single wallet can have multiple deposits and withdrawals at different times, so I have to calculate the APR for time intervals and average them. Also prepared an export for the top wallets with a profit of over 10 dollars.

2025-04-29 Wed: Added statistics for the swapx ichi vault frxUSD/scUSD – 60 active wallets with calculated rewards and APR. Some difficulties arise because rewards need to be calculated differently for active and closed positions (via contract method calls or events). I will also expand this table with data on time in range and loss.

2025-04-29 Tue: Continue research on swapx vault ICHI strategies: Exported data on the vaults, including deposit, withdrawal, fee collection, and rebalancing events. Currently exporting the final positions from AlgebraPools to build comparison statistics between manually managed positions and those managed by the vault strategies.

2025-04-28 Mon: Made an additional export and analysis for vfat USD pools. Started collecting data on ichi's strategies beefy's pools to create a comparative analysis with vfat. Discussing the current analytics results with the team, making adjustments.


2025-04-25 Fri: Finished analyzing VFAT positions and strategies based on the collected data. Added a document with key findings on pools, losses, the impact of auto-rebalancing, and overall conclusions. Fixed errors in range tracking calculations and corrected the alignment of position timestamps with hours_pool_data.

2025-04-24 Thu: Added missing pool data. Updated script integration and collected statistical information — resulting in a complete dataset including: position, price range, deposits, profit, annual percentage rate, time in range, impermanent loss, wallet, strategy settings, pool, and more.

2025-04-23 Wed: Finished exporting all rewards across all tokens, as well as hourly data on pool states. Currently working on the final script for data aggregation and position statistics calculation — vfat strategies (the exported data covers 45% of all vfat positions and the top 10 pools with 90% of the TVL).

2025-04-22 Tue: Finished the full data export for positions in the top 10 vfat pools. Still need to load the rewards from gauges for the entire period — after that, we’ll be able to launch advanced analytics to calculate pool strategies. Also did some research on SnapshotX (open-source Snapshot) to work with Harmony, for a governance solution.

2025-04-21 Mon: Continuing work on exporting data for all Shadow pools to generate extended statistics for VFAT. There are several issues with the subgraph when retrieving old positions from many pools — working on resolving them. Grouped all VFAT position-settings by cutoff and buffer parameters — most strategies monitor the entire Uniswap price range without restrictions. With no buffer and auto-rebalance enabled, the system instantly reacts as soon as the price moves out of range.


2025-04-17 Fri: Since the vfat sample of positions shows too little data with almost identical rebalancing settings for the USDC.e/scUSD and USDC.e/USDT pools, Theo and I decided to expand the data collection range to include all usd* pools — goal is to find the most profitable usd* pool from the last 90 days - working on scripts extending.

2025-04-16 Thu: Investigated user issues related to using Ledger Nano for staking. Then returned to analyzing USD strategies, exported the settings for all vfat positions — still have the main question is how to analyze params correctly. Synced with Theo about next steps.

2025-04-16 Wed: Finished fixing the bridge issues related to the loss of AXS tokens. The core problem was that Horizon legacy tokens operate through an intermediate contract, which requires more gas, and this wasn't calculated correctly in the proxy on the Ethereum side. Also fixed the issue with the explorer service interacting with the Arbitrum RPC.

2025-04-15 Tue: Switched to fixing several outstanding bridge issues from the community: $AXS asset stuck when bridging $1AXS from Ethereum to HarmonyONE, and a LEDGER Nano-related issue. Also finishing the final export of scUSD strategies (will update later today).

2025-04-14 Mon: Exported the historical price data of scUSDC for the entire period, based on the subgraph events swaps and historyPoolData, and plotted its distribution using AI. I'm continuing to work on researching how to tie vfat rebalancing strategy parameters to scUSD positions — currently, there's an issue where too few vfat strategies are found for the scUSD pool, and the parameters are repeating, so I'm double-checking the approach.


2025-04-11 Fri: Finished the service for loading NftSettingsSet events and finding positions related to those settings. As a result, there’s now an extended tsv table with vfat positions. Parameters like cutoff, buffer, etc., have been added. However, as we can see for the USDC.e/USDT pool, the settings are almost identical across all positions.

2025-04-10 Thu: Worked on linking historical shadow exchange positions to vfat strategies, mainly by checking for the SickleDepositedNft event in position creation transactions or mapping NftSettingsSet events from the NftSettingsRegistry contract by tokenId. This will let us group positions by wallet and strategy parameters like cutoff and buffer. Building scripts to load event data and refresh the stats.

2025-04-09 Wed: Researched issues with performance limitations of the shadow-pool-analytics application on fly.io, configured the deployment. Switching to vfat contract analysis and searching for a subgraph or writing a custom event listener to bind vfat parameters (cutoff / buffer) to positions and generate general statistics.

2025-04-08 Tue: Completed shadow pool analytics service for receiving full statistics on positions (including impermanent losses) and wallets in real time. Added swagger on developed APIs (by position, by wallet, general list etc). Working on optimization: due to the fact that the analysis of the entire pool of about 10 thousand positions takes up too many processor resources fly.io

2025-04-07 Mon: Finished a script for loading data and calculating the parameters of impermanent Loss percent and short term volatility percent. Working on wrapping the script in the nestjs service with an api to be able to make requests to custom pools in real time.


2025-04-04 Fri: Started working on a service for assessing impermanent loss for positions opened via vfat.io. Data for analysis about the position and pool is loaded via subgraphs and token prices are taken via open APIs coingecko, binance.

2025-04-03 Thu: Added a script for determining the optimal strategy by positions: first grouping by wallets and ticks, then averaging values of APR, deposited, time in range, position duration, and then calculating parameters like total profit in usd, number of rebalances, and rebalances gap in hours. Exported the results to TSV tables.

2025-04-02 Wed: To determine whether a position was in-range, two approaches were used: based on pool hours data (with hourly accuracy) and by exporting all swap events (more precise). Updated the statistics calculation script according to the new data and performed the final export.

2025-04-01 Tue: Added a script for exporting burn events to determine the exact lifetime of each position, and accordingly added recalculation of the actual APR.


2025 Q1 Review

Improvements and launch of Pump.ONE contracts. All contracts are made upgradable. Added a second alternative version of the Token Factory contract without competitions with the preserved functionality of trading and publishing in Uniswap V3 pools. Transition to AсcessControl with the division of functionality between the roles of administrator and manager. Added utility methods for withdrawing rewards and liquidity. Fixed critical errors in interaction with Uniswap and price calculation. Assistance with integration with backend and frontend services. Support at Pump.ONE application launch.

Completed Unify Bridge Assets V1 feature: USDC converter contract allow converting legacy USDC to USDC.e at a rate of 1-1, extended ProxyHRC20 layerzero contracts to support bridging USDC tokens from different chains to one USDC.e on the harmony side, the frontend was also updated to support unify assets feature. Now the conversion works for the linea and base networks.

Started working on Layerzero V2 bridge contract: one common contract for all tokens, dynamic addition of new tokens via contract method calls, auto deployment of token wrapper on the harmony side. Draft version is ready, currently in debugging stage. Researched options for transferring liquidity from v1 contracts to v2.

Researched contracts for auto balance strategies: vfat Farm Strategy, beefy, arrakis, gamma. Created contract based on FarmStrategy with predefined parameters. The contract checks for range out-of-range and calls rebalancing methods. The goal is to collect statistics for analysis in-range fee-collecting performance in sonic mainnet.


2025-03-31 Mon: Added a script to determine the best strategies by grouping by average price and range, as well as by tick. Added calculation of the ROI parameter, total profitability and average APR. Because most of the positions are concentrated in the most profitable group, it is difficult to isolate winning strategies. Working on adding rebalancing parameters and time in the range.


2025-03-28 Fri: Fixed calculation errors, corrected data. Researched to understand which positions were opened via vfat and which via shadow ux. Added position lifespan analysis for more accurate calculation for apr.

2025-03-27 Thu: Completed final version of the statistic script using a combined approach to loading rewards and calculating apr - all methods are used: totalFeeCollateral and claimRewards from the subgraph, direct call earned for positions for which there was no withdrawal of rewards, analysis of transfers of reward tokens from the guard address to the address of the position owner. Also expanded the range of information collection to 1 month - to capture more positions and rewards (since most open them for a long time).

2025-03-26 Wed: Tried an alternative method for loading rewards by unloading reward token transfer operations via sonic api. Based on the developed python script from Rika. Updated some stats tsv data.

2025-03-25 Tue: Worked on solving the problem of calculating apr with reference to positions - loaded part of the data from the subgraph via claimRewards and part by directly calling the earned method of the contract. When unloading for the week, the general data does not match the declared in the shadow total rewards interface. Doing a deeper research of the problem of linking rewards to positions.

2025-03-24 Mon: Converted tables with reports to tsv format, redid rounding and grouping by prices. There is still a problem with the APR calculation - some of them are negative or 0, which does not correspond to the general statistics. It seems that the problem is in the extended time range of creating positions and collecting rewards, also part of positions still not claim rewards.


2025-03-21 Fri: Worked on a script for loading (directly through my subgraph) and generating statistics for specified pools, positions: tick-range in usdc/usd* pools, rebalance occurrences (calculated through mint/burn events), trading fees, liquid rewards (through subgraph queries), future points, overall return.

2025-03-20 Thu: Researched way to detect how much tvl is in shadow’s vaults via direct deposits vs managed by vfat’s "auto rebalancing" or "auto compounding" strategies. Deployed and configured custom Shadow Pool Subgraph.

2025-03-19 Wed: Researched graphql queries to get data (positions and rewards). Completed a script to calculate TVL and rewards for a price in range of 90% (from $1). some problem with linking rewards to swap transactions (ie grouping by price range)

2025-03-18 Tue: Added scripts for uploading swap data from swapX. Uploaded more data on USDC.e/scUSD pools, updated the script for calculating stats range by volume. Started researching the possibility of linking swap events to position commission data - to calculate rewards in the 90% range.

2025-03-17 Mon: Used portfolio tracker to output all trades of the last 7 days in csv format for shadow’s and swapX USDC.e/USDT pool. Added scripts for calculating the range (centered around $1) where 90% of trades were in for maximizing gains from fees.


2025-03-15 Sat: Added more contract events to support analytics collection (rebalancing prices, fee, ticks etc). Worked on Q1 Review.

2025-03-14 Fri: Completed integration with shadow exchange pools via Ramses V3 Protocol interfaces (used shadow exchange for managing pools). Added a simple backend service for calling methods for checking out-of-range with automatic rebalancing. Testing the contract and strategy.

2025-03-13 Thu: sick day-off

2025-03-12 Wed: sick day-off

2025-03-11 Tue: Researched interaction with shadow exchange pools, including via vfat (Farm Strategy) adapters. Transferred the logic of making decisions on rebalance to the contract level, testing Farm Strategy on the usdc shadow pool.

2025-03-10 Mon: Worked on developing a contract based on FarmStrategy: predefined parameters, limited settings, application consists of a contract and a client. The client checks for out-of-range and calls rebalance methods. The goal is to collect statistics for analysis in-range fee-collecting performance in sonic mainnet.


2025-03-07 Fri: Researched contracts for auto balance strategies: vfat Farm Strategy, beefy, arrakis, gamma. Research of the sonic mainnet eco system, analysis of interaction with liquidity pools using Farm Strategy as an example.

2025-03-06 Thu: Added improvements for layerzero v2 receiver: automatic wrapped token registration, fee handling for token transfers, validation of supported chains, and improved event logging for better tracking and security. Added more tests.

2025-03-05 Wed: Added layer zero v2 receiver contract for use on the harmony side: standard methods for receiving and sending tokens + deploy wrapper token contract in case of a new token. Now the main problem is the correct calculation of the cost of deployment and increasing the fee for cases when deploying a new token.

2025-03-04 Tue: Published layerzero v2 bridge contracts first version: allows the owner to add and remove supported tokens, transmitted message contains token address, amount and receiver, token wrappers still should be deployed manually. Continue working on dynamic token wrappers deployment.

2025-03-03 Mon: Researched the socket bridge proposal, compared it with existing analogues; dealt with the problem of deploying new contracts on layerzero v1 (Destination transaction caused payload stored). Contacted layerzero developers to register configs of new contracts.


2025-02-28 Fri: Support for layerzero v1 bridge: several bugs blocking the transfer of bnb/one tokens have been fixed (reports from Sopha and Theo). Studying statistics on operations - there are many explorer errors associated with the limited unavailability of free bsc rpc (considering the option of returning to our own node for bsc). Finishing up updating the interface for the hidden conversion of legacy assets, preparing a demo.

2025-02-27 Thu: Updated OFTCore contract for unify bridge assets: allows specifying a token in the sendFrom method and includes a whitelist mechanism. Testing new version. Researched sonic gateway bridge solutions: repositories, [audit](audit here https://blog.openzeppelin.com/sonic-gateway-audit), docs, possibility of porting to harmony.

2025-02-26 Wed: Unify assets: improvements to the proxy contract V1 - one more parameter has been added to the constructor that indicates a usdc-supported legacy token (burning only). Also, in the _debitFrom method you can now explicitly indicate which token will be burned. Debugging and fixing problematic USDC (Base) bridge transactions.

2025-02-25 Tue: Synchronized with Theo and Philip about the current version of unify assets - it was decided to finalize the architecture to make it possible to do hidden legace usdc conversion without redirects to the conversion interface. Helped Rika with contract deployment, debugging and understanding of bridge contract structure.

2025-02-24 Mon: Added a description with screenshots and comments on the current flow of unidy bridge assets translations (for discussion with Theo and Philip). Layerzero V2 - research for the possibility of transferring liquidity to new contracts with V1. Research for bridge solutions based on liquidity pools from the Socket protocol team (suggestion from Philip).


2025-02-21 Fri: Added ux improvements for the layerzero bridge: a fix for displaying legacy assets, displaying tokens available for transfer, and validation at the stage of entering the transfer amount. Published the latest version on the bridge prod. Tested the full bridge AERO flow from Rika.

2025-02-20 Thu: Reviewed staking dashboard update (Ledger App Integration via Ledger SDK feature). Continue to work on the architecture of the common contract of the V2 bridge.

2025-02-19 Wed: Added fixes for ui usdc converter: fixed error when converting decimals, updated configs and contract addresses. A new version of ui has been deployed. Sent all updates to Aaron for security review.

2025-02-18 Tue: Fixed tests for pump.one contracts: support for interfaces of updated contracts, fixed a bug with the withdrawal of commissions by the administrator, fixed a bug with waiting for a delay between publication on Uniswap and the conversion of tokens.

2025-02-17 Mon: Deploy hrc20 production contacts for usdc tokens (eth, arb, bsc, base, linea). Detailing and planning work to update the bridge - transition to LayerZero V2, creation of a common contract for all tokens with the dynamic connection of new tokens.


2025-02-14 Fri: Improvements to the USDC converter: since bscUSDC differs in decimals from USDC of other chains - amount normalization has been added when converting tokens - now the decimals of input and output tokens are taken into account. Tests have been updated and contracts redeployed.

2025-02-13 Thu: The transition from Ownable to Access Control contracts has been implemented to make it possible to allocate a separate Manager role, which will initiate the start of a new competition. The Administrator role will still be responsible for updating the contract and setting up the configuration.

2025-02-12 Wed: Researched the issue with pablish to uniswap after competition ending. Reviewed a pull request from Aaron with a bug fixes. Transferred fixes to Token Factory Base. Synchronized with Artem about updates. A reqiredCollateral parameter has also been added to control the minimum collateral before publishing.

2025-02-11 Tue: After synchronizing with Artem and Aaron, it was decided to add publishing methods on Uniswap to the contract and make the token non-tradable after publication. Pushed new version. Tested new contract version, found an error "execution reverted: LOK" (uniswap intercation) - Working with Aaron on a fix.

2025-02-10 Mon: Completed the Token Factory Base contract: only token release, purchase, sale. I gave it to Aaron for review. Working with Artem on integration.


2025-02-07 Fri: Improvements to the Reward Distributor contract: transition from Ownable to AccessControl. Added manager role to set epoch duration and epoch reward. Withdrawal methods are available only to the main admin role. Synchronized with Artem regarding improvements to Token Factory - working on another modification for the factory without competition but with support for all events and methods of the original (for full compatibility in the frontend).

2025-02-06 Thu: Completed deploying smart contracts: proxy, USDCe, converter, published the frontend demo of the usdc converter, and added several ui corrections. Working on a flow description for testing a unify bridge assets full demo.

2025-02-05 Wed: Deployment and configuration of the production version of contracts for the USDCe token, proxy contracts for the bsc USDC and USDCe harmony bundle, deployment USDC converter contracts and frontend app, etc.

2025-02-04 Tue: Improvement of the USDC converter and layerzero bridge frontend services to implement a full flow with redirection and conversion of tokens: a return to the bridge after conversion has been added, on the bridge side support for going to the USDCe token page after conversion has been added. Testing the full flow and fix errors.

2025-02-03 Mon: Reviewed changes from Artem. Worked on additional front-end features of the USDC converter: selecting tokens from a drop-down list, following a link - passing the token address through the url, as a result of which the USDC converter opens with a pre-installed token for exchange (bridge crossing integration).


2025-01-31 Fri: Researched the possibility of withdrawing ROT/MAGGOT tokens from Harmony, or adding them to an existing bridge (at the request of community partners). Testing an updated version of pump.one with upgradable contracts in conjunction with backend and frontend services.

2025-01-30 Thu: Synchronized with Artem about improvements to pump.one before launch: at Theo’s request, we are making a version with the optional inclusion of competitions. I made several improvements that allow you to use Token Factory without competitions, with the subsequent optional inclusion of competitions. Several manage methods have also been added for emergency withdrawal of user funds and transfer tokwns ownership.

2025-01-29 Wed: Worked on integrating the USDC converter into the layerzero bridge interface: if the user selects legacy assets and the balance is non-zero, he is prompted to go to a separate usdc converter page. After successful conversion, a redirect is made back to the bridge to continue the operation.

2025-01-28 Tue: Added more changes to pump.one Upgradeable-contracts version. Changed package versions to support compatibility with ethers 5 (used in deployment and update scripts). Shared with Aaron for security review.

2025-01-27 Mon: Changed USDC converter contract - according to issue from Aaron. Transfer of tokens has been replaced by burning. Started working on improvements to the front end of the usdc converter service.


2025-01-24 Fri: Review and test of the front-end part of the usdc converter - pull request from Teo. Assessing integration into the main bridge application, it looks like the converter should be a separate application or a separate widget.

2025-01-23 Thu: Tested updating contracts via hardhat Upgradeable Contracts. Added update support for Token Factory and Liquidity Manager contracts. Added new deployment and update scripts.

2025-01-22 Wed: Synchronized with Artem regarding improvements to the pump.one contract. Worked on an upgradable version of the Token Factory contract.

2025-01-21 Tue: Tested unify assets full flow: transferred bsсUSDC to harmony, converted to USDCe, transferred back through a proxy USDCe contract. Worked on rest lz bridge frontend fixes: renaming legacy tokens to legacyAssets, adding lz logo banner. Waiting for a decision from Theo and Alaina on the way to integrate the USDCe converter: inside the bridge application or redirect to a separate application.

2025-01-20 Mon: Worked on updating the frontend part of the bridge application - added checks for the available transfer limit for all USDC tokens by calling a new contract proxy method. Also working on displaying warnings and changing token links.


2025-01-17 Fri: Refactoring of the proxy layerzero oft contract - updating the solidity version, adding service methods to manage contract parameters, adjusted the calculation of the amount of tokens during transfer, added safeERC20.

2025-01-16 Thu: Deployed a usdc converter with test tokens, created an example of use with ethers. Shared instructions with Teo for further development of the interface. Working on optimizing the Proxy contract.

2025-01-15 Wed: Completed USDC Converter contract: allow converting legacy USDC to USDC.e at a rate of 1-1. Added e2e tests. Currently working with test tokens.

2025-01-14 Tue: Extended the existing LZ Proxy contract to store the number of tokens locked on the external chain side on the Harmony side. Increase and decrease this value accordingly during transfers. Added contract-level validation.

2025-01-13 Mon: Completed corrections based on review comments: removed the subtraction of the fee basis value when calculating the commission, corrected the tests. Continue work on unify bridge assets.


2025-01-10 Fri: Worked on Unify Bridge Assets new proxy contract, based on task. Another round of testing for pump.one contracts (update from Aaron).

2025-01-09 Thu: Completed fixing all tasks on the erc4626 issues list. Prepared a list of improvements: fee calculation, resolved unnecessary and risky dependencies, added fallback methods to withdraw assets for reward contract, use of the current balance in case it is not enough for rewards per epoch.

2025-01-08 Wed: Looked at the contract issues that Aaron found as a result of the security audit. Working on adding fallback methods to withdraw assets from Reward Contract. Also started working on adjusting the commission deduction in accordance with the documentation from Aaron.

2025-01-07 Tue: Added Rewards Deposited events storing to erc4626 rewards distributor backend. Research to evaluate the complexity of adding an additional competition function to Pump.One contracts

2025-01-06 Mon: Added several fixes for the Staking Vault contract. Shared contracts with Aaron for a security audit. Synchronized with Artem to update the client.


2024 Q4 Review

Development Pump.ONE contracts: the logic for the token factory, competition and liquidity manager is fully implemented. Implemented counting of investments, determining the winner and publishing on Uniswap v3. Additional logic has been developed for linking tokens to the competition ID: buying and selling is allowed only within the current competition - then the user can only convert his tokens into winner tokens, or publish on Uniswap if this token is the winner. Several integration tests have been developed. Contracts serve as the basis for the Pump.ONE application. Added integrations with API services and frontend client.

Developed Staking Vault contracts based on Erc-4626 with a Reward distributor contract. Additionally, the 1sDAI token was added to the bridge, which was integrated into the Staking Vault. Added logic for commission deduction, as well as rewards by epoch.

Also worked on the development of several new layerzero bridge features: integration with Solana (with the transition to LayerZero V2) - implemented draft only for the test network. Updating npm bridge packages and worked on bridge-cli for translations from the command line.


2025 Goals:

In 2025, I will enhance the Harmony Bridge with features like migration to LayerZero V2, Solana support, a unified contract for multiple tokens with dynamic additions, and USDCe support for all chains. UX improvements will also be implemented for a smoother experience.

Additionally, I'll release DeFi applications such as Pump ONE contracts, ERC-4626-based Staking Vaults, GMX V1, and an upgraded GMX version with autocompounder, leveraged GLP, and delta-neutral vaults. DeFi games integrated with Telegram will also be launched.

I’ll develop autonomous yield optimization agents and AI-driven trading bots for real-time decision-making, as well as integrate AI into staking and liquidity management for seamless portfolio rebalancing and auto-compounding.


2024-12-24 Tue: Added more tests for the Reward and Staking Vault contracts: testing the change in the price of share tokens and the sequential addition of rewards. Testing the withdrawal of the full amount of share tokens. Added methods for editing all internal parameters of the Reward contract, as well as the ownership model.

2024-12-23 Mon: Fixed the erc4626 Staking Vault contract issue, related to the deduction of commissions when withdrawing funds through the withdrawal and redeem methods: in the current version, the commission is deducted from the general pool, which makes the price of share tokens lower for all holders. This problem is fixed in the new version.


2024-12-20 Fri: Reviewed and tested the new pump one contracts update. Tested changes related to new burn and convert mechanism, reduced liquidity at publishing pool.

2024-12-19 Thu: Expanded the contract - added methods for editing internal variables, epoch length, number of rewards, etc. Updated e2e tests. Added indexing of reward payment events to the web 2 service. Synchronized with Artem regarding the service method for integration with the UI.

2024-12-18 Wed: Added web2 service API to display vairables and statistics of the rewards distributor contract: the current balance, next epoch flip, rewards streamed per day, rewards streamed per epoch. Also set up deployment of the service on fly.io.

2024-12-17 Tue: Added erc4626 rewards distributor web2 service that monitors the current balance and calls rewards distributor contract methods every epoch to transfer rewards to StakingVault.

2024-12-16 Mon: Synchronized with Artem about the Staking Vault contract methods, as well as the main use cases. Shared a test script with main use cases. Involved in testing and debugging errors. Added Q4 reviews.


2024-12-13 Fri: Worked on a prototype for a new Proxy bridge contract with the ability to unify bridge assets - the main difference on the Harmony side will be the ability to link several proxy oft contracts to one token and accounting for liquidity on the side of the external chain by increasing the counter inside the contract on the Harmony side.

2024-12-12 Thu: Worked on foundry tests for Erc-4626 Staking Vault and Reward distributor contract. Reviewed Unify Bridge Assets doc, explored the possibility of avoiding liquidity fragmentation, assets bridged from any chain into Harmony should result in one single asset.

2024-12-11 Wed: Completed the e2e tests for integration cases with Uniswap and the creation of a pool - publishToUniswap. Unfortunately, there remains a problem with running tests on local emulator with deploying UniswapV3Factory from tests (different versions of Uniswap and token factory).

2024-12-10 Tue: Worked on tests for TokenFactory: buying, selling, price changes, commission, publishing on Uniswap. Correction of contract settings to resolve issue. Fixed bug on call mint for not winner with low token price. Redeploy all contracts. Researched bridge rpc connection issue.

2024-12-09 Mon: Pumpfun launch: fixed issue with uniswap initial supply calculation. Review and merged latest changes from Aaron. Redeployed all contracts. Testing complex e2e cases.


2024-12-07 Sun: Reviewed and tested several merge requests from Aaron. Found several issues.

2024-12-06 Fri: Pupmpfun launch testing. Researched computeMintingAmountFromPrice using issue. Synchronized with Aaron regarding the distribution of tasks - to speed up the launch process.

2024-12-05 Thu: Worked on Staking Vault tests and reward distribution logic extensions. Received a list of review edits from Aaron - worked on the fixes.

2024-12-04 Wed: Added Staking Vault (1sDAI) contract based on erc-4626 with Reward contract. Added custom fetures: 0.1% of deposits or withdrawals are levied as a fee and transferred to a separate walletsupport, Reward distribution: Before each epoch the reward contract checks the available 1sDAI balance and will distribute the amount set by us OR the maximum amount available.

2024-12-03 Tue: Worked on other edits for token factory and liquidity manager contracts: ensuring the assembly is compatible with uniswap/v3-periphery through the use of foundry remappings, calculating tickLower and tickMax based on price, comparing token addresses and correcting their order when creating a pool.

2024-12-02 Mon: Synced with Aaron and Artem about pumpfun launch, pushed contract fixes based on Aaron review: getSqrtPriceX96 calculation function has been fixed, the logic for calculating the initial number of winner tokens for a pool has been changed, pool creation has been separated into a separate method, etc.


2024-11-29 Fri: Researched issues with correct ticks and sqrtPriceX96 calculation. Helped Artem with the integration of new contracts into the client and backend services. Working on more tests: swap via created pools, pools mamagement from contract creator accounts, adding more liquidity.

2024-11-28 Thu: Completed Liquidity Manager contract based on NonfungiblePositionManager and UniswapV3Pool iteractions. Extended TokenFactory woth new winner logic, added more events and public views. Updated test scripts.

2024-11-27 Wed: Researched other ways to manage the liquidity pool. Made a new version based on NonfungiblePositionManager class to mint a liquidity position and then modify the provided liquidity. (this way also reccomeded in uniswap v3 docs). Additionally, it is necessary to work out the issue of storing and managing tokens received when adding liquidity.

2024-11-26 Tue: Pushed new version with mint fill range feature based on PanopticFactory example. But still have LOK error (reentrancy guard. A transaction cannot re-enter the pool mid-swap) on execution.

2024-11-25 Mon: Synchronized with Artem and Aaron regarding the launch of the pumpfun service, and identified the missing core features. Working on final improvements and tests.


2024-11-22 Fri: Worked on the remaining logic for the winner after calling burnTokenAndMintWinner: adding liquidity to uniswap, sending events, defining a fixed inital supply, recalculating native tokens with which a new pull will be created.

2024-11-21 Thu: Worked with Artem on the integration of new contract methods into the client and backend pump-fun services. Received new version of the bonding curve contract from Aaron - working on integrating the contract into the current token factory and writing foundry tests.

2024-11-20 Wed: Added support for the sDAI token to the Harmony Bridge. Researched possibility of implementing the erc-4626 standard on Harmony for the DeFi-Strategy project. Other improvements for the bridge ux.

2024-11-19 Tue: Added more fixes for pump fun token factory contract: resolved wrong competitionId issue (in _sell method called from burnTokenAndMintWinner) and changed the types of several structures to optimize storage. Started working on tests using foundry.

2024-11-18 Mon: Pused review edits, as well as integration with the latest updates. There is still a problem with calculating the price when selling and calling the burnTokenAndMintWinner method. There is a big difference between the blocked collateral and the new price calculated using the bounding curve. Synchronized with Aaron on current issues and further improvements.


2024-11-15 Fri: Reviewed and teseted Aaron's pr with new bonding curve using Bancor Formula. Started integrating new updates into the current release version with expanded logic for determining the winner.

2024-11-14 Thu: Researched potential issue with burnTokenAndMintWinner method: whoever wants to sell first (when burning-to-covert becomes eligible) gets to sell it at a much higher price. Inspected cases we should enforce using a linear bonding curve (i.e. constant price) for calculating ONEs (ETH) obtained for burning.

2024-11-13 Wed: Continue to work on improving the contract based on pull revest review: allow each token to choose their own bonding curve, switched to higher solidity version, switched to Foundry for deployment, testing, and scripts, added custom error structs.

2024-11-12 Tue: Got feedback from Aaron on the latest updates. Working on fixing and improving reliability: switched keys from "day number" to some sort of "competition series id", to avoid collision when competition interval varies (instead of always 1 day), also changed all related logic in various methods.

2024-11-11 Mon: Continue to work on developing further logic for managing tokens issued through pump.fun TokenFactory after the winner is determined: scenarios with the addition of liquidity on Uniswap, minting more tokens, withdrawal of rewards, closing positions.


2024-11-08 Fri: Helped with integration contract methods into the pump.fun client application and backend services. Tested different contract cases, Fixed errors related to setting the start date of the competition for new tokens and breaking the logic of determining the winner.

2024-11-07 Thu: Synced with Artem regarding UX cases - decided that after winning the token ceases to participate in the competition and can only be converted into a Uniswap liquidity pool with a fixed initial supply. Added winners list - to prevent the winner from participating in the voting again and to support payments for past dates.

2024-11-06 Wed: Added more features to pump contracts: stored contracts creation date, restriction of buy and sale operations by funding rate interval (1 day after contract creation date), added get winner by date view.

2024-11-05 Tue: Finished implementing the logic for determining the winner on the contract side. Synchronized with Aaron and Frank to adjust the business logic of the application. Working on adding new cases: after the winner is determined, the token is eliminated from the competition and winners liquidity pool is automatically created to Uniswap.

2024-11-04 Mon: Synchronized with Artem regarding the launch of the pump demo application, helped with the integration of contract methods and testing. Continue to implement the logic for determining the winner by day on the contract side.


2024-11-01 Fri: Working on the logic for determining the winner of the contract side: store a map that accumulates money paid for each token for each day, and the total number of token created so far until each day.

2024-10-31 Thu: Synced with Aaron about the best token burning flow. Updated the contract with new logic - now after determining the winner, each user must call a method that check if a token they hold is the winner for the day, and if not, mints the winner token for the user based on an amount calculated by the accumulated money ( across all days) paid for the token which the user hold, divide by the accumulated money paid for the winning token. Added example for Artem.

2024-10-30 Wed: Expanding the logic when burning (non-winning) tokens - now there are 2 ways: either we allow liquidity to be created and pairs are stored on the pump_eth contract, or we allow only one user to mint tokens, otherwise we will not be able to reset all balances (burn everything). Discussing both options with Aaron.

2024-10-29 Tue: Extended TokenFactory contract with uri tokens params, added more test cases: create several tokens with winner selecting. Updated create tokens logic: store new token numbers in an array - so that we can iterate through them when burning.

2024-10-28 Mon: Synchronized with the team regarding the development of pumpeth features. Received adjustments and references from Aaron regarding integration with Uniswap V3. Working on deploying a new pool feature and minting from an existing pool.


2024-10-25 Fri: Working on finalizing the burnAllAndReleaseWinner method - Changed the Token data structure and added a new class that will allow me to work with Uniswap V3 via PositionManager, instead of V2, which is used in the current version. Based on open Uniswap documentation and examples.

2024-10-24 Thu: Added contracts v2 (based on repository). Added tests for token creating and sell/buy with factory. Added more events and burnAllAndReleaseWinner method (The same logic for determining the winner with web2 service - then we call this method and it burns all tokens except the winner, for the winner we create a liquidity pool)

2024-10-23 Wed: Synced with Aaron about the contracts repository. Researched a possible solution to the problem that burnLiquidityToken is transferring to 0 address, which would revert in some ERC20 implementation. Working on changing the factory contract (paid for non-winning coins towards the winning coin, and mint more winning coins for each user (who minted other coins).

2024-10-22 Tue: Working on new "burnAll" contract method that will burn tokens in all liquidity pools and mint new tokens in the winner's liquidity pool. Method must be called by the keeper service, which will pass the winner's pool address as a parameter.

2024-10-21 Mon: Added more contracts events for swap operations. Also added expanded statistics to determine liquidity and trading volume per day and all the time. Synchronized with the team regarding the next steps.


2024-10-18 Fri: Added more test script: adds a new token to the system (launch: deploy through a factory, add liquidity, add a user profile) and then buy this token for ONE (swapETHForTokens). Began implementing new features - such as transferring a fee to the winner.

2024-10-17 Thu: Forked pump eth contracts repo to harmony. Added extended deploy scripts with more func wrappers and utils for better testing. Testing launch and swap methods.

2024-10-16 Wed: Completed the auto deployment script. I'm working on testing the main methods: mint, burn, createPair. Working on a simple scripts to reproduce cases of adding tokens and liquidity on harmony mainnet.

2024-10-15 Tue: Synchronized with Li, Artem and Aaron regarding further integration of pump.fun. Вistributed tasks and made a plan. Started deploying the repository - locally and on the mainnet. Writing a script for auto deployment.

2024-10-14 Mon: Started developing a new platform fees for creating memecoins (similar to https://pump.fun). Pumping all liquidity into ONE winner per day. I looked at the original repository on rust. Researched existing evm based forks (such as pumpeth).


2024-10-11 Fri: I synchronized with the developers of the layerzero team regarding multiple token for OftAdapter support - but unfortunately they do not currently have a ready-made solution and it is necessary to deploy a separate OftAdapter for each token. Started working on Multiple tokens OftAdapter: init new contract for rust, working on logic.

2024-10-10 Thu: Completed a working prototype for SOL devnet -> Harmony testnet: OftAdapter on Solana side and OFT token contracts on the Harmony side. Integrated into bridge cli. Now there is a problem with deployment to production - since the cost of deploying a contract on the Solana side is about 5 SOL (to high for testing and adding new tokens).

2024-10-09 Wed: I explored the possibility of reusing layerzero oft adapter v2 on the solana side for different tokens - to simplify adding new tokens and save deployment costs. Created and testing new solana version.

2024-10-08 Tue: Tested and fixed errors in harmony bridge cli. Added new features - such as loading a wallet from the command line, on request and with an aws file. Published latest version to npm.

2024-10-07 Mon: Completed and published the harmony bridge cli for transferring tokens to Harmony from EVM based chains (eth, binance, base, linea, arb). Shared instructions for use with Theo. Synced with Li and team about next goals (bridge multi tokens contract, solana support).


2024-10-04 Fri: Developed the structure and set of commands for harmony bridge cli. Moved sdk support for the current bridge there. I'm working on implementing support for direct transfers SOL to ONE with lz-solana-sdk-v2 and solana keys.

2024-10-03 Thu: Developed wrapper contracts for Oft and OftAdapter lz version 2 (those send and quota methods require the formation of structures). Redeployed the contracts - testing sending between chains. Still have errors on sending - synchronizing with the layerzero team to solve the problem.

2024-10-02 Wed: Added doc with step-by-step description of adding a new token to the bridge (deploying 3 contracts and configs for front, back repositories). Added lz-solana-sdk-v2 and @solana/web3.js libs to bridge client to interact with OFTAdapter on Solana side. Continue configuring and testing lz v2 bridging.

2024-10-01 Tue: During testing, OFT proxy on Solana received several problems related to setting the recipient's application address and receiving messages on the Harmony side. Synchronized with the layerzaero team on this issue - The Endpoint V1 and V2 contracts are backwards compatible but need to hang the OFT Program to support EPV1 OFT's message encoding. Worked on updating the recipient's contract.

2024-09-30 Mon: Added support for Moo Deng token to harmony bridge. Deployed programs for solana layerzero OFT token. Working on client side scripts (based on solana web3) to call programs methods and token transfers.


2024-09-27 Fri: Studied ways to develop programs woth Rust lang for Solana. Researched Layerzero solana repositories for transferring messages and tokens. Researched the possibility of implementing one base contract on the Solana side for all tokens. Working on proxy oft program on solana side to do simple 1-1 bridge binding.

2024-09-26 Thu: Inspected and resolved bridge issue - related to the transfer of tokens from the base chain. Switched to work on the bridge: developing a new proxy contract to support transfers Solana <-> Harmony. Based on layerzero v2 endpoint. Design overview.

2024-09-25 Wed: Worked on command line utility for bridging ERC20 tokens (based on sdk repo). Additional functionality will be network binary download, wallet creation etc

2024-09-24 Tue: Redeployed contracts with new fixes, adding more tokens and ux fixes according to Aaron's review. Tested the pano cli tool from Aaron. Synced with Li and Aaron about next goals.

2024-09-23 Mon: Worked on fixing the "insufficient collateral for fees" error - which occurred when an order is executing by the price keeper service (due to incorrect calculation of _sizeDelta in USD). Continue testing long positions (2x - 50x) feature with stable coins pairs.


2024-09-20 Fri: Worked on the ability to use stable coins in gmx long positions (we still get errors when executing positions with stable coins - since this is not provided for in contracts)

2024-09-19 Thu: By request from Soph i was investigating the problem that npm package name hmy-bridge-sdk (repo) was previously unclaimed on NPM (If this package had been claimed by an attacker, this would have led to arbitrary code execution on the affected server, as well as allowing the attacker to add backdoors inside the affected project(s) during the build process). additional info.

2024-09-16 Mon - 2024-09-19 Thu: Paid Time Off


2024-09-12 Fri: Fixed security vulnerabilities related to path-to-regexp in several repositories. Fixed another error found by Aaron - related to stuck of long positions executions (when opening USDC to ONE).

2024-09-12 Thu: completed corrections based of the review; simplified the script and contracts for adding new tokens - adjusted the settings of the contract with roles (in the old version, only the GOV address can add new tokens). Сontinue to research the possibilities of increasing Leverage GXP x10 with current design.

2024-09-11 Wed: updated GMX interface after Aaron's final review notes, worked on more updates: changing "Long" to "USD" on trading page, adding USD token as the target token under "Short" either, added links to adding liquidity for "insufficient liquidity" case.

2024-09-10 Tue: Got GX review notes from Aaron. Worked to solve issues: fixes ui texts and links, resolved leverage stuck at pending under "Positions" ans other fixes for sell and trading pages.

2024-09-09 Mon: Synced with Aaron about UniswapV3Oracles issues, looks like it's a matter of incorrect settings and pools addresses (waiting for updated information). Added a script for quickly adding/configuring tokens to gmx vault and adding liquidity via the console (for new tokens from Aaron).


2024-09-06 Fri: Added test price feeds with all oracles: UniswapV3MedianOracle, UniswapV3SpotOracle, BandOracleReader - currently only BandOracleReader returns correct values. Tested Fast price feeds and updated doc with new items for Aaron.

2024-09-05 Thu: Fixed SecondPriceFeed delta issue, tested price switching with new UniswapV3MedianOracle from Aaron - working stable. Finishing up working on test cases. Sync with Theo about documentation and missing features for the current version.

2024-09-04 Wed: Worked on test cases and test scripts for keepers services: case of price changes after creating an position, borderline cases of price differences of various oracles (firstPriceFeed and SecondPriceFeed). Got issue with auto switching to firstPriceFeed if the price goes beyond the delta. Working on a fix.

2024-09-03 Tue: Synced with Li and Aaron on priorities and next goals. Started working on test cases (and test scripts) to verify keeper services (Aaron says this is mandatory before release into production). Reviewed documentation from Theo; Get Uniswap median-over-time oracle from Aaron - reviewed and start implementing.

2024-09-02 Mon: Switched to supporting the current version of gx.country to fix several price synchronization issues in price keeper (To give Aaron a working version for auditing). Need another update for the new oracles used for synthetics (Planning to sync with Aaron to get the final set of tokens and addresses). Continue work on the "Auto-compounding Wrapper page".


2024-08-30 Fri: Completed integration and bug fixes in the base gmx interface with morphex contracts (autocompounding). Checked the main cases of adding liquidity, exchange, etc. Deployed a new version. Start work on the "Auto-compounding Wrapper page" migration - unfortunately did not find the source code for this part of the functionality in the morphex github and need to research requests and contracts call.

2024-08-29 Thu: Сreated a separate branch for the gmx interface with morphex contracts, configured deployment to a separate test domain. Still have some errors - in the process of being fixed.

2024-08-28 Wed: Researched morphex leveraged trading features for the possibility of their integration into the standard gmx interface and the current stats service.

2024-08-27 Tue: Moved updates for subgraphs in accordance with the latest versions from morphex to fix synchronization errors. Renamed the names of tokens and wrappers on the contract side for morphex-autocompounder version.

2024-08-26 Mon: Updated subgraphs with new contract version (morphex based). Continue to correct integration errors. Updated Oracles for the main version of gmx. Synced with Li and team about next goals and gmx launch.


2024-08-23 Fri: Getting errors when testing ux using the merged (autocompounder features to harmony gmx) version of contracts. Created a separate branch with a version of contracts from morphex - will use it as a basis. Deployed a new version of contracts and continue testing.

2024-08-22 Thu: Worked on updating the rewards page. Fixed subgraph and ux issues. Working on compiling documentation on deployment and changes for gmx autocompounder version.

2024-08-21 Wed: Created a separate version of the gmx interface for autocompounder fetaure. Integrated morphex contracts (with autocompounder support) to gmx interface. Mograted staked GXP page to new interface. Working on rewards page.

2024-08-20 Tue: After discussing the roadmap with the team, we decided that we are making 2 versions of GMX - in the first we fix the already working functionality (and have passed the security audit) and at the same time I am working on a version with new features: I have divided the code base and working on a separate repository and interface for the autocompounder version.

2024-08-19 Mon: Continue to work on a simple demo for the auto compounder feature within the gmx application. Implemented a page with the ability to staked GXP for deposits. Testing and debugging. Synced with Li, Frank and Artem about goals and roadmaps.


2024-08-16 Fri: Researched morphex app sources to reproduce earn wMLP and Rewards features. Unfortunately, there are no sources for ux, but the algorithm is clear from the documentation. Started working on a simple demo to demonstrate the auto compounder feature.

2024-08-15 Thu: Worked on scripts for testing the full staking cycle from deposit to get claimable rewards using contracts: RewardRouterV4, StakedGmxTracker, BonusGmxTracker, FeeGmxTracker. Get errors at the step when RewardRouter deposits the StakedGmxTracker tokens into the BonusGmxTracker - debugging the problem, working on fixing it and selecting the correct configuration.

2024-08-14 Wed: Continue work on new deploying and configuring scripts with new staking contracts for autocompounder feature. Reviewed and integrated an new oracles synth-oracle from Aaron for gmx first priceFeed.

2024-08-13 Tue: Added RewardRouterV4 and StakingRewardRouter based on contracts that use morphex.trade. Worked on updating the deployment scripts and integrating new contracts into the current system.

2024-08-12 Mon: Corrected and improved the update of Rewards scripts. Worked on adding paired wGXP with native-protocol token, GMX, to form our native liquidity pair (wGXP-GMX) without the need for a or second native liquidity pair. Synchronized with Artem regarding bug in staking dashboard validator profile update (request from Soph) - looks like there is a problem with SSR caching.


2024-08-09 Fri: Worked on autocompounder feature. Expanded the deployment script by adding the StakedGlp contract to the deployment (provide a way to transfer staked GLP tokens by unstaking from the sender and staking for the receiver). Testing with RewardRouterV2.

2024-08-08 Thu: Synced with Pablo and Theo about the most relevant additional features on top of GMX. We decided that the simplest and most relevant would be the integration of autocompounder. Morphex (gmx fork) does it natively. Researched morphex staked GLP contract. Working on integrating these contracts into our ecosystem.

2024-08-07 Wed: Synchronized with Pablo about adding additional features for GMX v1. Researched features that can be implemented on top of GMX: Autocompounding vaults, Leverage GLP, Delta-netutral vault (by example Umami delta-neutral vaults for GMX).

2024-08-06 Tue: Reviewed the draft technical documentation from Theo and Pablo. Worked om resolving earn page issues: stake v1 feature, reward stats display etc.

2024-08-05 Mon: Created an integration test to check price keeper service work (secondPriceFeed oracle) in different cases: correct price update, case when price keeper stopped updating the price, case when price keeper is hacked and sets a false price - blocking and switching to firts priceFeed (band oracle). Switched to working on the Earn page (together with Rikako).


2024-08-02 Fri: Synchronized with Artem about the latest version of the BandOracleReader contract (used as priceFeed for gmx), added support for the gmx vaultPriceFeed contract (latestAnswer view), deployed contracts for tokens used in gx.country. Testing the entire system: priceFeed contract, secondPriceFeed contract, price keeper, watcher, band-oracle-updater.

2024-08-01 Thu: Added fastPriceFeed contract price monitoring service (takes the price from independent sources, compares it with the price in the contract and blocks contracts if the delta is exceeded). Working on updating the security audit documentation to take into account the new service.

2024-07-31 Wed: Worked on adding a new watcher service for price feed keeper - which should monitor the state of the price in contracts and disable receiving prices from second price keeper if it becomes incorrect (In accordance with the security requirements of secondPriceFeed developers and security audit from Aaron).

2024-07-30 Tue: Integrated dashboard page to gmx interface. Got feedback on the security audit from Aaron - researching the highlighted points and generate a report on the necessary list of services to eliminate potential vulnerabilities.

2024-07-29 Mon: Connected a band oracle contract with a chainlink interface as first price feed (for now only for WBTC). Tested the price update. Fixed gmx interface ui issues.


2024-07-26 Fri: Created a document to discuss security audit. Added more information about using keepers and price oracles. Continue the security audit with Aaron. Working on the integration BandOracleReader (from Aaron) as priceFeed for gmx Vault. it looks like we will be able to use the same oracles for gmx and synthetix, which is much more convenient and safer.

2024-07-25 Thu: Fixed a problem with displaying charts: added gmx-h-prices subgraph, updated gmx-stats service. Reviewed and merged Rikako's interface updates. Received the first feedback on the security audit from Aaron - he highlighted the main vulnerabilities associated with the work of keepers. I will prepare additional documentation describing the work of these services and related contracts.

2024-07-24 Wed: Had a meeting with Pablo and Alania about the launch of gmx. Worked on fixes based on feedback from Pablo. Deployed an updated version of the contracts/interface/keeper.

2024-07-23 Tue: Forked a completely new gmx-contracts repository so that it had all the latest changes and also transferred edited deployment scripts and other changes to it. Updated deployment documentation and changelog. Synced with Aaron to start a security audit.

2024-07-22 Mon: Updated price keeper: functionality for updating prices bedore executing positions, added binance api for loading prices, added more APIs to track the status of the service. Worked on deploy scripts refactoring: combined the deployment into a single file, added a config with addresses that will have access to contact management, removed unnecessary comments etc


2024-07-19 Fri: Competed position keeper service module. Fixed several contracts settings on deploy: liquidation fee usd was too high and blocked ececution for increased positions, also changed access settings for routers. Continue working on production deploy script/docs.

2024-07-18 Thu: Fixed several bugs in the contract settings that interfered with the execution of positions. Also for a complete ecosystem - started working on the position keeper service (keeper executes the position at the current index price). Received feedback from Rikako on contract deployment scripts - based on this optimizing deployment scripts to make them simpler and easier to understand for auditing (plan to finish by Monday).

2024-07-17 Wed: Worked on bug fixes based on Alaina and Rikako's feedback: negative liquidation price in ux, issue with position list display, etc.; Worked on technical tests fpr swap, buy USDG, creating long/short positions.

2024-07-16 Tue: Updated deploy script: added OrderBook, redid the section with setting up PositionRouter and PositionManager contracts (This update resolved issue with long positions creation). Updated interface with new contracts.

2024-07-15 Mon: Added script for auto configuring new tokens by list (ONE, 1ETH, wBTC, 1USDC, 1USDT). Deployed new version with new contracts, token lists and ux fixes. Synced with Alaina about MVP version. Working on fixing bugs that appear during testing. (Now one of the known bugs is the display of long positions - it seems that the problem is in the configuration of the OrderBook contract)


2024-07-12 Fri: Working on updating GLP (and other) token names in the interface and at the contract level. Also working on fixing a page crash due to caching of old addresses in the local storage. Also plan to add the final set of supported tokens: ONE, 1ETH, wBTC, 1USDC, 1USDT.

2024-07-11 Thu: Fixed issue on adding liquidity via interface (mintAndStakeGlp method): added several missing contracts and corrected the address of the native token during deployment and initialization of RewardRouter. Updated interface with new contracts addresses.

2024-07-10 Wed: Updated deploy docs (added items for setting up the fastPriceFeed contract). Fixed interface issues: loading token balances, correct list of tokens, interaction with the contract. Actual version here. Have issue on adding liquidity via interface (on call mintAndStakeGlpETH method) - working on fix.

2024-07-09 Tue: Continued work on integrating the liquidity addition page (buying GLP). There are still several errors related to the fact that the price of glp is incorrectly calculated relative to tokens. Localized the problem in the contract settings during deployment - working on a fix.

2024-07-08 Mon: Integrated functionality for buying GLP and adding liquidity across the interface. After buying GLP tokens will automatically be staked and user will start earning Escrowed GMX. There are problems with the correct calculation of prices and commissions on this page - working on fixing.


2024-07-05 Fri: Synchronized with Theo about the current state of the gmx project and future goals. We identified adding liquidity as the highest priority goal, and began work on integrating functionality for buying GLP and adding liquidity across the interface. I’m also considering the possibility of using already existing uniswap pools, similar to jupiter.

2024-07-04 Thu: Updated keeper service (refactoring and bug fixes). Worked on adding test tokens on the mainnet fmx - looking for a way to create liquidity without using real native tokens, so as not to lose balance during the testing process.

2024-07-03 Wed: Tried to deploy the gmx ecosystem on the testnet - but there were problems with the deployment of the subgraph (not supported on the testnet). Therefore, for the demonstration I decided to use the existing version on the mainnet and then add test tokens to it (deployed several test tokens). Reconfigured Vault and Price Keeper for new test tokens. Working on interface updated. Also summarize the results (review of the working functionality) to form a list of remaining technical tasks.

2024-07-02 Tue: Tested the subgraph with events of the FastPriceFeedEvents contract using the new keeper. Worked on changing part of the subgraph: replacing ChainLinkAggregator events handlers. Also began deploying testnet contracts with a large number of tokens to demonstrate realistic pools, etc.

2024-07-01 Mon: Added more APIs for the keeper service: getting the average price for a token, updating the price, getting the price based on the first or second priceFeed (for debugging). The logic for calculating the median price (obtained from coinbase, redstone etc) has also been updated. Engaged in comprehensive testing: keeper - gmx swap - subgraph.


2024 Q2 Review

Porting GMX v1 to Harmony: contracts, interface, stats and subgraph; Created contracts deploy script, created scripts for adding tokens and liquidity, added docs with deploy steps description, added Harmony chain support to all repos. Configured sync and deploy for all services: subgraph, stats, interface. I have successfully tested adding liquidity, swap and position creation.

For LayerZero token airdrop, I created scripts to collect statistics for all users who used the LayerZero bridge and scripts for statistics on Swap liquidity pools that used tokens transferred through the bridge (via Swap subgraph). Reviewed and publish the proposal.


2024-06-28 Fri: Configured gmx keeper service deployment to fly.io. Service APIs are available here (now only metrics). Reworked FastPriceFeed deployment scripts to correctly add signers (multiple watcher accounts are currently setup to have the ability to send the transaction to enable spreads). Continue test/bug fixing, writing documentation on using the service and API extension for more convenient testing.

2024-06-27 Thu: Worked on Position keeper part - added eventLogger for tracking PositionRouter contract events and updating the price in the FastPriceFeed contract when executing a position. Continue working on keeper service deployment and complex service testing.

2024-06-26 Wed: Created a separate service (based on nest.js) for price feed keeper. It will be deployed on fly.io. The service consists of two parts: Price feed keeper (submits prices routinely for swaps) and Position keeper (submits prices when executing a position).

2024-06-25 Tue: Worked on keepers scripts integration. Added draft version for set price keepers scripts. Setting Price functionality and next price calculation working correctly. Working on coinbase api integration and and migration to the structure of an independent service.

2024-06-24 Mon: Researched various options for gmx secondary price feed (used to compare prices and identify deviations). Current implementation of GMX contracts relies on keppers (more about it in the following doc (Price Feeds section).). To get the price, kepper can use both oracle and the api of one/several cex. Found a good implementation of keeper from the redstone-finance team. Working on migration and integration of keeper with our contracts and CoinBase api.


2024-06-21 Fri: Gmx v1 on harmony: Worked on updating the gmx subgraph for token price aggregation - in the current version uses secondary priceFeed events and chainlinkAggregator, reworking it to interact with Band Protocol. Also researching other oracles we can use on Harmony for second PriceFeed.

2024-06-20 Thu: Gmx v1 on harmony: completed integration of the primary price feed with Band Protocol, updated deploy scripts and redeployed contracts. Worked on secondary price feed configuration and testing (currently returns an incorrect price when using 2 priceFeed with test values)

2024-06-19 Wed: Gmx v1 on harmony: fixed volume charts issue, updated gmx stats service - now volume display correctly. Synced with Artem about Band Protocol integration, continue working on new gmx priceFeed contracts and subgraphs (for supporting new price change events).

2024-06-18 Tue: Gmx v1 on harmony: Resolved deploy issue, now frontend on gx.country. Worked on migration Gmx priceFeed contracts from Chainlink (chainlink pricefeed deprecated on Harmony) to BandChain. Researched the reasons why volume is not saved for charts, fixed several subgraph issues and deployed a new version. Continue testing.

2024-06-17 Mon: Worked on compiling my Q2 results. Gmx v1 on harmony: continue work on the deployment and integration of interface services, gmx stats and subgraph - for displaying graphs (still not displayed in the final interface).


2024-06-14 Fri: Gmx v1 on harmony: Fixed sync issue for stats subgraph and deployd new version. Current subgraph sources here. Updated harmony-gmx-stats with new subgraph urls and harmony contracts. Deployed harmony-gmx-stats to fly.io. Still have issue with volume charts, other should working correct.

2024-06-13 Thu: Gmx v1 on harmony: localized the problem in the stats subgraph - removed some of the problematic contracts and events that interfered with synchronization, also updated the versions of ts packages for assembling the subgraph. Deploying a new subgraph version and continuing to test the statistics service; Also worked on deploy statistic service to fly.io;

2024-06-12 Wed: Created a script to check how many bridge wallets for airdrop LayerZero transferred more than 10, 100, 1000 USD (requested by Theo); Gmx v1 on harmony: Several more problems were found when integrating the gmx stats service with the gmx-harmony subgraph, continue debugging to localize the problem.

2024-06-11 Tue: Gmx v1 on harmony: updated ux - removed unnecessary texts and meta data; Updated contracts for gmx-raw subgraph (required to display a list of positions). Continue integration and testing subgraphs with gmx stats service. Working on new documentation on connecting and integrating subgraphs.

2024-06-10 Mon: Gmx v1 on harmony: received feedback from Rikako on the deployment script and made corrections - added deployment of the PositionRouter contract and setting up token pairs; Redeployed priceFeed contracts for tokens with correct Harmony ChainlinkAggregator integration. Updated contracts for gmx-stats subgraph and continue testing.


2024-06-07 Fri: Gmx v1 on harmony: fixed all titles, meta and icons in the interface. Waiting for approval from Aaron for deployment to gx.country. During the gmx subgraph research, it turned out that we had the integration of contracts with ChainlinkAggregator configured incorrectly. Reworking the deployment script for the correct interaction of VaultPriceFeed contracts with harmony ChainLink.

2024-06-06 Thu: Gmx v1 on harmony: investigated the issue related to the license to use the gmx interface source code and contracts - since registrar suspended the domain and ask for official permission from GMX. Worked on changing the ux interface to remove corporate logos and gmx names from there. Continue working on stats service integration/launching: pools, positions lists.

2024-06-05 Wed: Gmx v1 on harmony: Fixed issue with long/shorts positions - problem was in incorrected configured Position Router. Redeployed contracts and updated version on gm.country. Long/Shorts positions creating correctly, however still have problem with displaying charts and positions lists. Working on issue resolving.

2024-06-04 Tue: Gmx v1 on harmony: worked on deploying interface to gm.country (with Aaron). Configured and deployed stats service, now testing prices charts with new service. Still have issue with long/shorts positions, continue debugging contracts.

2024-06-03 Mon: Gmx v1 on harmony: part of the interface related to trading V2 has been removed, the current frontend is deployed on the stand. Tested the functionality related to the creation of long and shorts - an error was found related to the formation of amount - fixing it. Testing the formation of price charts.


2024-05-31 Fri: Gmx v1 on harmony: Resolved issue with wrong price on swap. Created new scripts for configuring tokens and add liqudity. Configured and added new tokens to demo stand - right now we can test WONE/BUSD/LINK swap, but with small liqudity. Working on docs for adding new tokens/liqudity.

2024-05-30 Thu: Gmx v1 on harmony: continue to investigate the problem of contracts when swapping tokens, I managed to localize the problem in the VaultReader contract in the getVaultTokenInfoV4 method. Made several fixes for the Vault, VaultReader and GlpManager contracts. Testing a new build.

2024-05-29 Wed: Posted Harmony Bridge RFP proposal using OApps’ deployer address on Ethereum; Gmx v1 on harmony: added contracts abis to deploy scripts repo, created script for setting new tokens configs and adding liquidity. Continue adding and testing new tokens to swap interface. There is a problem (error on the contract side) when swap tokens with a changing price (not stable coins). There are also errors when placing long positions. I'm debugging the problems and working on a fix.

2024-05-28 Tue: Gmx v1 on harmony: redeployed contracts with new corrected adresses (native token, gov, hrc20 etc), fixed bugs with add liquidity functionality, continue testing. Working on deploy frontend demo to gm.country; Reviewed new proposal on the “RFP Submission" from Theo. Working on submiting a proposal: post proposal using OApps’ deployer address on Ethereum.

2024-05-27 Mon: Deployed harmony-gmx v1 swap interface draft version. Now supported WONE,ONE and USDC tokens. Working on bug fixing, charts and stats integration. Reviewed Aaron's vertex notes.


2024-05-24 Fri: Migration gmx v1 to harmony: Have several issues with gmx-harmony-subgraph synchronisation. Looks like several contracts was configured incorrect. Looking for a possible cause of the problem and checking the deployment step by step;

2024-05-23 Thu: Worked on harmony gmx v1 interface: added more harmony configuration settings, fixed bugs. Forked gmx-subgraph to harmony. Inspected other backend services for gmx app: stats and main api. Stats looks ok for migration. However, сould not find repositories for the main API service, continue research.

2024-05-22 Wed: Added gmx contracts deploy notes (links, changes description, deploy instruction and logs). Forked GMX app interface repo to harmony and added harmony contracts for testing. Studing server side part integration required to run the gmx app.

2024-05-21 Tue: Completed draft version for gmx deploy script to harmony. Contracts deploy working correct, continue testing base cases with base gmx tests. Also inspecting gmx frontend part to integrate it with harmony contracts.

2024-05-20 Mon: Updated script for a more correct selection of Uniswap liquidity pools owners. Now, to get all Uniswap operations, we load all Mint events from Uniswap subgraph api and then filter events by tokens, so that the Uniswap liquidity pool creation operation contain one or more bridge token; Continue work on gmx v1 deploy script: fixed a bug with the gasPrice and gasLimit used, adjusted the binding to the native WONE token.


2024-05-17 Fri: LayerZero oken airdrop: Created a script to load user balances through the explorer API - this is how we want to identify holders with a balance of more than $50; Studied the API and methods for downloading addresses of Swap LP holders - to compare x with LZ broge transfers and generate LP owners list; Reviewed the proposal from Theo; Returning to gmx v1 tasks;

2024-05-16 Thu: Received new instructions from Theo regarding the terms of token allocation. We want to introduce 3 new categories: users that bridged, users that provided layerzero LP in Swap, users that hold at least $100 worth of layerzero OFT. For the first category we already have statistics, for the 3rd category we can obtain them based on bridge operations. I'm working on getting statistics on interaction with Swap.

2024-05-15 Wed: LayerZero oken airdrop: completed firbase dump parser and generated several csv documents with a list of addresses and the number of operations on these addresses. In total, there were about 500k unique users based on the analysis of 1.5 million transactions. Continue work on gmx v1 deploy script.

2024-05-14 Tue: LayerZero oken airdrop: Worked on calculating wallet distribution (users who bridged OFTs from 2022/07 to 091/2024). To do this, I have exported firebase db. At the moment there is a difficulty with the number of operations ~ 1.5 million - firebase does not allow running databases of this size on a local emulator or conert to csv another methods. Therefore, I am writing a parser that will go through all the dump files and pull out the necessary data.

2024-05-13 Mon: Continue working on harmony version for fmx v1 deploy/configure script. Switched to Layer Zero v2 and Sybil actions tasks. Started work on getting a statistic csv of everyone that has interacted with the bridge.


2024-05-10 Fri: Continue researching fork list and github repos. I haven’t been able to find a ready-made script for deploying and configuring all contracts yet, so I’m writing our own version based on what I can find in other projects. For example how this implemented for acria-dominik project.

2024-05-09 Thu: Double check researching results from Tej - checked GMX and other protocols that forked GMX v1. Also don't found suitable protocol for us. Right now main problem that GMX repo doesn’t have the deployment script.

2024-05-08 Wed: Inspected GMX v1 contracts deploy logs from Tej. Have a problem that all protocols including the gmx itself didn’t share the deployment script so we need to write it ourselves. Looked at repo for gmx v1 from Tej on harmony GitHub gmx-contracts.

2024-05-07 Tue: Switched to Port GMX v1. Started researching GMX v1 contracts docs and github repo. Also looked at other gmx repos: gmx-interface and gmx-subgraph.

2024-05-06 Mon: Synced with Artem on adding bridge page to Harmony Portfolio. Made a review of the architecture and source code; Started researching and deploying hyperlane according to the instructions.


2024-05-03 Fri: Got an update on the tasks from Theo, looking at the projects from the post and exploring them further on the opportunities fork to Harmony.

2024-05-02 Thu: Synchronized with Frank regarding the integration of 1Bot and harmony-llm-api with swap, bridge and copy-trading services. Working on the overall system architecture.

2024-05-01 Wed: Bridge support: Fixed several bridge explorer issues. On the recommendation of CoinGecko, we have prepared a bridge transition to a new API for fetching asset prices (new demo key plan). Continue to study available copy trading projects in various chains.

2024-04-29 Tue: Studied the list of popular GitHub projects dedicated to online copy trading. Look at several popular copy trade projects: copycat dex and MQL-CopyTrade. So far, it has not been possible to find ready-made solutions for onchain copy trading that could be migrated to Harmony.

2024-04-28 Mon: Synchronized with Theo and Frank for new tasks. Started working on the Cross-Chain Copy-Trade project. I plan to focus on the bridge/swap services part. Started exploring available options for bridges from Arbitrium the 100 assets via layerzero or other services.


2024-04-25 Fri: Synchronized with Artem regarding Layer 3 docs for Timeless with general description of decentralized protocols for open social graph (link1, link2). Сontinue to explore the implementation steps.

2024-04-24 Thu: Сontinue to explore the implementation steps (technologies and architecture) and variants of using cross-chain social profiles in shard 1 (for data availability using celestia rollup) as "layer 3" for timeless.

2024-04-24 Wed: Received from Theo and Zi new documents on a general description of the concept of decentralized protocols for an open social graph. Continue study the possibility of building layer 3 protocol as an open social graph that users onboard to through his timeless wallet.

2024-04-23 Tue: Inspected and fixed an issue with the Horizon Bridge explorer backend that was losing connection to Firestore, causing the explorer and layerzero operations to become out of sync. Synced with Theo regarding Layer 3 protocol implementation plan docs.

2024-04-22 Mon: Fixed several bugs for LlamaIndex and Together.ai RAG chatbot demo. Started research zi timeless integration docs.


2024-04-19 Fri: Configured and published demo for LlamaIndex and Together.ai RAG chatbot, with vector store data generated by pdf summary (linkedin resume). This can be tested here by asking the bot questions such as "What is a summary of this document?" etc. Sources where published here.

2024-04-18 Thu: Created app: powered by LlamaIndex and Together.ai RAG chatbot using Next.js bootstrapped with LlamaIndexTS. Also using Mixtral (through Together AI Inference) and Together Embeddings. It'll embed the PDF file in data, generate embeddings stored locally, then give you a RAG chatbot to ask questions to.

2024-04-17 Wed: Continue researching LlamaIndex TogetherLLM / sick half-day-off

2024-04-16 Tue: Researched other solutions based on ElasticSearch and LlamaIndex. Researched Together.ai RAG Integrations. The most promising and appropriate assembly looks LlamaIndex TogetherLLM

2024-04-15 Mon: Studied the possibility of using SingleStore with AWS and use cases with Shard 1. Still lacking a general architectural understanding of the system. I'm planning to do another sync with Aaron.


2024-04-12 Fri: Synced with Aaron regarding the vector store. Discussed the article: not something we can copy and paste since it is uses a lot of LinkedIn proprietary data and unique structure. We decided that we could start development with some existing systems such as SingleStore

2024-04-11 Thu: Started studying RAG and vector store for the LinkedIn resumes we have collected. Planning design vector store for Shard 1 Resume collection (have a system that can efficiently retrieve a reasonably small collection of relevant resume (100-500) from a very large pool (1M) given some context text descriptions)

2024-04-10 Wed: Fixed several errors that prevented services from starting op-batcher and op-proposer services. Started testing the interaction of rollup layers using optimism sdk.

2024-04-09 Tue: Testing and fixing synchronization stage errors for the rollup services on an aws machine. Started deploying op-batcher and op-proposer services.

2024-04-08 Mon: Deployed the op-node and op-g-eth services corrected for harmony shard 1 on an aws machine. Generated artifacts for contracts and transferred them to the AWS instance. Started testing rollup synchronization step on an AWS machine.


2024-04-05 Fri: During local testing, I received a set of block validation errors when synchronizing L2 with Harmony Shard 1 (L1). Partially disabled block validation to continue synchronization. I continue to debug the op-node service and search for the cause of the errors.

2024-04-04 Thu: To solve the problem with deploying contracts to L1 Harmony Shard 1 (described earlier), disabled the use of create 2. Also corrected several scripts to use legacy transactions instead of the EIP-1559 ones.

2024-04-03 Wed: Tried to solve the problem using Create2 deployer on Harmony. It is possible to deploy create2 to another (not default) address on Harmony. The only issue is to force Foundry to use another address instead of default one. It is technically doable, just need a bit more time to do this. But keep in mind, that the permit2 address will be different than the default (official) one. And it is impossible to deploy it to the official address, unless Harmony Mainnet will disable EIP-155 (at least for 1 transaction). Here is a long issue thread on foundry github related this issue. It is still opened btw.

2024-04-02 Tue: Continue building custom Op Stack rollup and deploying L1 contracts on Harmony Shard 1. A problem was discovered when deploying contracts. Create2 deployer that is used by Foundry (and therefore by script for deploying permit2) is not deployed on Harmony, and it cannot be deployed, because its transaction is presigned without chainId, and Harmony is EIP-155 protected, which requires chainId to be a part of the transaction.

2024-04-01 Mon: Continue building custom Op Stack rollup. Configured configs for op-node and op-geth services to support Harmony Shard 1. Proceeded to deploying and configuring contracts.


2024 Q1 Review (8 hours)

I developed the Inscriptions indexer backend and the OneScriptions hrc20 frontend. Additionally, I created the Inscriptions lottery main page and implemented the lottery backend and stats API. For the Human Protocol project, I focused on Firebase design and interaction, frontend features, locations features.

Added optimisations for the Human Protocol project: added firestore persistent Local Cache for all queries, connected infinity scroll for the actions table with lazy loading of 100 elements, optimized pages loading time (main page, feeds list) from 8 sec to 1 seс.

I conducted an architecture study for a sovereign rollup on our Shard 1. Furthermore, I deployed and integrated an OP Stack Rollup with Harmony Shard 1, which is currently in progress.

2-Week Deliverables by 2024-03-31:

Build sovereign Celestia rollup on Harmony Shard 1, deliver benchmark metrics for shard 1 as a data availability competitor to Near and Celestia (see Near's graphic)


2024-03-29 Fri: Unfortunately, it was not possible to integrate the ready-made Op Stack rollup Node build to work with Harmony Shard 1. For full deployment and support on Harmony Shard 1, we will need to build all services from source code, prepare configs, deploy and configure L1 and L2 contracts.

2024-03-28 Thu: There were compatibility problems when synchronizing op-node (optimism L2) and Harmony Shard 1. I am studying the source code and the rpc request format used to localize the problem.

2024-03-27 Wed: Synchronized with Diego about creating an aws instance for an op stack node containing op-geth and modules op-node. Deployed a op simple node in a docker container on aws, configured a grafana dashboard to display synchronization.

2024-03-26 Tue: Synchronized with Sun. Based on his meeting with Stephen, we decided to continue deploying Op Stack rollup without Celestia and Celestia with Rollkit in parallel. Because it is not yet clear what final architecture we will choose - we continue to work on several options.

2024-03-25 Mon: Launched an AWS instance to deploy a rollup. Started setting up and deploying rollup on a production instance.


2024-03-22 Fri: Launched Polaris EVM locally. Connected to celestia dev node. Looking into how we can submit proofs in to Harmony Shard 1.

2024-03-21 Thu: Had a meeting with Sun. Started working on the intial approach of deploying a rollup on Celestia as the data availability layer with Shard 1 as the proof storage. Worked on running the Polaris EVM using Rollkit by instructions.

2024-03-20 Wed: Based on the latest update from Stephen started looking at Polaris implementation for Rollkit. Looked at the following architecture Celestia as Data Availability - Shard 1 as just storing proof. Realized that we would need a wrapper around our Harmony nodes, in order for it to work as a data availability layer.

2024-03-19 Tue: Started Celestia Optimism Stack integration. Researched optimism services structure. Tried deploy a smart contract to the celestia testnet. Also tried deploy an OP Stack devnet on Celestia by instruction.

2024-03-18 Mon: Had a meeting with Sun. Explored our options and concluded that non-sovereign rollups might be a better fit for our project (using Celestia as the data availability layer and Shard 1 as the settlement layer). We think that the simplest and most convenient solution would be Сelestia Optimism. Started research an deployment of Сelestia Optimistic rollup on Shard 1.


2024-03-15 Fri: Build sovereign Celestia rollup on Harmony Shard 1: looked at Op Stack as an alternative: studied Op Stack docs, looked at optimism main services sources: op-program, op-node, op-batcher.

2024-03-14 Thu: Build sovereign Celestia rollup on Harmony Shard 1: Continue researching rollup contracts for capable of receiving, verifying proofs and transaction summaries. Looking at Blobstream as data availability - this solution contains ready-made solutions and contracts that we can try to fork and use.

2024-03-13 Wed: Build sovereign Celestia rollup on Harmony Shard 1: reviwed new docs from Sun, studied the option of using Rollkit SDK, learning how other EVM rollups interact using smart contracts.

2024-03-12 Tue: Meeting with Sun at which we discussed sovereign rollup development ways. Discussed the difficulties of using sovereign-sdk and cosoms-sdk. Made payments for the remaining 1BTC redeems requests (BTC bridge redeems). Prepared the BTC website (redeems program) for closure.

2024-03-11 Mon: Dived into building rollups using sovereign-sdk (Unfortunately, I don't have enough expirience with Rust - which prevents me from understanding some things). Also could not find adapters on Ethereum EVM. Helped Frank with shutting down the Stable Diffusion servers.


2024-03-08 Fri: sick day-off

2024-03-07 Thu: Continue researching libs, and docs to deploy a rollup using Celestia's SDK on Harmony Shard 1 (for AI, social, game data).

2024-03-06 Wed: Study of architecture sovereign rollup to use it for Harmony Shard 1 (for AI, social, game data). Researching Zero Gravity 0g.ai integration.

2024-03-05 Tue: Deployed BOB (Build on Bitcoin) relayer contracts on Harmony testnet and tried to launch BOB relayer service with testnet rpc.

2024-03-04 Mon: Exploring the possibility of launching the BOB (Build on Bitcoin) ecosystem on the Harmony side. Reviewing relayer contracts.


2024-03-02 Fri: Started researching bitcoin renaissance and BOB (Build on Bitcoin) ecosystems. Inspect BOB bitcoin light client docs.

2024-03-01 Thu: Worked on the following tasks on h.country: Added support for multiple joint filters: address, tag and location. If filter selected and selecting “all” should show all actions with that filter, selecting the user should then toggle to all actions of that filter and that user (nothing if there are no actions)

2024-02-28 Wed: Worked on the following tasks on h.country: Fixed lazy loading issue. Some UI fixes and source code refactorings.

2024-02-27 Tue: Worked on the following tasks on h.country: Fixed google maps links format - now the link also includes country, city and postcode. Removed from the list actions that include check-in without an address, also removed false positives for changing location. Minor style edits.

2024-02-26 Mon: Worked on the following tasks on h.country (PR): Connected firestore local cache in multiple tab mode. Connected infinity scroll for the actions table with lazy loading of 100 elements. Optimizations speed up page loading from 8 sec to 1 sec.


2024-02-25 Sun: Worked on the following tasks on h.country: looked at possible options for optimizing queries in firebase db to speed up application load. Considered cache options (access data offline). Reviewed user reactions feature.

2024-02-24 Sat: Worked on the following tasks on h.country PR: Added ability to set custom location on click to top right location button. Display check-in action in feeds table. Automatically update the current location if the new location is different.

2024-02-23 Fri: Worked on the following tasks on h.country: Added location pin button with new logic - opening google maps with preset location on clik. Removed m/ from slash section. Added new logic: Click on a location, get taken to that filter page. Next to the location name, there is a pin symbol. Click on that to open the google maps link to that street.

2024-02-22 Thu: Worked on the following tasks on h.country: Updated display of user links (custom links and social links) in the links area and feeds table. Added new logic: every time user refresh page, open a new tab, etc. - trigger new action of type "check_in" and update the location at the top of the page. Moved all fetch hooks to separate files. Added top locations display.

2024-02-21 Wed: Added filter by location: includes all actions that were performed by users on this street, as well as marks of some users by others. Refactored filters mechanism api.

2024-02-20 Tue: Added latest user location display to header (top left). Updated latest location search mechanism. Added logic to marked user (page owner) location when you click on a location (top left header); Added display for "locates" actions in the actions list (0/f445 (location) 0/EC68); Created Actions Context - to reload actions list from any components.

2024-02-19 Mon: Added Street name display, added display links actions, fixed links adding issue. Corrected street display format, show all actions for new users (first time visit). Added displaying latest location address in links section.


2024-02-16 Fri: Added shortcuts for user page to load page by id, address or social links. Added shortcuts for tag page. Started tag page migration. Improved adding links mechanism and url's parsing. Fixed bugs.

2024-02-15 Thu: Tested and reviewed new auth0 features. Synchronized with Theo about migration to a new project. Started transferring the logic for creating actions and selecting tags.

2024-02-14 Wed: Reviwed auth0 interactioin PR. Integrated auth0 provider to main page header. Added user's nickname (from auth0) display to main page. New messages are created with a link to the wallet address. Storing auth0 metadata in firebase (by wallet address key).

2024-02-13 Tue: Migrated more updates from remote-emitter. Fixed bugs. Started working on auth0 integration and storing oauth metadata in firebase.

2024-02-12 Mon: Merged Julia's remote-emitter to human-protocol client, migrated to typescript, refactoring.


2024-01-09 Fri: Configured telegram lottery. Updated lottery statistic. Worked on schema and flow for "message", "mention", and "interest" for human-protocol client and firebase store.

2024-01-08 Thu: Added firebase based api, for all current cases: adding user with topics, adding actions, auto increment topics counter. Configured firestore. Integrated with frontend part.

2024-01-07 Wed: Added api based on cloudflare KV service worker. Api support: adding user with topics, adding actions, auto increment topics counter. Integrated with frontend, testing, bug fixing. Added readme with api description.

2024-02-06 Tue: Added Cloudflare KV worker. Configured and deployed to harmony account. Currently, the service worker supports adding messages (in any format), receiving messages by key, and a list of keys and messages.

2024-02-05 Mon: Synced with Sun and Jenya. Researched ElastiCache: get/set data (location, media etc), and metrics. Researched ETH Denver project. Started working on service worker.


2024-01-02 Fri: Updated lottery statistic api: added statistic by telegram username. Worked on indexer api optimisations, to add universal support for all inscription types.

2024-01-01 Thu: Updated frontend and backend parts for telegram lottery. Extended lottery service: The algorithm for determining the winner has been changed (added 6 winners support). Updated filters by which lottery transactions are indexed.

*2024-01-31 Wed: Сomplete telegram bot image lottery feature. Added telegram inscriptions support to indexer. Extended indexer api to load and return telegram images by imageId from inscription.

*2024-01-30 Tue: Added support for subdomain and redirect paths from indexer so that they can be used by the client side (endpoint for .country, to get content from inscriptions). Expand the database table and add search for new fields, optimisations.

*2024-01-29 Mon: Сompleted set up for lottery 2.0. Updated frontend part. Reviewed backend PR's.


2024-01-26 Fri: Added filter for inscriptions, domains monitoring service and provide an endpoint which .country frontend can query to host content. Validation by url, parsing by types. Updated inscriptions indexer instance.

2024-01-25 Thu: Added stats api to get statistic by lottery inscriptions, unique wallets, txs by wallet. Extended logic for calculation winner: diff by 3 symbol if find several winners. Updated frontend part.

2024-01-24 Wed: Inscription lottery launch support. Added api to get tweet link by 2 letter domains, correct lottery time interval, fixed bugs. Did several ui fixes. Deployed main page to production url.

2024-01-23 Tue: Finished the demo version for the lottery main page (transaction sending, indexer, winner display). Added logic to the backend for monitoring and determining the winner, tweet link validations.

2024-01-22 Mon: Dive in the logic of operation of the inscription lottery. Started working on the main page for lottery.


2024-01-19 Fri: Worked on inscription for .country commands. Auctions through gas fee (we get information about the latest domain inscriptions from the indexer and then use it as a minimum gas for the next domain inscription). Still in progress.

2024-01-18 Thu: Reviewed XRCFactory contract from gwx.one. Reviewed Artem's updates for Indexer. Starting frontend integration with new api.

2024-01-17 Wed: Demo and transfer of the Indexer codebase to Artem for further development of .country inscriptions. Started XRCFactory contract review.

2024-01-16 Tue: Worked on resolving a bridge issue related to upgrading the default proof type to 2 (from mpt to FP). Continue research and migration of the ethscriptions-indexer into Harmony.

2024-01-15 Mon: Researched facet-vm and ethscriptions-indexer repos to explore the possibility of migrating ready-made ethscriptions solutions to Harmony.


2024-01-12 Fri: Deployed indexer and hrc20 inscriptions demo. Researched github.com/okx to added harmony chain support.

2024-01-11 Thu: Worked on frontend demo for OneScription and inscription indexer.

2024-01-10 Wed: Worked on moe project iprovements and migration to to nestjs engine. Inspecting reason and statistics of bridge errors.

2024-01-09 Tue: Looked into inscription implementation and indexer design

2024-01-08 Mon: Fixed stable diffusion backend server issues (inspected server settings for automatic disk cleanup), reviewed moe repository code


2024-12-25 Mon - 2024-01-05 Fri: Paid time off.


2023-12-22 Fri: Added indexer demo for inscriptions. Repository

2023-12-21 Thu: Helped Frank solve the problem of building a bridge on a local machine. Started working on indexer for inscriptions.

2023-12-20 Wed: Added frontend demo for sending transactions with inscription via Metamask.

2023-12-19 Tue: Investigated the problem with purchasing domains on 1.country. Research into inscription tokens.

2023-12-18 Mon: Added twitter lists manage feature, which allowed to configure sources via API endpoints (Any user with API key will be able to add / remove / update twitter list in x-api-backend). Started exploring the possibilities of deploying evm.ink to Harmony.


2023-12-15 Fri: Implemented "Talk to Me" reading data, loaded from backend. Continue working on "twitter-backend" features.

2023-12-14 Thu: Working with Artem on twitter-api backend. Added table, module and controller to store and manage twitter lists. Next it will be used to load tweets for each list.

2023-12-13 Wed: The tutorial for deploying Harmony Bridge Tokens and adding new chains has been completed. Fixed an issue with displaying "total locked" tokens. Did a live session with Sun during which we added Linea USDT support to Harmony bridge

2023-12-12 Tue: Added Linea chain and Linea usdc token support to harmony bridge: deployed contracts and update configs (1, 2, 3, 4]). Debugged issues, synced with layer zero team to enable linea<->harmony bridging.

2023-12-11 Mon: Refactored layerzero bridge frontend & backend to do deployment steps more simple. Preparing a training manual.


2023-12-8 Fri: Splited the benchmarks measurement into 5 steps. The steps are done according to Aaron's instructions. Extended relay to support more fields.

2023-12-7 Thu: Added benchmarks for "text to speach" and "speach to text" steps. Extended relay service to support stt, tts metrics. Continue working on kibana manage to display table with all benchmark stats.

2023-12-6 Wed: Tested build with DeepgaramASR to speed up record start. Working on benchmarks with Kibana.

2023-12-5 Tue: Looking for a solution for microphone handling, specifically to resolve the issue where the first word often cuts off.

2023-12-4 Mon: Fixed build errors for VoiceAi_2 app. Added more tests for CustomInstructionsHandler. Working on benchmark.


2023-12-1 Fri: Added elastic client to collect the stats for elasticsearch and next analyze the request time result in kibana. Working with Segey on resolving "Press and Hold" bug.

2023-11-30 Thu: Inspected different ways to collect benchmarks for open ai requests with different network speed. Added sentry perfomance monitoring example. Working on TimeLogger extension to collect the stats for elasticsearch and next analyze the result in kibana.

2023-11-29 Wed: Working on OpenAI Stream benchmark tests for poor network tests draft. Continue working on AppleSignInManager tests.

2023-11-28 Tue: Worked on unit tests for TimeLogger, AppleSignInManager and SettingsView modules. Added refacoring optimisations.

2023-11-27 Mon: Added buttons unit tests: GridButton, PressEffectButtonStyle, Theme. Resolving conflicts nad continue refacoring ActionsView module to decrease cyclomatic complexity.


2023-11-24 Fri: Resolved conflicts. Resolved Cancel "Tap to speak" record on press any other button. Fixed eslint errors and build issues. Refactored ActionsView to decrease cyclomatic complexity.

2023-11-23 Thu: Fixed problems when pressing multiple buttons at the same time (now you can't use "Tap to speak" and "Press and hold" at the same time).

2023-11-22 Wed: Improved "Pres & Hold" button handling (fixed lags on spam). Removed long press handling from all buttons; Added "More Action" button. Working on improving buttons handling on "many buttons press case".

2023-11-21 Tue: Fixed "Tap to Speak" issues: changed to "Tap to Speak" instead of "Tap to SPEAK", fixed colors blink on spam, fixed button delay and lags on spam. Increased openAI rate limits. Continue working on tests.

2023-11-20 Mon: Added unit tests for: ThemeManager, NetworkManager, AppleSignInManager modules. Updated NetworkManager module to improve test coverage; Added mocks for emulation network response.


2023-11-17 Fri: Configured "Voice 2" build for internal testing. Сontinue work on unit tests for stream modules and ui buttons.

2023-11-16 Thu: Resolved bugs regarding long press triggering tap functionality (when pressing long, unnecessary actions were triggered). Investigating the possibility of eliminate mic initialization lag when using "Press & Hold".

2023-11-15 Wed: Implemented button debounce after 10 taps to prevent crashes, also fixed pause/play lag. Added UI tests for new cases. Working on delay correction long press triggers in App purchase.

2023-11-14 Tue: Working on setup more comprehensive/granular sentry logs. Helped Nagesh with setup/test branch (uploads dsym file). Added swiftlint tool to enforce Swift style and conventions. Fixed project sources lint styles.

2023-11-13 Mon: Working on setup buttons debounce to have better app stability (prevent crashes etc). Working on setup more comprehensive/granular logs (sentry)


2023-11-10 Fri: Resolved issue with long press actions (Ensure long press actions do not trigger tap actions vice versa). Working on tracking active using app time and showing suggestions to share with friends and share on Twitter.

2023-11-9 Thu: Added the ability to repeat the current session to resolve repeat bug (When hitting "Repeat" during the first stream, it says "Hey" while the stream is going. It should just start again from the beginning instead.)

2023-11-8 Wed: Continue working on error capturing based on Aaron's checklist. Added action buttons metrics based on sentry ui metrics.

2023-11-7 Tue: Working on logging an iOS application using sentry.io as a platform for storing and viewing logs

2023-11-6 Mon: Working on reolving "speaker popping" issue (reproduced on quickly pause/play switch and new sessioan start). Bridge tasks support (btc tranquil payments).


2023-11-3 Fri: Working on build and review unit tests for voice ai. Updated staking dashboard ui. bridge tickets support.

2023-11-2 Thu: Working on different UI fixes: beep signal on released speak button, speak and pause bottons color changing sync, pause button blinks. Continue working on unit tests update.

2023-11-1 Wed: Working on UI fixes for Press to Speak button (colors, stuck). Unit tests for GPT Streaming module (in progress). Support for staking dashboard with mainnet shard reduction from 4 to 2.

2023-10-31 Tue: Added ChatGPTSwift lib for better gpt streaming stability / resolving bugs. Working on unit tests for Streaming module and UI components.

2023-10-30 Mon: (Resolve bugs in GPT streaming PR, specifically button interaction and async request/response handling) Continue working on GPT streaming PR


2023-10-27 Fri: Added deepgram streaming to main app. Working on button integration with streaming workflow.

2023-10-26 Thu: Reviewed Aaron's streaming code pr's. Copied streaming core sources to ios-yuriy for next whishper integration. Continue working on bugs from kanban board.

2023-10-25 Wed: Working on bug fixes for Voice AI app: the "Speak" button becomes non-functional while ChatGPT is processing, and the "Pause" button loses its functionality while the response is being processed.

2023-10-24 Tue: Continue working on full IOS end-to-end demo using Whipser, GPT4, and Elevenlabs: setup build and starting integrate Whipser speach to text via rest api.

2023-10-23 Mon: Started working on full IOS end-to-end demo "Emotion Build" (using Whipser, GPT4, and Elevenlabs). Reviewed Hey Julia project sources. Added project structure.


2023-10-20 Fri: Added more text to speech integrations to willow demo: Google Cloud, Microsoft Azure. Added select dropdown for speach to text to willow demo. Started setting up play.ht

2023-10-19 Thu: Added STT Deepgram streaming widget for wis demo. Working on table to see historical latency data to compare.

2023-10-18 Wed: Started work on Emotion build. Added TTS Core select (Elevenlabs + Willow microsoft model) for WIS end to end demo. Added more metrics (stt + llm + tts).

2023-10-17 Tue: Completed WIS end to end demo Working on streaming for WIS STT.

2023-10-16 Mon: Working on full end-to-end gui for Willow based on Willow rest api


2023-10-13 Fri: Willow demo draft Added willow demo draft. webrtc stt working, continue working on other functions (tts, sts, speaker change). Resemble AI demo

2023-10-12 Thu: Added the gdansk-ai repository, worked on deployment and setting up the environment. Started diving into api/docs for Willow inference server - for the next creation of a webapp demo.

2023-10-11 Wed: 1 part 2 part - Added storing/displaying of gpt chat history + updated UI; Refactoring - Added Mobx state manager, update layout; Working on store/display metrics for (stt-gpt-tts) (eta - today)

2023-10-10 Tue: Completed - Added tts audio player, integrated with elevenlabs (rest) and gpt streams, integrated with Artem's PR's. Code refactoring. Started work on UI improvements.

2023-10-09 Mon: I tried different options for working with TTS Elevenlabs (rest, ws), tried different sentence breakdowns. At the moment, we managed to achieve requests of 1.3 seconds for each sentences from the chatgpt stream. Also the current tts engine has many problems and often audio tracks overlap each other - a player is needed to manage them. Then i started working on the adding the tts audio player to project (smart management of audio chunks), and its integration with the chatgpt and elevenlabs stream Worked