Add 0xEquity rental income (fees/revenue, Base)#8039
Open
asimashfaq wants to merge 2 commits into
Open
Conversation
Contributor
Summary by CodeRabbit
WalkthroughAdds a new fees adapter for the 0xequity rental-income protocol on Base. It reads FullyProven events from the IncomeAttestationRegistry, converts the reported cents amount to USD, and exports fees, supply-side revenue, and methodology metadata. Changes0xequity Fees Adapter
Estimated code review effort: 2 (Simple) | ~10 minutes Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 12 | ❌ 3❌ Failed checks (3 warnings)
✅ Passed checks (12 passed)
✨ Finishing Touches✨ Simplify code
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@fees/0xequity/index.ts`:
- Around line 56-62: The SimpleAdapter definition for the v2 adapter is missing
the required pullHourly setting. Update the adapter object in the 0xequity index
so that the version: 2 adapter explicitly includes pullHourly: true alongside
fetch, chains, start, and methodology, since this EVM log-based adapter should
preserve hourly granularity.
- Around line 44-47: Remove the incorrect dailyHoldersRevenue field from the
return in the 0xequity fee calculation, since property-token holders are already
represented by dailySupplySideRevenue and should not be counted as holders
revenue. Update the return object in the relevant fee-calculation function to
only expose the supply-side revenue for these holders, and avoid reusing
dailyRevenue as a shared reference so downstream mutations cannot alias
unrelated balances.
- Around line 36-42: The fee aggregation in `dailyFees.addUSDValue` is missing a
required label, and the adapter config does not export `breakdownMethodology`.
Update the `0xequity` adapter so the revenue source is added with an explicit
breakdown label, then add a matching `breakdownMethodology` entry that includes
every label used. Also review `dailySupplySideRevenue` in the same flow: since
it currently clones `dailyFees`, it inherits the same label, so if the
supply-side label should be different, build it with its own labeled
`addUSDValue` call instead of cloning.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 957db60b-c81a-4ff6-b693-e8478b8065f0
📒 Files selected for processing (1)
fees/0xequity/index.ts
bheluga
reviewed
Jul 9, 2026
bheluga
left a comment
bheluga
left a comment
Member
There was a problem hiding this comment.
@asimashfaq thanks for the PR
I can just see logs emitted, I don't see transfers of rental yield in USDC on any other tokens.
How can I verify
|
The 0xequity adapter exports: |
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@fees/0xequity/index.ts`:
- Around line 54-61: Add an explicit empty Revenue section to
breakdownMethodology in the 0xEquity fee module for completeness. Update the
breakdownMethodology object alongside Fees and SupplySideRevenue so it includes
Revenue: {} even though dailyRevenue has no labels, making the intent explicit
and easier to maintain.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: f84d2432-48e7-45ce-8d3f-6817045af0c8
📒 Files selected for processing (1)
fees/0xequity/index.ts
Comment on lines
+54
to
+61
| const breakdownMethodology = { | ||
| Fees: { | ||
| "Rental Yield": "Gross rental income earned by 0xEquity's tokenized real-estate properties, as proven on-chain in the IncomeAttestationRegistry. A month is counted only when it is fully proven by two independent paths (a threshold-signed attestation and a Reclaim zkTLS proof of the same bank statement) that agree on the amount.", | ||
| }, | ||
| SupplySideRevenue: { | ||
| "Rental Yield to Property Holders": "All proven rental income, which is distributed to the property-token holders (the suppliers of capital) as yield.", | ||
| }, | ||
| } |
Contributor
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value
Consider adding Revenue: {} to breakdownMethodology for completeness.
No labels are added to dailyRevenue so it's not strictly required, but including an empty Revenue entry makes it explicit that revenue is intentionally zero and prevents confusion for future maintainers adding revenue labels.
♻️ Suggested addition
const breakdownMethodology = {
Fees: {
"Rental Yield": "Gross rental income earned by 0xEquity's tokenized real-estate properties, as proven on-chain in the IncomeAttestationRegistry. A month is counted only when it is fully proven by two independent paths (a threshold-signed attestation and a Reclaim zkTLS proof of the same bank statement) that agree on the amount.",
},
SupplySideRevenue: {
"Rental Yield to Property Holders": "All proven rental income, which is distributed to the property-token holders (the suppliers of capital) as yield.",
},
+ Revenue: {},
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| const breakdownMethodology = { | |
| Fees: { | |
| "Rental Yield": "Gross rental income earned by 0xEquity's tokenized real-estate properties, as proven on-chain in the IncomeAttestationRegistry. A month is counted only when it is fully proven by two independent paths (a threshold-signed attestation and a Reclaim zkTLS proof of the same bank statement) that agree on the amount.", | |
| }, | |
| SupplySideRevenue: { | |
| "Rental Yield to Property Holders": "All proven rental income, which is distributed to the property-token holders (the suppliers of capital) as yield.", | |
| }, | |
| } | |
| const breakdownMethodology = { | |
| Fees: { | |
| "Rental Yield": "Gross rental income earned by 0xEquity's tokenized real-estate properties, as proven on-chain in the IncomeAttestationRegistry. A month is counted only when it is fully proven by two independent paths (a threshold-signed attestation and a Reclaim zkTLS proof of the same bank statement) that agree on the amount.", | |
| }, | |
| SupplySideRevenue: { | |
| "Rental Yield to Property Holders": "All proven rental income, which is distributed to the property-token holders (the suppliers of capital) as yield.", | |
| }, | |
| Revenue: {}, | |
| } |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@fees/0xequity/index.ts` around lines 54 - 61, Add an explicit empty Revenue
section to breakdownMethodology in the 0xEquity fee module for completeness.
Update the breakdownMethodology object alongside Fees and SupplySideRevenue so
it includes Revenue: {} even though dailyRevenue has no labels, making the
intent explicit and easier to maintain.
Author
|
This is not the USDC transfer .. as this more like money we receive in USD from the company WISE account. https://app.0xequity.com/listings/158-nelson-st#how-its-proven You can see this page to get more details |
Member
|
@asimashfaq looks like the contract is very new, so it won't help in tracking since 2024. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
0xEquity tokenizes real estate on Base. Each property's off-chain rental income is proven on-chain, trust-minimized, in an
IncomeAttestationRegistry(0xa67edcec210147b85b589313b05e04c680fdef02, source-verified). A calendar month (periodId = YYYYMM) is fully proven only when two independent paths agree on the amount: a threshold-signed attestation (Path A) and a Reclaim zkTLS proof of the same bank statement (Path B). On finalize the registry emitsFullyProven(token, periodId, totalMinor)—totalMinor= gross rental income in USD cents.Methodology
FullyProven.totalMinor, cents → USD), attributed to the block the month was finalized on-chain (event-based viagetLogs, so it backfills correctly).Notes
FullyProvenevents landed close together — those months render near their finalize date rather than smoothly across 2024–2026. Going forward each month is attested ~monthly, so ongoing fees render correctly.0xce827d203dC317CB8823098DCbE88fD3aE447482). The registry is already multi-property, so new properties surface with no adapter change.Validated locally with
npm test fees 0xequity→ daily fees pick up the finalized month in-window.