Powering the Reputation Economy: Integrating Andromeda Core with The Graph

Community & Grants
1

Powering the Reputation Economy: Integrating Andromeda Core with The Graph

Hi everyone! :waving_hand:

I’m Ilich, Architect at Andromeda Core. I want to share our initiative with you and explain why I believe our integration with The Graph can be a turning point for data interoperability and trust in Web3.

We are building the first real-time reputation economy for DAOs and builders. We already have operational payment flows on Algorand (via the x402 protocol) and integrations with Rootstock, Arbitrum, and Optimism. Currently, we are in the process of integrating data from the Solana ecosystem to feed our reputation engine; we understand that the higher the data density, the more reliable and complete the system becomes.

Our goal is for this entire reputation and payment history to be indexed and searchable through The Graph, becoming the public data layer for dApps, wallets, and decentralized job markets.

1. The Problem: Fragmented Reputation Stifles Innovation

Today, if you have contributed to multiple protocols and chains, your history is scattered. There is no simple way for a new project to consult your worth in a unified manner. This creates enormous friction: projects waste resources manually verifying contributors, and builders cannot capitalize on their previous track record.

2. The Solution: Andromeda Core (Infrastructure for Trust)

Andromeda Core acts as a verifiable reputation aggregator. By integrating The Graph, we transform raw data from multiple chains into a decentralized, searchable reputation “Scorecard.”

To ensure the sustainability and performance of this ecosystem, we have implemented a hybrid model:

  • Public Layer: Essential reputation data indexed on The Graph, open to the community.

  • Enterprise Layer: A subscription and data-selling system via specialized APIs for companies requiring advanced analytics and high availability.

3. Why is The Graph Vital for Andromeda?

The Graph is the industry standard for data access. Integrating with it allows us to achieve:

  • Data Synergy: Enabling any dApp to consume the “Andromeda Score” without relying on centralized servers.

  • Sustainability: Revenue from our enterprise subscriptions will be reinvested into the maintenance and curation of our subgraphs, ensuring the public infrastructure remains high-quality.

4. Achievements and Roadmap

We already have the technical architecture to cross-reference reputation data between EVM and non-EVM chains (Solana/Algorand/Polkadot/ETH). The next step is to standardize this information into robust subgraphs that allow other developers to build on our foundation.

5. The Grant Plan: Focus on Development and Stability

To take this project to the next level, we are seeking a collaboration focused on two critical pillars:

  • Infrastructure Support (12-Month Runway): We recognize that latency and stability are the biggest obstacles to mass adoption. We are requesting support to cover cloud service costs for one year. This will allow us to:

    • Full Development Focus: Eliminate the operational financial burden to focus on integrating more ecosystems and improving protocol logic.

    • High Availability: Maintain a hybrid infrastructure with 99.9% uptime, combining The Graph nodes with high-performance caching layers.

    • UX Improvement: Ensure reputation queries are instantaneous, facilitating integration for DAOs and recruiters.

  • Guaranteeing Openness: We are committed to keeping the reputation core always accessible and free via The Graph. The enterprise subscription model will fund continuous expansion to new networks (such as our strategic migration to Solana).

6. Call to the Community: Help Us Refine

We want your honest feedback:

  1. Does the community believe a hybrid model (SaaS + Public Subgraph) is the right path for the sustainability of a data protocol?

  2. What other on-chain behavioral data would you like to see indexed in a reputation profile?

  3. Any technical recommendations for optimizing multi-chain indexing in this scenario?

We are open to collaborating with indexers, curators, and builders to make reputation the most valuable asset in Web3.

Thanks for reading and for your support! :green_heart:

Ilich Blanco Founder & CEO, Andromeda Computer / Gaia Ecotrack / Andromeda Core

2

Well… not even anyone from the core team commented or asked anything about the proposal. It’s a real shame.
3

Maybe you can deploy as a data service on Horizon? How to Build and Deploy a Data Service on The Graph's Horizon Framework — Lodestar Blog

4

Thanks for the response! That sounds like an excellent strategic move. Given that Andromeda Core already processes and scores complex behavioral data (TrustScores) which standard subgraphs do not cover, becoming a Data Service on Horizon aligns perfectly with our mission to offer “Trust-as-a-Service.”

I would love to explore the specific technical requirements for integrating the AVIP protocol. Do you have any resources or a point of contact you would recommend I speak with regarding the implementation of specialized reputation services on Horizon?

5

Hi Ilich,

Thanks for the detailed write-up. I’d be interested in understanding the architecture a bit better.

A few initial questions:

  • What does the data flow look like end-to-end? Specifically, are you looking to operate your own indexing infrastructure, or primarily consume and compose data that is already available through The Graph ecosystem?
  • Have you explored whether existing Subgraphs, Substreams, or cross-chain aggregation patterns could address the core data needs?
  • On the Horizon angle, is the goal specifically to coordinate a decentralized network of indexing service providers?

The reason I ask is that the use case as described reads more like a cross-chain data aggregation pattern than a need for custom indexing infrastructure. If that’s right, there may be more direct paths to what you’re trying to build.

Happy to jump on a call to work through the architecture together and make sure I’m connecting you with the most relevant Graph resources. Let me know if that would be useful and I’ll follow up by DM to coordinate the call.

6

Hello, thanks for your thoughtful questions! I really appreciate them. And yes, I’d love to hop on a call to dive deeper into this topic.

Just to give you a bit of context before we chat, we don’t limit ourselves merely to aggregating data from various chains. We view Andromeda as a synthesis layer. We ingest raw events, on Solana, we do this via Yellowstone gRPC, and for Rootstock and Arbitrum, we also consume data from their subgraphs using custom connectors, and feed all of that into our AVIP Engine. This engine calculates a deterministic TrustScore, which we then anchor back on-chain as a Merkle root, ensuring it is mathematically verifiable rather than a “black box.”

Regarding infrastructure. YES, we do consume existing subgraphs when they are available; however, much of the time, we have to perform our own indexing. The agent economy will demand sub-second latency, and we require that level of responsiveness. That said, we are actively exploring ways to transform our custom semantic connectors into Substreams, so that this reputation data becomes available to the entire Graph ecosystem not just to us.

And you’ve hit the nail on the head regarding a crucial aspect, coordination. Exactly. The goal is a decentralized network where indexing isn’t merely about making data “available,” but about providing verifiable reputation and service-level proofs that autonomous agents can rely on. That is the horizon we are building toward.

You raised the point about massive data aggregation, and you’re right; but what truly matters to us is the integrity and provenance of that data. Without those elements, the scoring system could be manipulated, and the entire framework would crumble. Therefore, that is our non-negotiable principle. It would be great to hop on a call to determine how we can align Andromeda’s ATLAS Knowledge Graph with The Graph’s latest cross-chain aggregation patterns. I think there is something truly solid here.

I look forward to your DM so we can coordinate the meeting.

7

[UPDATE] Andromeda Core AVIP v2.0 — Transparency, Development, and Open Collaboration

:pushpin: Posted by: Ilich Blanco (Andromeda Core)
:date: Date: August 17, 2026
:link: Original topic: Powering the Reputation Economy: Integrating Andromeda Core with The Graph (April 2026)

1. Introduction: Why This Post

A few months ago, I opened this thread to introduce Andromeda Core and our proposal to integrate a verifiable reputation Data Service into Graph Horizon. The community response was positive, and we held conversations with the team at The Graph Foundation.

Today, I want to share with all of you a transparent chronicle of what has happened since then, the real status of our development (which we continue to fund with our own resources), and open a space for open collaboration with the community.

We are not here to complain or to pressure anyone. We are here to inform, to show working code, and to ask for the opinions of those who are building this ecosystem. We believe the best way to move forward is through radical transparency and community dialogue.

2. Chronological Timeline (March – August 2026)

:date: March 2026

  • First contact with The Graph Foundation through official channels.

  • Submission of the initial integration proposal and a request for a meeting.

:date: April 2026

  • April 12: Publication of the original thread in this forum:

    “Powering the Reputation Economy: Integrating Andromeda Core with The Graph”

    • Presentation of the problem (fragmented reputation).

    • Proposed solution (AVIP + Subgraphs).

    • Sustainability model (public + enterprise).

    • Verify this thread

  • April 29: Public exchange with Andrew Clews (The Graph community member).

    p3
    p31296×727 204 KB

    Screenshot of the public thread.

    • Andrew suggested contacting Gwen Burgess (The Graph Foundation).

:date: May 2026

  • May 8: Virtual meeting with Tomás M. (developer at The Graph Foundation).

    • Technical presentation of AVIP v2.0.

    • Explanation of the mathematical model (TrustScore, asymmetric decay, Merkle proofs).

    • Demonstration of the multi-chain architecture.

    prueba1
    prueba11087×799 120 KB

  • prueba2
    prueba21920×1080 223 KB

  • May 12: Post-meeting follow-up.

    • Submission of the formal grant proposal ($55K, Core Grant).

    • Links to the graphical presentation and source code.

    p4
    p41088×901 116 KB

    Screenshot of the email sent to Tomás M.

  • May 14: Exchange with Andrew Clews regarding Gwen Burgess’s email.

    • Technical issue with the corporate domain (gerencia@andromedacomputer.net).

    • An alternative email was provided (andromedacomputerca@gmail.com).

    p5
    p51920×1080 209 KB

    Screenshot of the forum conversation.

  • May 22: Confirmation that Gwen’s email was not received.

    • Reiterated our willingness to collaborate.

:date: June 2026

  • June 15: New public message to Andrew Clews.

    • Connection to the autonomous agent economy (Michaelgent, Clarabotagent).

    • Proposal for AVIP as a verifiable trust layer for agents already paying for data on The Graph using x402.

  • Throughout the month:

    • No formal response to the follow-up emails sent to The Graph Foundation.

    • The foundation publishes open calls for developers seeking a verifiable reputation solution similar to our proposal.

:date: July – August 2026

  • Strategic decision:

    • In the absence of a response, Andromeda Computer assumes the development costs (infrastructure, team time, testing).

    • We began building the functional prototype in Rust/Substreams on Arbitrum One.

  • August 17 (TODAY):

    • The MVP is already processing real governance data from the Arbitrum DAO.

    • It generates TrustScores with asymmetric decay and verifiable Merkle roots.

    • Open-source code available on GitHub.

3. Current Project Status (August 2026)

:white_check_mark: What is already built (with our own resources)

Component Status
AVIP v2.1 Engine in Rust :white_check_mark: Functional. Fixed-point arithmetic (fixed + cordic) for bit-for-bit determinism.
Substreams for Arbitrum One :white_check_mark: Processes governance events (votes, proposals, executions).
TrustScore calculation (5 dimensions) :white_check_mark: With asymmetric decay (λ_pos=0.001, λ_neg=0.003).
Merkle Tree & root generation :white_check_mark: Per block batch.
JSON output with inclusion proofs :white_check_mark: Complete structure for off-chain verification.
Public repository :white_check_mark: GitHub - ilichb/coreV: Andromeda Core production system · GitHub

:counterclockwise_arrows_button: What we are developing now

  • Migration of the logic to NestJS for better API integration.

  • Improvement of the internal audit system (continuous and random tests of the model).

  • Preparation of an agnostic architecture for deployment on networks and Layer 1/Layer 2 solutions focused on autonomous AI agents (a use case already in production on The Graph with agents like Michaelgent and Clarabotagent).

:hourglass_not_done: What we need to scale

  • Collaboration with The Graph Indexers to deploy the Data Service on testnet.

  • Community feedback on the architecture, TrustScore weights, and use cases.

  • Formal response from The Graph Foundation regarding the Core Grant proposal ($55K).

4. Market Validation and Use Case (Without Unconfirmed Partnerships)

The deterministic TrustScore we have built is not a theoretical concept. It addresses a real and urgent need that is already manifesting on The Graph network:

Autonomous agents (such as Michaelgent and Clarabotagent) are already querying subgraphs and natively paying for data using x402. However, they operate “blindly” regarding the behavioral risk of the actor they are interacting with. They cannot tell if an address is trustworthy or malicious.

Our AVIP engine provides precisely that missing trust layer:

  • Before executing a payment or trusting a contract, the agent can query the TrustScore of the target address.

  • Verification is done via Merkle proofs, without needing to trust a centralized oracle.

  • The calculation is deterministic, so any The Graph Indexer can reproduce and validate it.

This use case is already mature for production, and our integration with Substreams and TAPv2 is designed to fit seamlessly into the Graph Horizon roadmap.

5. Our Position: Transparency, Dialogue, and Collaboration

I want to be absolutely clear:

  1. We are not here to confront anyone. We understand that The Graph Foundation has its own processes and priorities.

  2. We are not asking for charity. We are offering an infrastructure that:

    • Is already built (working MVP).

    • Already has technical validation (real Arbitrum data).

    • Is complementary to The Graph (not a competitor).

  3. We are continuing development with or without the grant. However, we believe that The Graph is the natural home for this Data Service, because:

    • The Graph already has the indexing infrastructure.

    • The Graph already has the payment system (TAPv2).

    • The Graph already has the agent economy (x402).

  4. We want the community’s opinion. What do you think of the architecture? What metrics would you add? What use cases do you see as most urgent?

6. Call to Action (Community)

:magnifying_glass_tilted_left: For developers and indexers

:speech_balloon: For the community at large

  • Do you think verifiable reputation should be a native service on The Graph?

  • What other on-chain data would you like to see included in the TrustScore?

  • What do you think of the hybrid model (public + enterprise) for sustainability?

:classical_building: For The Graph Foundation

  • We reiterate our willingness to collaborate.

  • The Core Grant proposal ($55K) remains on the table.

  • We are open to additional technical meetings with anyone you deem necessary.

  • Our goal is for AVIP to become a native Data Service in Graph Horizon.

7. Closing: The Future is Built Together

Andromeda Core is a living, open, and ongoing project. We have not stopped development due to a lack of response; on the contrary, we have accelerated because we believe in the vision of a Web3 where trust is verifiable, portable, and accessible to all.

The Graph has the data infrastructure.
Andromeda has the trust layer.

Together, we can enable autonomous agents, DAOs, and builders to operate with the certainty that reputation is not an opinion, but a mathematical proof.

We look forward to your comments, questions, and proposals.

Ilich Blanco
Founder & CEO, Andromeda Computer

1 Like
8

[ERRATA & UPDATE] Clarification on Andromeda Core AVIP v2.0 Status – Technical Corrections (August 2026)

Posted by: Ilich Blanco (Andromeda Core)
Date: August 21, 2026

1. Introduction

First and foremost, I want to extend a sincere thank you to the community member who took the time to perform a meticulous, line-by-line audit of our public post against the actual codebase we reviewed together in this forum.

Our core principle from the very beginning has been radical transparency. We are builders, and we know that trust is earned through verifiable facts—not polished marketing. When a discrepancy is pointed out, the only legitimate response is to acknowledge it openly, correct the record, and move forward stronger.

With that spirit, I am publishing this errata and update to clarify four specific points regarding the current status of the Andromeda Core prototype. None of these change the viability of the project, but they are essential for maintaining technical honesty with the developers, indexers, and Foundation members who are evaluating our work.

2. Summary of Technical Corrections

The following table details the specific inaccuracies in the original post and the corresponding corrections based on the actual state of the andromeda-substreams-horizon repository.

Section Original Statement Correction / Clarification
Repository Link Links to github.com/ilichb/coreV as evidence of the Substreams prototype. Correction: The correct public repository for the Substreams prototype is [Github] ilichb/andromeda-substreams-horizon)

Note: ilichb/coreV is a separate production monorepo (housing the Rootstock FES Pilot). The prototype discussed and audited in this thread lives exclusively in the andromeda-substreams-horizon repo.
Asymmetric Decay ✅ TrustScore calculation (5 dimensions) With asymmetric decay (λ_pos=0.001, λ_neg=0.003). Correction: The implementation is partially complete.

- λ_pos (positive decay) is fully integrated and active end‑to‑end in the pipeline.
- λ_neg (negative decay) is implemented as an isolated function and passes unit tests, but it is not yet invoked in the main calculation pipeline. Our internal FASE1_REPORT.md documents this honestly as “partial asymmetric decay.”
Merkle Tree & Inclusion Proofs ✅ Merkle Tree & root generation (Per block batch) + JSON output with inclusion proofs. Correction: This feature is currently not implemented in the andromeda-substreams-horizon prototype.

The Merkle root generation and proof structures are part of our architectural roadmap for the next phase. They are planned but not yet coded in the repository presented for this grant proposal. We will update the community as soon as this module is ready.
Fixed-point Arithmetic Fixed-point arithmetic (fixed + cordic) for bit-for-bit determinism. Correction: We pivoted from the initial fixed + cordic approach during development. The engine now uses substrate-fixed for deterministic arithmetic. The text was legacy copy-paste from an earlier design document and has been updated.

3. Clarification on Repository Structure

To avoid any future confusion, I want to clearly delineate our repository landscape:

  • ilichb/andromeda-substreams-horizon → The active development repository for this specific Graph integration. This contains the map_events logic, the AVIP engine with substrate-fixed, the 22 unit tests, and the real-world Arbitrum governance data processing we demonstrated.

  • ilichb/coreV → A separate, private-until-now production repository containing the Rootstock FES Pilot. It was never intended to be the point of reference for this community proposal.

I have updated the original post to point exclusively to the correct prototype repository.

4. What Remains Fully Validated (No Changes)

I want to emphasize that the following core pillars of our update remain intact and fully verified:

  • Functional Substreams on Arbitrum One: The engine successfully processes real governance events (votes, proposals, executions) from the Arbitrum DAO (verified against block 72,951,811).

  • TrustScore Calculation Logic: The mathematical model (5 dimensions) is correctly implemented, with the partial caveat regarding λ_neg mentioned above.

  • Chronological Timeline: The record of our communications with Andrew Clews, Tomás M. (The Graph Foundation), and the formal grant proposal submission on May 12 stands as documented.

  • Use Case & Market Fit: The necessity for a deterministic trust layer for autonomous agents (Michaelgent, Clarabotagent) paying via x402 remains a valid and urgent ecosystem need—even if the implementation is currently focused on the foundational indexing layer.

5. Our Commitment Going Forward

We believe that inviting the community to review our code is the highest form of accountability. These corrections do not weaken our proposal; they strengthen our credibility by demonstrating that we respond to scrutiny with action, not deflection.

Regarding the path to full asymmetric decay:

Rather than committing to an arbitrary timeline for integrating λ_neg, we want to be transparent about the actual bottleneck: connecting λ_neg is not a simple plumbing exercise. It requires a fundamental design decision: What exactly constitutes a “negative event” in the context of Arbitrum DAO governance?

We are currently defining this classification framework for negative signals. To involve the community in this design, we propose the following candidate signals as a starting point for discussion:

  • Defeated proposals: Does a proposal that fails to pass reflect negatively on the proposer’s reputation, or is it a neutral outcome?

  • Reversal of support: Should a vote cast against a proposal that the same address previously supported be weighted as a negative signal (indicating inconsistency or poor judgment)?

  • Abstentions: Should abstaining from critical votes carry any weight, or is it a purely neutral action?

We will share our proposed classification formally for community feedback before finalizing and integrating λ_neg into the main pipeline.

Other immediate next steps:

  1. We will update the original pinned post to reflect the table of corrections above.

  2. We will begin drafting the Merkle Tree module and share the architectural specs with the community for input before implementation.

6. Call to Action (Reiterated)

  • To Developers & Indexers: Please review the correct repository here: github ilichb/andromeda-substreams-horizon Your pull requests and issues are welcome.

  • To The Graph Foundation: Our Core Grant proposal ($55K) remains open. We are ready for additional technical deep-dives with your team to clarify these implementation details.

  • To the Community: Do these corrections address your concerns? More importantly, we invite your input on the “negative event” classification—what signals would you consider as negative reputation in a DAO context? Please share your thoughts in this thread.

Thank you again for holding us to the highest standard. The future of verifiable reputation depends on honest builders—and that is exactly what we intend to be.

Ilich Blanco
Founder & CEO, Andromeda Computer

10

Hi everyone, Especially @Andrew_Clews

After the last update, we conducted a deep technical audit of the entire codebase with the help of independent verifiers. Today, I’m sharing the final, verified state of the integration, along with the exact corrections applied.

1. Recap & Current Status

We are building the first Verifiable Reputation Data Service on Graph Horizon. We ingest on-chain data via Substreams, process it through a deterministic AVIP engine (Rust, fixed-point), anchor the results via Merkle trees, and verify them on-chain.

Current hard metrics:

  • 41/41 tests passing (cargo test --workspace).

  • Rust & Solidity Merkle verifiers fully synchronized (tested with 30 cross-language fixtures).

  • Live data ingestion verified on Arbitrum One mainnet.

2. Component Breakdown (Phase 1 & 2)

2.1. Substreams & Normalizer (Phase 1) :white_check_mark:

  • Indexes real events from the Arbitrum DAO Governor (ProposalCreated, VoteCast).

  • 2,906 VoteCast events detected via RPC for the first proposal; representative samples are processed end-to-end through the full pipeline.

  • Fixed-point arithmetic (Q24.40) ensures bit-for-bit deterministic results across all machines.

2.2. AVIP Engine (Phase 2 - A1 & A2) :white_check_mark:

  • Asymmetric Decay (λ_neg): Binary switch. If a wallet has any against vote, Governance and Community dimensions decay 3× faster (λ=0.003). Technical dimension always decays at λ=0.001 (by design).

  • Weighted Voting: We scale contributions by vote_weight (ARB tokens). 1 point per 1,000 ARB, with a cap of 30 points. A voter with 1M ARB has up to 30× the impact of a voter with 1K ARB—this cap prevents whale dominance while preserving meaningful signal.

2.3. Cryptographic Anchoring (Phase 2 - A3 & A4) :white_check_mark:

  • Merkle Tree (andromeda-crypto crate): keccak256 with strict domain separation (0x00 for leaves, 0x01 for nodes). Padding uses promotion (instead of duplicating the last leaf), preventing the classic CVE-2012-2459 collision vector.

  • Proof of Service: Defined as Protobuf (indexer_id, batch_root, timestamp, signature). Uses Ed25519 deterministic signatures (RFC 8032) — no RNG required in WASM.

2.4. On-Chain Verification (Phase 2 - B) :white_check_mark:

  • AVIPDataService.sol includes a verifyProof function.

  • Crucially, it now accepts numLeaves and implements the isPromoted logic to handle odd-sized batches (the majority of real-world cases), exactly matching the Rust implementation.

3. Critical Audit Findings & Corrections

We identified three significant discrepancies during the audit. All have been fixed and verified.

:red_circle: Fix 1: C² Factor (Confidence Squaring)

  • Finding: The engine was using the confidence factor directly (C) instead of squaring it (C²). Since the factor ranges between 0.7 and 1.0, squaring it reduces the score.

  • Impact: TrustScores decreased by ~22–26% (e.g., test case A: 77.2 → 59.59).

  • Correction: Applied confidence_factor * confidence_factor in calculate_score. This now aligns perfectly with the Core Paper v3.1 mathematical specification.

:red_circle: Fix 2: Merkle Domain Separation

  • Finding: leaf() and node() used the same hash function without domain prefixes, allowing an internal node hash to be presented as a leaf.

  • Correction: Implemented strict prefixes (0x00 for leaves, 0x01 for nodes) in both Rust and Solidity. Adversarial tests (internal_node_cannot_be_used_as_leaf) now pass.

:red_circle: Fix 3: Rust ↔ Solidity Synchronization

  • Finding: The Solidity verifier assumed perfect binary trees, rejecting valid proofs for odd-sized batches (3, 5, 7 leaves, etc.).

  • Correction: Added the numLeaves parameter and isPromoted logic to the Solidity contract.

  • Blindage: We generated 30 test vectors in Rust (valid + tampered) and verified them via Foundry. The cross-language sync is now bulletproof.

4. Clarification on the Mathematical Model (CoreV vs Horizon)

To avoid any confusion:

  • CoreV (Andromeda Core Production): Has the full 5-dimension AVIP engine (Technical, Governance, Community, Relations, Innovation) implemented in TypeScript (with the legacy decay bug present in some references).

  • Horizon Prototype (This Repo): Implements a simplified version of the core kernel (3 primary on-chain dimensions: Technical, Governance, Community) using aggregate-level decay rather than per-event decay. This is a deliberate engineering choice for performance and determinism in the Substreams environment. The protocol is extended with Horizon-specific infrastructure: Merkle anchoring, Proof of Service, and on-chain Solidity verification.

5. Commit History (Key Milestones)

All changes are public in the repository. Key commits include:

Phase 1 (Substreams + Normalizer):

  • fc9ce26 — Increment 1: CanonicalEvent schema, Governor ABI, Substreams manifest.

  • 3d8e6d8 — Increment 2: map_events module + AVIP engine (fixed-point, decay corrected).

  • 1b417cd — Increment 3: End-to-end run against real Arbitrum DAO Governor data.

Phase 2 (Engine extensions, Merkle, Proof of Service, Solidity):

  • 7ea355a — Phase 2 (A1+A2): Wired asymmetric decay (λ_neg) and vote_weight-based scoring.

  • 157952c — Phase 2 (A3+A4): andromeda-crypto crate + ProofOfService protobuf.

  • 6a2bccd — Phase 2 (A3/A4 close): Merkle root integration in map_events + ed25519 signing.

  • a2ca9ec — Phase 2 (B): Data Service design (PHASE2_DESIGN.md) + AVIPDataService.sol skeleton.

  • 6fd83af — Fix: Merkle domain separation (leaf/node with 0x00/0x01) + padding by promotion.

  • 163c02e — Critical C² fix (scores adjusted).

  • 4dcb85a — Solidity sync (promotion logic + numLeaves).

  • 4b1904e — Cross-language tests (Foundry + Rust fixtures).

6. Next Steps (Phase 3 — Pilot)

We are now ready for the pilot with Indexers. Our progress depends on external milestones:

  1. Horizon Testnet availability for external Data Services.

  2. Final GIP-0066 specification (Data Service base contracts).

  3. Formal feedback from The Graph Foundation on our Core Grant proposal ($55K).

What we are asking from the Foundation:

  • A technical alignment meeting to sync our AVIPDataService.sol with the final GIP-0066 interface.

  • Priority access to the Horizon testnet for the pilot.

  • A formal response to the Core Grant request.

7. Call to Action

  • To Indexers: The infrastructure is ready. Would you stake GRT to serve these reputation queries? Check the repo, run the tests (cargo test --workspace yields 41/41).

  • To The Graph Foundation: We have a working, audited MVP ready for the next step. We are eager to collaborate on finalizing the Data Service integration.

  • To Builders: What other on-chain signals should we add to the TrustScore? Your feedback shapes the roadmap.

I’ll be back soon with a live video demo showing the pipeline in action (Substreams → Engine → Merkle → On-chain verification).

Thank you for your continued support. Let’s keep building the decentralized trust layer of Web3.

Ilich Blanco
Architect, Andromeda Core

TL;DR:

  • Phases 1 & 2 are complete and audited (41/41 tests).

  • Critical fixes applied: C² (scores down ~22-26%), Merkle domain separation, Solidity sync for odd batches.

  • Vote weighting: Cap is 30× (not 1,000×) to prevent whale dominance.

  • Model: Horizon implements a simplified 3-dimension kernel of the full 5-dimension AVIP engine, with aggregate decay.

  • Commits verified: Phase 1 hashes corrected to fc9ce26, 3d8e6d8, 1b417cd; Phase 2 hashes match exactly.

  • Next step: Pilot with Indexers, pending Foundation’s testnet and GIP-0066 finalization.

12

glad you don’t give up mate

1 Like
13

Hello everyone,

First, I want to sincerely thank @AxiomaticAardvark for their comment. It is an honor to receive such support from such an active and respected member of the community. I have no intention of giving up; on the contrary, I am more motivated than ever to make this project a success.

Regarding the repository link:

I want to be completely transparent. In my last post, the repository link was temporarily blocked, but I am happy to report that my posts have been unblocked. My intention has always been to share the source code, which is the foundation of all our work.

To avoid any confusion, and in accordance with community guidelines, I confirm that the active development repository for this project is:

:link: github.com/ilichb/andromeda-substreams-horizon

gtg
gtg1667×1041 199 KB

I thank the moderators for their attention and for allowing this space to remain a hub for collaboration and technical exchange. I invite everyone to review the code, run the tests (cargo test --workspace yields 41/41), and share their feedback.

Let’s keep building together.