feat: add Brix wiTRY yield adapter

[ismailemin]

Summary

Adds a yield adapter for wiTRY, the yield-bearing staking wrapper for Brix's iTRY (a TRY-pegged stablecoin backed by Turkish money market funds).

APY methodology — distribution-anchored

Instead of sampling convertToAssets(1e18) at fixed "now" and "exactly 7 days ago" timestamps, both endpoints are anchored to actual on-chain RewardsReceived events emitted by the wiTRY vault every time yield is streamed in. This is robust to multi-day distribution gaps (Turkish public holidays, weekends, religious holidays) that would otherwise produce large false dips and spikes if a fixed now − 7d block were used.

1. Collect RewardsReceived(uint256) events from the wiTRY vault in the last 21 days.
2. end_event   = latest distribution
   start_event = latest event with ts ≤ end_event.ts − 7d (fallback: events[0])
3. vestingPeriod = getVestingPeriod() from the vault
   end_sample_ts   = min(now, end_event.ts + vestingPeriod)
   start_sample_ts = start_event.ts + vestingPeriod
4. rateEnd   = convertToAssets(1e18) at block(end_sample_ts)
   rateStart = convertToAssets(1e18) at block(start_sample_ts)
   elapsedDays = (end_sample_ts − start_sample_ts) / 86400   (dynamic, typically 7–9)
5. APY = (rateEnd / rateStart) ^ (365 / elapsedDays) − 1

Why vesting-aware sampling. wiTRY uses an Ethena V2-style vesting pattern where `totalAssets()` subtracts the unvested portion of the latest distribution. Reading `convertToAssets` at the distribution event's own block returns the pre-distribution rate — the new amount has been added to `vestingAmount` but is 0% unlocked. Sampling at `event.ts + getVestingPeriod()` (currently 3600s, read live from the contract — admin-mutable) ensures each anchor event's distribution is fully reflected.

Why robust to holidays. When no distribution arrives, both `end_event` and `start_event` stay frozen → APY stays flat. The catch-up distribution at the end of a gap shifts both anchors symmetrically (start_event also moves) → no spike. This was the key concern for a Turkish-yield protocol with frequent multi-day banking-holiday gaps.

No fee multiplier needed. The 10% performance fee is deducted by `YieldForwarder` before yield is streamed into the wiTRY vault, so `convertToAssets` growth already reflects net yield to wiTRY holders.

Pool

• Chain: Ethereum
• Symbol: wiTRY
• Receipt token: `0xE346C29b5B60Ef870b9724c57ccfbBc631e47DEE`
• Underlying: iTRY (`0xb492B4aFD9658093694CF9452D5C272e8230F3B0`)
• TVL: `totalAssets(wiTRY) × iTRY_USD_price` via DefiLlama coins
• `poolMeta`: `"APY · distribution-anchored 7d"`

Verified mainnet run

{
  "pool": "0xe346c29b5b60ef870b9724c57ccfbbc631e47dee-ethereum",
  "chain": "Ethereum",
  "project": "brix",
  "symbol": "wiTRY",
  "tvlUsd": 0,
  "apyBase": 43.61888605833464,
  "underlyingTokens": ["0xb492B4aFD9658093694CF9452D5C272e8230F3B0"],
  "poolMeta": "APY · distribution-anchored 7d",
  "url": "https://app.brix.money"
}

`tvlUsd: 0` is expected and depends on the parallel price adapter PR landing in `DefiLlama/defillama-server`.

Prerequisites

• TVL adapter must be merged (or in parallel) — yield-server requires the project slug `brix` to exist via the parallel TVL adapter PR in `DefiLlama-Adapters`.

Project info

• App: https://app.brix.money
• Website: https://www.brix.money

Allow edits by maintainers: ✅

[coderabbitai]

Warning

Rate limit exceeded

@ismailemin has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 57 minutes and 27 seconds before requesting another review.

You’ve run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: ac23aee1-ee5a-4c23-9730-291f63740f14

📥 Commits

Reviewing files that changed from the base of the PR and between 817efa2 and 096a817.

📒 Files selected for processing (1)

• src/adaptors/brix/index.js

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[github-actions]

Error while running brix adapter:

Test Suites: 1 failed, 1 total
Tests: 1 failed, 9 passed, 10 total
Snapshots: 0 total
Time: 0.291 s
Ran all test suites.

Nb of pools: 1
 

Sample pools:
┌─────────┬───────────────────────────────────────────────────────┬────────────┬─────────┬─────────┬────────┬────────────────────┬──────────────────────────────────────────────────┬──────────────────────────────────┬──────────────────────────┐
│ (index) │ pool                                                  │ chain      │ project │ symbol  │ tvlUsd │ apyBase            │ underlyingTokens                                 │ poolMeta                         │ url                      │
├─────────┼───────────────────────────────────────────────────────┼────────────┼─────────┼─────────┼────────┼────────────────────┼──────────────────────────────────────────────────┼──────────────────────────────────┼──────────────────────────┤
│ 0       │ '0xe346c29b5b60ef870b9724c57ccfbbc631e47dee-ethereum' │ 'Ethereum' │ 'brix'  │ 'wiTRY' │ 0      │ 42.876596074425755 │ [ '0xb492B4aFD9658093694CF9452D5C272e8230F3B0' ] │ 'APY · distribution-anchored 7d' │ 'https://app.brix.money' │
└─────────┴───────────────────────────────────────────────────────┴────────────┴─────────┴─────────┴────────┴────────────────────┴──────────────────────────────────────────────────┴──────────────────────────────────┴──────────────────────────┘
This adapter contains some pools with <10k TVL, these pools won't be shown in DefiLlama

[ismailemin]

CI failure is the expected slug-dependency, not an adapter issue

The one failing test is the prerequisite mentioned in the PR description:

```
expect(protocols).toContain(apy[0].project);
// Expected: "brix"
// Received array: ["binance-cex", "okx", "lido", ...]
```

This fails because the project slug `brix` does not yet exist in DefiLlama's protocol list — it gets created when the parallel TVL adapter PR (DefiLlama-Adapters#19280) merges. Once that lands, this CI will pass on a re-run.

Adapter itself: passing all other checks

```
✓ Check if link to the pool's page exist
✓ Check for unique pool ids
✓ Pool 0xe346c29b... should only contain allowed keys
✓ Expects pool to have at least one number apy field
✓ tvlUsd field should be number
✓ underlyingTokens field should be an Array of strings
✓ Expect other fields to match their data types
✓ Pool is expected to have a rewardTokens field (n/a, no rewardApy)
✓ No pool IDs are duplicated across projects

Sample pool produced:
{
pool: '0xe346c29b5b60ef870b9724c57ccfbbc631e47dee-ethereum',
chain: 'Ethereum',
project: 'brix',
symbol: 'wiTRY',
tvlUsd: 0,
apyBase: 42.876596074425755,
underlyingTokens: ['0xb492B4aFD9658093694CF9452D5C272e8230F3B0'],
poolMeta: 'APY · distribution-anchored 7d',
url: 'https://app.brix.money'
}
```

`tvlUsd: 0` is also expected and depends on the parallel price adapter PR (defillama-server#12004) landing.

Happy to coordinate merge order — TVL first → this re-runs green → Price unlocks USD value.