# Indexing Co

> Indexing Co is the data layer for programmable payments. Real-time blockchain data pipelines across 100+ chains, delivered directly to your own database.



---
title: Get In Touch
url: https://www.indexing.co/contact
---

# Get In Touch {: .text-display-regular }

<div class="contact-grid">
    <div class="contact-card">
        <div class="contact-card-header">
            <h2 class="text-subhead-bold">Schedule a Demo</h2>
            <p class="text-body-base-regular">See Indexing Co in action. Book a time with our team to discuss your use case and explore how we can help.</p>
        </div>
        <a href="https://calendly.com/dennis-indexing-co/indexing-co-demo" class="button-link button-link-small">Get A Demo</a>
    </div>
    <div class="contact-card">
        <div class="contact-card-header">
            <h2 class="text-subhead-bold">Send a Message</h2>
            <p class="text-body-base-regular">Have a question or want to discuss a specific use case? Drop us a message.</p>
        </div>
        <form id="contact-form">
    <label class="form-label">
        <span class="text-caption-medium">Name</span>
        <input name="name" type="text" required autofocus class="form-input">
    </label>
    <label class="form-label">
        <span class="text-caption-medium">Email</span>
        <input name="email" type="email" required class="form-input">
    </label>
    <label class="form-label">
        <span class="text-caption-medium">Message</span>
        <textarea name="message" rows="5" required class="form-input"></textarea>
    </label>
    <button type="submit" class="contact-submit-button">Send Message</button>
</form>
    </div>
</div>

<style>
.contact-grid {
    display: grid;
    grid-template-columns: repeat(2, 1fr);
    gap: 16px;
    width: 100%;
    margin-top: 40px;
}

.contact-card {
    display: flex;
    flex-direction: column;
    padding: 24px;
    border: 1px solid var(--UI-Gray-5, light-dark(#e5e5ea, #2c2c2e));
    border-radius: 8px;
    background-color: var(--UI-Backgrounds-Primary);
    gap: 24px;
    min-height: 400px;
    box-sizing: border-box;
}

.contact-card > a.button-link {
    margin-top: auto;
    width: 100%;
    max-width: 100%;
    box-sizing: border-box;
    flex-shrink: 0;
    line-height: 140%;
    min-height: 30px;
}

.contact-submit-button {
    margin-top: auto;
}

.contact-card-header {
    display: flex;
    flex-direction: column;
    gap: 12px;
}

.contact-card-header h2 {
    margin: 0;
}

.contact-card-header p {
    margin: 0;
    color: var(--Text-Secondary, rgba(60, 60, 67, 0.6));
}

#contact-form {
    display: flex;
    flex-direction: column;
    gap: 16px;
    flex: 1;
}

.form-label {
    display: flex;
    flex-direction: column;
    gap: 8px;
}

.form-label span {
    color: var(--Text-Primary);
}

.form-input {
    padding: 12px 16px;
    border: 1px solid var(--UI-Gray-5, light-dark(#e5e5ea, #2c2c2e));
    border-radius: 6px;
    background-color: var(--UI-Backgrounds-Primary);
    color: var(--Text-Primary);
    font-family: Inter, sans-serif;
    font-size: var(--font-size-sm, 16px);
    font-weight: 400;
    line-height: 150%;
    letter-spacing: -0.16px;
    transition: border-color 0.2s ease, box-shadow 0.2s ease;
}

.form-input:focus {
    outline: none;
    border-color: var(--Text-Primary);
    box-shadow: 0 0 0 3px light-dark(rgba(0, 0, 0, 0.05), rgba(255, 255, 255, 0.05));
}

.form-input::placeholder {
    color: var(--Text-Secondary, rgba(60, 60, 67, 0.6));
}

textarea.form-input {
    resize: vertical;
    min-height: 120px;
}

.contact-submit-button {
    /* Reset button styles */
    border: none;
    cursor: pointer;
    font-family: Inter, sans-serif;
    
    /* Match button-link-small styling exactly */
    background: var(--Text-Primary);
    color: light-dark(var(--UI-White), var(--UI-Black));
    display: flex;
    justify-content: center;
    align-items: center;
    gap: 10px;
    border-radius: 100px;
    width: 100%;
    text-decoration: none;
    transition: opacity 0.2s ease;
    padding: 8px 16px;
    font-size: var(--font-size-xs, 14px);
    font-weight: 400;
    line-height: 140%;
    letter-spacing: -0.16px;
    box-sizing: border-box;
    flex-shrink: 0;
    min-height: 30px;
}

.contact-submit-button:hover {
    opacity: 0.8;
}

@media screen and (max-width: 768px) {
    .contact-grid {
        grid-template-columns: 1fr;
        gap: 16px;
    }
    
    .contact-card {
        padding: 20px;
        min-height: auto;
    }
}
</style>

<script>
    document.getElementById("contact-form").onsubmit = function send(evt) {
        evt.preventDefault();

        const name = document.querySelector("#contact-form input[name='name']").value;
        const email = document.querySelector("#contact-form input[name='email']").value;
        const message = document.querySelector("#contact-form textarea").value;

        const payload = {
            text: `New website lead\n\n> ${message}\n\n${name} - ${email}`
        };

        document.getElementById("content").innerHTML = "<h1 class='text-headline-regular'>Thanks for reaching out! <br>We'll be in touch</h1><br><div class='dex-bit' style='margin-bottom: 200px'></div>";

        fetch("https://app.indexing.co/console/leads", {
            method: "POST",
            headers: {
                "content-type": "application/json"
            },
            body: JSON.stringify(payload)
        });
    }
</script>


---
title: The Indexing Company
url: https://www.indexing.co/index
description: The data layer for programmable payments.
---

# Stop reinventing the wheel. <br class="desktop-only">We build enterprise-grade infrastructure so you don't have to. {: .text-jumbo-regular }

[Get A Demo](https://calendly.com/dennis-indexing-co/indexing-co-demo){: .button-link }

<div class="hero-dex-block">
<div class="hero-dex-bg"></div>
<div class="hero-dex-content">
<div class="hero-dex-left">
<p class="text-subhead-regular">Read, transform, and <i>use</i> onchain data. Sub-second latency, tailored configurations, and always delivered direct to you.</p>
<a href="https://calendly.com/dennis-indexing-co/indexing-co-demo" class="button-link button-link-small" style="background:#fff;color:#000">Let's Talk</a>
</div>
</div>
</div>

#### Working with the industry's best {: .text-caption-regular }

<div id="logos">
    <!-- To add a case study to any logo, add the "has-case-study" class to the logo container div -->
    <!-- Then include the case-study-button and case-study-dialog structure inside -->
    <div class="has-case-study" style="--logo-url: url(/assets/logos/mesh-pay.svg)">
        <a href="/articles/mesh-unlocks-new-possibilities-in-crypto-transfers" class="text-legal-regular case-study-button">Case Study →</a>
        <div class="case-study-dialog">
            <div class="case-study-company text-body-base-bold">MeshPay</div>
            <div class="case-study-divider"></div>
            <p class="case-study-quote text-caption-regular">"... we were able to swiftly implement dynamic webhooks that function seamlessly across multiple chains. Their web3 data infrastructure is truly transformative—it's like the AWS of web3 data."</p>
            <div class="case-study-divider"></div>
            <div class="case-study-author">
                <div class="case-study-author-title text-legal-regular">CTO</div>
                <div class="case-study-author-name text-legal-regular">Arjun Mukherjee</div>
            </div>
            <div class="case-study-footer">
                <div class="case-study-footer-logo">
                    <img src="/assets/case-studies/arjun-avatar.png" alt="Arjun Mukherjee">
                </div>
                <a href="/articles/mesh-unlocks-new-possibilities-in-crypto-transfers" class="case-study-link text-caption-medium">Read Full Case Study</a>
            </div>
        </div>
    </div>
    <div style="--logo-url: url(/assets/logos/crystal-intelligence.svg)"></div>
    <div style="--logo-url: url(/assets/logos/cordial-systems.svg)"></div>
    <div style="--logo-url: url(/assets/logos/avalanche.svg)"></div>
    <div style="--logo-url: url(/assets/logos/clanker.svg)"></div>
    <div style="--logo-url: url(/assets/logos/rps.svg)"></div>
</div>

<div id="sub-content">
    <div id="value-props">
        <div>
            <div>
                <h2 class="text-headline-bold">Source Anywhere</h2>
                <p class="text-body-large-regular">Access data from any chain in real-time. Use the same pipelines for historical data access.</p>
                </div>
            <div>
                <h2 class="text-headline-bold">Transform Everywhere</h2>
                <p class="text-body-large-regular">Add your business logic and let infrastructure handle the rest. Distributed means control.</p>
            </div>
            <div>
                <h2 class="text-headline-bold">Deliver Just-In-Time</h2>
                <p class="text-body-large-regular">Pipelines integrate directly to your existing storage layers. No middlemen, direct to you.</p>
            </div>
        </div>

        <div class="kpi-strip">
            <div class="kpi-cell">
                <span class="kpi-number">100+</span>
                <span class="kpi-label">Supported Networks</span>
            </div>
            <div class="kpi-cell">
                <span class="kpi-number">1.6 TB</span>
                <span class="kpi-label">Processed Daily</span>
            </div>
            <div class="kpi-cell">
                <span class="kpi-number">2.54s</span>
                <span class="kpi-label">Avg Block-to-Storage</span>
            </div>
        </div>
    </div>

    <div id="directory-list">
        <div class="header">
            <p class="text-label-regular">Latest Developments</p>
            <a href="/articles" class="text-link-regular">View all</a>
        </div>
        {{LATEST_DEVELOPMENTS}}
    </div>

    <div id="use-cases">
        <div class="header">
            <p class="text-label-regular">Use Case Highlights</p>
            <a href="https://docs.indexing.co" class="text-link-regular">View docs</a>
        </div>
        <div>
            <a href="https://docs.indexing.co/examples/token_transfers">
                <svg xmlns="http://www.w3.org/2000/svg" height="24px" viewBox="0 -960 960 960" width="24px" fill="currentColor"><path d="M220-260q-92 0-156-64T0-480q0-92 64-156t156-64q37 0 71 13t61 37l68 62-60 54-62-56q-16-14-36-22t-42-8q-58 0-99 41t-41 99q0 58 41 99t99 41q22 0 42-8t36-22l310-280q27-24 61-37t71-13q92 0 156 64t64 156q0 92-64 156t-156 64q-37 0-71-13t-61-37l-68-62 60-54 62 56q16 14 36 22t42 8q58 0 99-41t41-99q0-58-41-99t-99-41q-22 0-42 8t-36 22L352-310q-27 24-61 37t-71 13Z"/></svg>
                <p class="text-body-base-regular">
                    <span>Track universal token transfers across <i>all</i> chains.</span>
                    <span>→</span>
                </p>
            </a>
            <a href="https://docs.indexing.co/examples/aave_pt1">
                <svg xmlns="http://www.w3.org/2000/svg" height="24px" viewBox="0 -960 960 960" width="24px" fill="currentColor"><path d="M400-280h160v-80H400v80Zm0-160h280v-80H400v80ZM280-600h400v-80H280v80Zm200 120ZM80-80v-80h102q-48-23-77.5-68T75-330q0-79 55.5-134.5T265-520v80q-45 0-77.5 32T155-330q0 39 24 69t61 38v-97h80v240H80Zm320-40v-80h360v-560H200v160h-80v-160q0-33 23.5-56.5T200-840h560q33 0 56.5 23.5T840-760v560q0 33-23.5 56.5T760-120H400Z"/></svg>
                <p class="text-body-base-regular">
                    <span>Decode complex payment and DeFi interactions.</span>
                    <span>→</span>
                </p>
            </a>
            <a href="https://docs.indexing.co/guide/filters/add">
                <svg xmlns="http://www.w3.org/2000/svg" height="24px" viewBox="0 -960 960 960" width="24px" fill="currentColor"><path d="M218-320q-42 0-75.5-27T100-416L71-550l-44 3-7-80q78-7 133.5-10t99.5-3q65 0 105 6t72 21q14 7 26.5 10t23.5 3q11 0 21.5-3t24.5-9q33-15 76-21.5t114-6.5q46 0 102 3t122 9l-7 79-43-3-30 137q-9 42-42 68.5T743-320h-89q-42 0-74-25.5T538-411l-27-107h-61l-27 107q-11 41-43 66t-73 25h-89Zm-40-112q3 14 14 23t25 9h89q14 0 25-8.5t14-21.5l31-121q-27-5-61-6.5t-62-1.5q-23 0-49.5.5T154-556l24 124Zm437 2q3 13 14 21.5t25 8.5h89q14 0 25-9t14-23l26-125q-20-1-46-1.5t-46-.5q-30 0-66.5 1.5T584-551l31 121Z"/></svg>
                <p class="text-body-base-regular">
                    <span>Watch millions of wallets with a single pipeline.</span>
                    <span>→</span>
                </p>
            </a>
            <a href="https://docs.indexing.co/examples/streaming_erc20_deployments">
                <svg xmlns="http://www.w3.org/2000/svg" height="24px" viewBox="0 -960 960 960" width="24px" fill="currentColor"><path d="M160-400q-33 0-56.5-23.5T80-480q0-33 23.5-56.5T160-560q33 0 56.5 23.5T240-480q0 33-23.5 56.5T160-400Zm66 228-56-56 174-174 56 56-174 174Zm120-388L172-734l56-56 174 174-56 56ZM480-80q-33 0-56.5-23.5T400-160q0-33 23.5-56.5T480-240q33 0 56.5 23.5T560-160q0 33-23.5 56.5T480-80Zm0-640q-33 0-56.5-23.5T400-800q0-33 23.5-56.5T480-880q33 0 56.5 23.5T560-800q0 33-23.5 56.5T480-720Zm134 162-56-58 176-174 56 56-176 176Zm120 386L560-346l56-56 174 174-56 56Zm66-228q-33 0-56.5-23.5T720-480q0-33 23.5-56.5T800-560q33 0 56.5 23.5T880-480q0 33-23.5 56.5T800-400Z"/></svg>
                <p class="text-body-base-regular">
                    <span>Stream real-time token deployments.</span>
                    <span>→</span>
                </p>
            </a>
            <a href="/articles/mesh-unlocks-new-possibilities-in-crypto-transfers">
                <svg xmlns="http://www.w3.org/2000/svg" height="24px" viewBox="0 -960 960 960" width="24px" fill="currentColor"><path d="M480-320q59 0 127.5-20.5T797-414q2-11 2.5-21.5t.5-21.5q0-11-8.5-18t-19.5-4q-14 5-31 10.5T698-452q-69 29-118 40.5T480-400q-52 0-102-12t-122-41q-26-11-40-16l-28-10q-11-4-19.5 3.5T160-457q0 11 .5 21.5T163-414q101 48 179.5 71T480-320Zm0 160q94 0 167-41t114-110q-88 37-155 54t-126 17q-58 0-129-17.5T198-310q40 69 113.5 109.5T480-160Zm0-400q-66 0-113-47t-47-113q0-66 47-113t113-47q66 0 113 47t47 113q0 66-47 113t-113 47Zm0-80q33 0 56.5-23.5T560-720q0-33-23.5-56.5T480-800q-33 0-56.5 23.5T400-720q0 33 23.5 56.5T480-640Zm0 560q-177 0-288.5-105T80-457q0-52 41.5-83t90.5-15q16 5 33.5 11.5T287-527q64 26 106 36.5t87 10.5q43 0 85-10t103-36q29-11 46.5-18t34.5-12q49-14 90 17t41 82q0 79-31 147.5T764-190q-54 51-127 80.5T480-80Z"/></svg>
                <p class="text-body-base-regular">
                    <span>Payment orchestration without the headaches.</span>
                    <span>→</span>
                </p>
            </a>
            <a href="https://docs.indexing.co/guide/pipelines/create#destinations">
                <svg xmlns="http://www.w3.org/2000/svg" height="24px" viewBox="0 -960 960 960" width="24px" fill="currentColor"><path d="M280-160q-50 0-85-35t-35-85H60l18-80h113q17-19 40-29.5t49-10.5q26 0 49 10.5t40 29.5h167l84-360H182l4-17q6-28 27.5-45.5T264-800h456l-37 160h117l120 160-40 200h-80q0 50-35 85t-85 35q-50 0-85-35t-35-85H400q0 50-35 85t-85 35Zm357-280h193l4-21-74-99h-95l-28 120Zm-19-273 2-7-84 360 2-7 34-146 46-200ZM20-427l20-80h220l-20 80H20Zm80-146 20-80h260l-20 80H100Zm180 333q17 0 28.5-11.5T320-280q0-17-11.5-28.5T280-320q-17 0-28.5 11.5T240-280q0 17 11.5 28.5T280-240Zm400 0q17 0 28.5-11.5T720-280q0-17-11.5-28.5T680-320q-17 0-28.5 11.5T640-280q0 17 11.5 28.5T680-240Z"/></svg>
                <p class="text-body-base-regular">
                    <span>Any network, any data, delivered to <i>you</i>.</span>
                    <span>→</span>
                </p>
            </a>
        </div>
    </div>

    <div id="cta">
        <div>
            <h1 class="text-jumbo-regular">Build with Indexing Co</h1>
            <div class="cta-buttons">
            <a href="https://docs.indexing.co">Get Started</a>
            <a href="https://calendly.com/dennis-indexing-co/indexing-co-demo">Get A Demo</a>
            </div>
        </div>
    </div>

</div>

<script>
if (/\/[A-z]+/.test(window.location.pathname)) {
    window.location = '/404';
}
</script>


---
title: Terms of Service
url: https://www.indexing.co/terms-of-service
---

<embed
    src="/assets/The Indexing Co - Terms of Service (1.30.24).pdf#view=FitH"
    type="application/pdf"
    width="100%"
    height="600px" />


---
title: Case Studies
url: https://www.indexing.co/case-studies
description: How payment platforms, identity protocols, and institutional infrastructure providers use Indexing Co's blockchain data pipelines in production.
---

<div class="cs-hero">
<h1 class="text-display-regular">Case Studies</h1>
<p class="cs-hero-sub">Real teams, real data problems, real results. Here's how companies use Indexing Co to ship faster and stop managing indexing infrastructure.</p>
</div>

<div class="cs-grid">

<div class="cs-card">
<div class="cs-card-accent"></div>
<div class="cs-card-body">
<h2 class="cs-card-title">Mesh</h2>
<p class="cs-card-subtitle">Real-Time Crypto Transfer Monitoring</p>
<p class="cs-card-desc">Mesh needed to track on-chain transfers from centralized exchanges across Bitcoin, Ethereum, and Solana. The exchanges didn't provide the data. Mesh couldn't build indexers for every chain fast enough.</p>
<p class="cs-card-desc">Indexing Co deployed dedicated webhook infrastructure that monitors transfers with dynamic filtering across multiple chains through a single interface. Mesh confirmed transactions in real time without building or maintaining any indexing infrastructure.</p>
<blockquote class="cs-quote">Indexing Co's infrastructure allowed us to swiftly implement dynamic webhooks that function across multiple chains. Their web3 data infrastructure is like the AWS of web3 data.<br><cite>Arjun Mukherjee, CTO at Mesh</cite></blockquote>
<a href="/articles/mesh-unlocks-new-possibilities-in-crypto-transfers" class="cs-read-more">Read the full story</a>
</div>
</div>

<div class="cs-card">
<div class="cs-card-accent"></div>
<div class="cs-card-body">
<h2 class="cs-card-title">Disco</h2>
<p class="cs-card-subtitle">Identity Data Across 1.2 Million Wallets</p>
<p class="cs-card-desc">Disco built a self-sovereign identity protocol where users control their on-chain data across chains. The challenge: indexing historical and real-time data for every new user, across every chain, without indexing entire blockchains upfront.</p>
<p class="cs-card-desc">Indexing Co built Just-In-Time Indexing (JITI) for Disco. Targeted backfills triggered per wallet address, combined with real-time monitoring for new transactions. At peak, Indexing Co processed data from over 1.2 million wallets. All data streamed directly to Disco's database with full ownership and composability.</p>
<a href="/articles/disco-control-your-data" class="cs-read-more">Read the full story</a>
</div>
</div>

<!-- Cordial case study - re-enable when article is published
<div class="cs-card">
<div class="cs-card-accent"></div>
<div class="cs-card-body">
<h2 class="cs-card-title">Cordial Systems</h2>
<p class="cs-card-subtitle">Institutional Wallet Infrastructure at Scale</p>
<p class="cs-card-desc">Cordial Systems manages digital assets for institutions across dozens of blockchains. As coverage grew, each new chain meant custom integrations, node management, and data normalization. Infrastructure overhead was slowing product development.</p>
<p class="cs-card-desc">Indexing Co replaced fragmented data sources with a single pipeline platform. Cordial now tracks millions of wallet addresses across chains with real-time transaction visibility and consistent schemas, delivered directly to their Postgres database.</p>
<a href="/articles/cordial-systems" class="cs-read-more">Read the full story</a>
</div>
</div>
-->

</div>

<div class="cs-cta">
<h2 class="text-headline-bold">Your Team Next</h2>
<p>If your team spends more time on data infrastructure than on your product, we should talk.</p>
<a href="/contact" class="button-link button-link-green button-link-medium">Get in Touch</a>
</div>

<style>
#page-case-studies #content {
  width: min(900px, calc(100vw - 48px));
  display: block;
  gap: 0;
}
#page-case-studies #content > h1:first-of-type { display: none; }

.cs-hero {
  margin-bottom: 56px;
}
.cs-hero h1 {
  margin-bottom: 16px;
}
.cs-hero-sub {
  font-size: 16px;
  line-height: 1.6;
  color: var(--Text-Secondary);
  max-width: 600px;
}

.cs-grid {
  display: flex;
  flex-direction: column;
  gap: 24px;
  margin-bottom: 64px;
}

.cs-card {
  border-radius: 12px;
  overflow: hidden;
  border: 1px solid var(--UI-Gray-5);
}
.cs-card-accent {
  height: 4px;
  background: var(--Brand-Indexing-Green);
}
.cs-card-body {
  padding: 32px;
}
.cs-card-title {
  font-size: 24px;
  font-weight: 500;
  letter-spacing: -0.5px;
  color: var(--Text-Primary);
  margin-bottom: 4px;
}
.cs-card-subtitle {
  font-size: 15px;
  color: var(--Brand-Indexing-Green);
  font-weight: 500;
  margin-bottom: 20px;
}
.cs-card-desc {
  font-size: 15px;
  line-height: 1.6;
  color: var(--Text-Secondary);
  margin-bottom: 12px;
}
.cs-quote {
  margin: 20px 0;
  padding: 16px 20px;
  border-left: 3px solid var(--Brand-Indexing-Green);
  font-style: italic;
  font-size: 15px;
  line-height: 1.6;
  color: var(--Text-Primary);
  background: light-dark(rgba(74, 241, 32, 0.04), rgba(74, 241, 32, 0.06));
  border-radius: 0 8px 8px 0;
}
.cs-quote cite {
  display: block;
  margin-top: 8px;
  font-style: normal;
  font-size: 13px;
  color: var(--Text-Secondary);
}
.cs-read-more {
  display: inline-block;
  margin-top: 8px;
  font-size: 14px;
  font-weight: 500;
  color: var(--Brand-Indexing-Green) !important;
  text-decoration: none !important;
}
.cs-read-more:hover {
  text-decoration: underline !important;
}

.cs-cta {
  text-align: center;
  padding: 64px 32px;
  background: light-dark(#f5f5f5, #1c1c1e);
  border-radius: 16px;
  margin-bottom: 32px;
}
.cs-cta h2 {
  margin-bottom: 12px;
  color: var(--Text-Primary);
}
.cs-cta p {
  font-size: 16px;
  color: var(--Text-Secondary);
  margin-bottom: 24px;
}
.cs-cta .button-link {
  margin: 0 auto;
}
</style>


---
title: Indexing Co vs The Graph
url: https://www.indexing.co/compare/the-graph
description: How Indexing Co's pipeline platform compares to The Graph's decentralized indexing protocol for blockchain data.
tags: Compare
---

The Graph pioneered decentralized blockchain indexing. Its subgraph model gave developers a standard way to index smart contract events and query them via GraphQL. The protocol supports 60+ chains, has a large open-source community, and runs on a token-incentivized network of indexers. That matters.

But the protocol's architecture carries trade-offs that show up fast in production. AssemblyScript-only transforms, single-chain subgraphs, full re-indexes on schema changes, and a token-based cost model that makes spend unpredictable. Indexing Co was built to solve these problems without sacrificing flexibility.

## Feature Comparison

| | Indexing Co | The Graph |
|---|---|---|
| **Architecture** | Custom pipelines | Subgraphs (decentralized protocol) |
| **Transform language** | TypeScript | AssemblyScript |
| **Query interface** | SQL, GraphQL, webhooks | GraphQL only |
| **Data destination** | Your PostgreSQL, BigQuery, webhooks | Hosted GraphQL endpoint |
| **Multi-chain** | Single pipeline definition | Separate subgraph per chain |
| **Schema changes** | Hot-swap transforms, no re-index | Full re-index from block zero |
| **Block-to-database delivery** | sub-500ms (dedicated infra) | Seconds (synced), hours to days (initial sync) |
| **Data scope** | Contracts, wallets, blocks, transactions | Contract events only |
| **Chains** | 100+ | 60+ |
| **VM support** | EVM, Solana, Cosmos, Move | EVM-focused |
| **Pricing** | Fixed pipeline subscription | GRT token fees (variable) |
| **Reorg handling** | Built-in confirmation depth | Varies by indexer |

## Where The Graph Fits

- **Decentralization is a hard requirement.** If your project needs censorship-resistant data infrastructure with no single point of failure, The Graph's decentralized indexer network delivers that.
- **Simple single-chain frontends.** A straightforward dApp on one EVM chain that only needs contract event data via GraphQL. Subgraphs handle this well.
- **Open-source community.** Large developer ecosystem, extensive documentation, and community-built subgraphs you can fork and deploy.

## Where Indexing Co Fits

- **Multi-chain production apps.** One pipeline definition covers Ethereum, Base, Arbitrum, Polygon, and more. No separate deployments per chain, no stitching data together.
- **Data beyond contract events.** Track wallets, decode transactions, index block-level data, and combine it all in a single pipeline. The Graph limits you to contract event logs.
- **Predictable costs and fast iteration.** Fixed pricing instead of variable GRT token fees. Change your schema or transforms without re-indexing from scratch. Ship updates in minutes, not days.

## Related Reading

- [Subgraphs Suck: Crypto Data Infra is Changing](/articles/subgraphs-suck)
- [The Evolution of Blockchain Indexing](/articles/evolution-of-indexing)
- [Indexing Co vs Subgraphs](/compare/subgraphs)

## Get Started

Move beyond subgraphs. Set up your first pipeline in under 10 minutes.

[Get a Demo](https://www.indexing.co/contact) | [Open the Console](https://console.indexing.co)


---
title: Indexing Co vs Building In-House
url: https://www.indexing.co/compare/build-your-own
description: The trade-offs between building custom blockchain indexing infrastructure and using Indexing Co's managed pipeline platform.
tags: Compare
---

Building your own blockchain indexing infrastructure gives you maximum control. You choose your tech stack, own every line of code, and customize everything. The question is whether the months of engineering time and ongoing maintenance are worth it when a managed platform gives you the same flexibility.

## What Building In-House Actually Means

A production-grade blockchain indexer requires:

1. **Node connections or full archive nodes**: RPC endpoints or dedicated archive nodes for each chain. Archive node storage runs terabytes per chain. Rate limiting, failover, load balancing.
2. **Block processing**: Polling or streaming blocks, handling reorgs, managing confirmation depth, detecting missed blocks.
3. **Event decoding**: ABI parsing, log decoding, transaction trace extraction. Different for every contract and every chain.
4. **Transformation**: Business logic that turns raw events into your data model.
5. **Storage**: Database schema design, migration management, write optimization for high-throughput inserts.
6. **Monitoring**: Pipeline health, latency tracking, data completeness checks, alerting on gaps or failures.
7. **Multi-chain**: Repeat steps 1-6 for every chain you need to support.

Teams that build in-house typically estimate 2-4 weeks and end up spending 3-6 months before reaching production readiness. Then maintenance begins.

## Feature Comparison

| | Indexing Co | In-House |
|---|---|---|
| **Time to production** | Hours to days | 3-6 months |
| **Ongoing maintenance** | Managed | 0.5-1 FTE |
| **Node operations** | Not required | Full/archive nodes per chain |
| **Multi-chain support** | 100+ chains, single config | Each chain is a separate project |
| **Reorg handling** | Built-in | You build it |
| **Backfill** | Managed, parallelized | You build it |
| **Monitoring** | Built-in dashboard | You build it |
| **Transform flexibility** | TypeScript, full control | Whatever you choose |
| **Data destination** | PostgreSQL, BigQuery, webhooks | Whatever you build |
| **Vendor dependency** | Yes (Indexing Co) | None |
| **Scaling** | Managed | Your ops team |
| **Cost** | Pipeline subscription | Engineering salaries + node infra |

## Where In-House Hurts

<div class="use-case-cards">
<div class="uc-card">
<span class="uc-title">The Reorg Problem</span>
<span class="uc-desc">Chain reorganizations are the hardest part. Your indexer processes block 1000, writes data, then the chain reorgs and block 1000 changes. Now you need to detect the reorg, roll back affected data, and reprocess. Miss one and your data is wrong, silently. Indexing Co handles reorgs at the platform level with configurable confirmation depth.</span>
</div>
<div class="uc-card">
<span class="uc-title">Multi-Chain Multiplication</span>
<span class="uc-desc">Adding a second chain doesn't double your work, it often triples it. Different RPC behaviors, different block structures, different finality rules, different ABI conventions. Each chain brings its own edge cases. With Indexing Co, adding a chain is a configuration change, not a project.</span>
</div>
<div class="uc-card">
<span class="uc-title">The Maintenance Tail</span>
<span class="uc-desc">The initial build is the easy part. What follows: RPC endpoint failures, chain upgrades that break block structure, database performance degradation, schema migrations on terabytes of data, on-call rotations for pipeline failures. This tail typically consumes 0.5-1 FTE permanently.</span>
</div>
<div class="uc-card">
<span class="uc-title">The Node Burden</span>
<span class="uc-desc">Running archive nodes means terabytes of storage per chain, continuous sync, failover logic, and version upgrades on every client release. Add RPC rate limits, endpoint reliability, and load balancing. Before you write a line of indexing logic, you're already running infrastructure.</span>
</div>
</div>

## When to Build In-House

Most teams that choose to build in-house underestimate the cost. A senior data engineer with blockchain experience costs $150k–$250k/year. Indexing Co costs a fraction of that and ships faster. Even teams with blockchain data as a core product benefit from outsourcing the indexing layer below their product: Indexing Co handles the pipeline infrastructure so your team can build the explorer, analytics product, or data platform on top.

<div class="when-cards"><div class="wc-card"><span class="wc-label">The narrow cases for in-house</span>
<ul>
<li>Truly unique requirements that no managed platform can satisfy, and you already have a dedicated data engineering team to build and maintain it</li>
<li>Single chain, stable schema, low event volume. The simplest possible case where the maintenance burden stays genuinely manageable</li>
</ul>
</div>
<div class="wc-card wc-card--us"><span class="wc-label">Why Indexing Co fits most cases</span>
<ul>
<li>Cheaper than a data engineer: pipeline subscription vs. $150k–$250k/year salary plus infra costs</li>
<li>Building a chain explorer or analytics platform? Indexing Co handles the indexing layer below, your team builds the product on top</li>
<li>Need fully controlled infrastructure? Indexing Co can run in your environment or co-locate with your existing infra</li>
<li>Have edge cases your in-house system can't handle? Indexing Co can run alongside, handling the hard parts while you keep ownership of the rest</li>
<li>Expertise included: reorg handling, multi-chain edge cases, chain upgrades. Handled at the platform level, not on your on-call schedule</li>
</ul>
</div>
</div>

## The Hybrid Approach

Some teams start with Indexing Co for speed, then evaluate whether to bring specific pipelines in-house as they scale. Indexing Co delivers to your database, so there's no lock-in. Your downstream code talks to your database, not to Indexing Co.

## Get Started

Skip the months of infrastructure work. Set up your first pipeline in under 10 minutes.

[Get a Demo](https://www.indexing.co/contact) | [Open the Console](https://console.indexing.co)


---
title: Compare Indexing Co
url: https://www.indexing.co/compare/index
description: How Indexing Co compares to subgraphs, managed indexing services, analytics platforms, RPC providers, and building your own blockchain data infrastructure.
tags: Compare
---

<div class="why-switch-section">

<div class="why-switch-header">
<div class="why-switch-bar"></div>
<span class="why-switch-title">Why Teams Choose Indexing Co</span>
</div>

<p class="why-switch-intro">Architectural superiority translated into execution speed. How we systematically eliminate friction compared to legacy alternatives.</p>

<div class="why-switch">

<div class="ws-stat">
<div class="ws-accent"></div>
<div class="ws-body">
<span class="ws-number">sub-500ms</span>
<span class="ws-label">Block to your database, dedicated infra</span>
<span class="ws-desc">Sub-500ms block-to-storage on dedicated infrastructure. No polling intervals, no sync delays, no API layer between the chain and your data. Shared infrastructure averages 2.54s.</span>
<span class="ws-tag">dedicated pipeline infrastructure</span>
</div>
</div>

<div class="ws-stat">
<div class="ws-accent"></div>
<div class="ws-body">
<span class="ws-number">Zero</span>
<span class="ws-label">Extra API layers</span>
<span class="ws-desc">Data lands in your own database, your own schema. Query with SQL, your ORM, or any standard tooling — no GraphQL required.</span>
<span class="ws-tag">direct database delivery</span>
</div>
</div>

<div class="ws-stat">
<div class="ws-accent"></div>
<div class="ws-body">
<span class="ws-number">100+</span>
<span class="ws-label">Live chains, one pipeline</span>
<span class="ws-desc">100+ live chains from a single integration. No separate subgraph per chain, no chain-specific SDKs. Any additional chain available on request.</span>
<span class="ws-tag">custom chain integrations on request</span>
</div>
</div>

</div>

</div>

## Pipeline and Indexing Services

<div class="compare-featured">

<div class="compare-card">
<div class="cc-header">
<span class="cc-competitor">The Graph</span>
<span class="cc-vs">VS</span>
<span class="cc-us"><span class="cc-us-logo"></span></span>
</div>
<div class="cc-tags">
<span class="cc-tag">Decentralized Network</span>
<span class="cc-tag">AssemblyScript</span>
</div>
<div class="cc-split">
<div class="cc-legacy">
<span class="cc-split-label">Legacy Model</span>
<span class="cc-split-text">Requires proprietary languages, complex DevOps for self-hosting, and tolerates significant network sync delays.</span>
</div>
<div class="cc-direct">
<span class="cc-split-label">Direct Execution</span>
<span class="cc-split-text">TypeScript pipelines written directly to your database. Zero middleware, instant sync, native developer experience.</span>
</div>
</div>
<span class="cc-cta">Compare them now →</span>
<a href="/compare/subgraphs" class="cc-link" aria-label="Compare The Graph vs Indexing Co"></a>
</div>

<div class="compare-card">
<div class="cc-header">
<span class="cc-competitor">Goldsky</span>
<span class="cc-vs">VS</span>
<span class="cc-us"><span class="cc-us-logo"></span></span>
</div>
<div class="cc-tags">
<span class="cc-tag">Managed Subgraphs</span>
<span class="cc-tag">Mirror Pipelines</span>
</div>
<div class="cc-split">
<div class="cc-legacy">
<span class="cc-split-label">Legacy Model</span>
<span class="cc-split-text">A hosted wrapper around outdated architecture. Still relies on polling mechanisms and brittle pipeline configurations.</span>
</div>
<div class="cc-direct">
<span class="cc-split-label">Direct Execution</span>
<span class="cc-split-text">Data flows directly into your own PostgreSQL. No shared API layer, no extra sync hop, no polling. Your database is the read endpoint.</span>
</div>
</div>
<span class="cc-cta">Compare them now →</span>
<a href="/compare/goldsky" class="cc-link" aria-label="Compare Goldsky vs Indexing Co"></a>
</div>

<div class="compare-card">
<div class="cc-header">
<span class="cc-competitor">Envio</span>
<span class="cc-vs">VS</span>
<span class="cc-us"><span class="cc-us-logo"></span></span>
</div>
<div class="cc-tags">
<span class="cc-tag">HyperIndex</span>
<span class="cc-tag">EVM-only</span>
</div>
<div class="cc-split">
<div class="cc-legacy">
<span class="cc-split-label">Legacy Model</span>
<span class="cc-split-text">Developer framework, self-hosted by default, EVM-only. Fast to prototype — but you own the infrastructure and ops burden.</span>
</div>
<div class="cc-direct">
<span class="cc-split-label">Direct Execution</span>
<span class="cc-split-text">Fully managed. 100+ chains. Indexing Co handles the infra layer so your team ships product, not infrastructure.</span>
</div>
</div>
<span class="cc-cta">Compare them now →</span>
<a href="/compare/envio" class="cc-link" aria-label="Compare Envio vs Indexing Co"></a>
</div>

<div class="compare-card">
<div class="cc-header">
<span class="cc-competitor">SubQuery</span>
<span class="cc-vs">VS</span>
<span class="cc-us"><span class="cc-us-logo"></span></span>
</div>
<div class="cc-tags">
<span class="cc-tag">300+ Chains</span>
<span class="cc-tag">Self-deployed SDK</span>
</div>
<div class="cc-split">
<div class="cc-legacy">
<span class="cc-split-label">Legacy Model</span>
<span class="cc-split-text">SDK you deploy yourself, token-gated at the network level, outputs to GraphQL. Broad chain support, narrow delivery options.</span>
</div>
<div class="cc-direct">
<span class="cc-split-label">Direct Execution</span>
<span class="cc-split-text">Fully managed pipeline. Data delivered in your schema to your database — no GraphQL layer, no deployment overhead.</span>
</div>
</div>
<span class="cc-cta">Compare them now →</span>
<a href="/compare/subquery" class="cc-link" aria-label="Compare SubQuery vs Indexing Co"></a>
</div>

<div class="compare-card">
<div class="cc-header">
<span class="cc-competitor">SQD (Subsquid)</span>
<span class="cc-vs">VS</span>
<span class="cc-us"><span class="cc-us-logo"></span></span>
</div>
<div class="cc-tags">
<span class="cc-tag">Decentralized Data Lake</span>
<span class="cc-tag">ZK Proofs</span>
</div>
<div class="cc-split">
<div class="cc-legacy">
<span class="cc-split-label">Legacy Model</span>
<span class="cc-split-text">Decentralized data lake with an AI/commerce focus following its 2025 acquisition. Product direction has shifted from production pipelines.</span>
</div>
<div class="cc-direct">
<span class="cc-split-label">Direct Execution</span>
<span class="cc-split-text">Real-time pipeline purpose-built for production apps. Consistent roadmap, direct database delivery, no strategy pivots.</span>
</div>
</div>
<span class="cc-cta">Compare them now →</span>
<a href="/compare/sqd" class="cc-link" aria-label="Compare SQD vs Indexing Co"></a>
</div>

</div>

## General Web3 APIs

<div class="compare-featured">

<div class="compare-card">
<div class="cc-header">
<span class="cc-competitor">Covalent</span>
<span class="cc-vs">VS</span>
<span class="cc-us"><span class="cc-us-logo"></span></span>
</div>
<div class="cc-tags">
<span class="cc-tag">Unified API</span>
<span class="cc-tag">Pre-built Schemas</span>
</div>
<div class="cc-split">
<div class="cc-legacy">
<span class="cc-split-label">Legacy Model</span>
<span class="cc-split-text">Unified REST API with pre-built data schemas. You query their structure — no control over the schema your application receives.</span>
</div>
<div class="cc-direct">
<span class="cc-split-label">Direct Execution</span>
<span class="cc-split-text">You define the transformation logic. Data lands in your database in your schema — no shared API layer to query through.</span>
</div>
</div>
<span class="cc-cta">Compare them now →</span>
<a href="/compare/covalent" class="cc-link" aria-label="Compare Covalent vs Indexing Co"></a>
</div>

<div class="compare-card">
<div class="cc-header">
<span class="cc-competitor">Moralis</span>
<span class="cc-vs">VS</span>
<span class="cc-us"><span class="cc-us-logo"></span></span>
</div>
<div class="cc-tags">
<span class="cc-tag">80+ API Endpoints</span>
<span class="cc-tag">NFT / Token / Wallet</span>
</div>
<div class="cc-split">
<div class="cc-legacy">
<span class="cc-split-label">Legacy Model</span>
<span class="cc-split-text">Pre-built endpoints for common use cases. Fast to start — but you're constrained to their data model and rate limits forever.</span>
</div>
<div class="cc-direct">
<span class="cc-split-label">Direct Execution</span>
<span class="cc-split-text">Raw event streams transformed to your data model, delivered to your infrastructure. No rate limits on your own data.</span>
</div>
</div>
<span class="cc-cta">Compare them now →</span>
<a href="/compare/moralis" class="cc-link" aria-label="Compare Moralis vs Indexing Co"></a>
</div>

<div class="compare-card">
<div class="cc-header">
<span class="cc-competitor">Bitquery</span>
<span class="cc-vs">VS</span>
<span class="cc-us"><span class="cc-us-logo"></span></span>
</div>
<div class="cc-tags">
<span class="cc-tag">GraphQL APIs</span>
<span class="cc-tag">WebSocket Streams</span>
</div>
<div class="cc-split">
<div class="cc-legacy">
<span class="cc-split-label">Legacy Model</span>
<span class="cc-split-text">GraphQL APIs with WebSocket subscriptions across 40+ chains. Every query goes through their layer — latency and rate limits included.</span>
</div>
<div class="cc-direct">
<span class="cc-split-label">Direct Execution</span>
<span class="cc-split-text">Data in your own database, your own schema. 100+ chains, no GraphQL ceiling, no third-party query layer between you and your data.</span>
</div>
</div>
<span class="cc-cta">Compare them now →</span>
<a href="/compare/bitquery" class="cc-link" aria-label="Compare Bitquery vs Indexing Co"></a>
</div>

<div class="compare-card">
<div class="cc-header">
<span class="cc-competitor">Neynar</span>
<span class="cc-vs">VS</span>
<span class="cc-us"><span class="cc-us-logo"></span></span>
</div>
<div class="cc-tags">
<span class="cc-tag">Farcaster</span>
<span class="cc-tag">Social Protocol</span>
</div>
<div class="cc-split">
<div class="cc-legacy">
<span class="cc-split-label">Legacy Model</span>
<span class="cc-split-text">Purpose-built for Farcaster. The moment your product needs on-chain data from EVM, Solana, or any other network, you need a second provider.</span>
</div>
<div class="cc-direct">
<span class="cc-split-label">Direct Execution</span>
<span class="cc-split-text">Social protocol and on-chain data from a single pipeline. Farcaster plus 100+ chains — one integration, one schema, one bill.</span>
</div>
</div>
<span class="cc-cta">Compare them now →</span>
<a href="/compare/neynar" class="cc-link" aria-label="Compare Neynar vs Indexing Co"></a>
</div>

</div>

## RPC and Node Providers

<div class="compare-featured">

<div class="compare-card">
<div class="cc-header">
<span class="cc-competitor">Alchemy</span>
<span class="cc-vs">VS</span>
<span class="cc-us"><span class="cc-us-logo"></span></span>
</div>
<div class="cc-tags">
<span class="cc-tag">RPC Provider</span>
<span class="cc-tag">Custom APIs</span>
</div>
<div class="cc-split">
<div class="cc-legacy">
<span class="cc-split-label">Legacy Model</span>
<span class="cc-split-text">Built for broadcasting transactions, not querying historical state at scale. Creates massive latency for complex data aggregations.</span>
</div>
<div class="cc-direct">
<span class="cc-split-label">Direct Execution</span>
<span class="cc-split-text">Dedicated pipeline to your own database. Complex historical state available in milliseconds via your own SQL, no API rate limits in the read path. Many teams use both.</span>
</div>
</div>
<span class="cc-cta">Compare them now →</span>
<a href="/compare/alchemy" class="cc-link" aria-label="Compare Alchemy vs Indexing Co"></a>
</div>

<div class="compare-card">
<div class="cc-header">
<span class="cc-competitor">QuickNode</span>
<span class="cc-vs">VS</span>
<span class="cc-us"><span class="cc-us-logo"></span></span>
</div>
<div class="cc-tags">
<span class="cc-tag">Node Infrastructure</span>
<span class="cc-tag">Raw Streams</span>
</div>
<div class="cc-split">
<div class="cc-legacy">
<span class="cc-split-label">Legacy Model</span>
<span class="cc-split-text">Focused on generic node access. Streaming solutions deliver raw data, lacking native transformation and decoding layers.</span>
</div>
<div class="cc-direct">
<span class="cc-split-label">Direct Execution</span>
<span class="cc-split-text">Built-in ABI decoding and custom transformation logic execute before data hits your database. Clean, structured data ready to query.</span>
</div>
</div>
<span class="cc-cta">Compare them now →</span>
<a href="/compare/quicknode" class="cc-link" aria-label="Compare QuickNode vs Indexing Co"></a>
</div>

<div class="compare-card">
<div class="cc-header">
<span class="cc-competitor">Helius</span>
<span class="cc-vs">VS</span>
<span class="cc-us"><span class="cc-us-logo"></span></span>
</div>
<div class="cc-tags">
<span class="cc-tag">Solana-only</span>
<span class="cc-tag">gRPC Streaming</span>
</div>
<div class="cc-split">
<div class="cc-legacy">
<span class="cc-split-label">Legacy Model</span>
<span class="cc-split-text">The deepest Solana infrastructure available — SOC 2, gRPC, 99.99% uptime. Best-in-class for Solana-only products.</span>
</div>
<div class="cc-direct">
<span class="cc-split-label">Direct Execution</span>
<span class="cc-split-text">Multi-chain products that include Solana get all chains from one pipeline. One integration, one schema, full coverage.</span>
</div>
</div>
<span class="cc-cta">Compare them now →</span>
<a href="/compare/helius" class="cc-link" aria-label="Compare Helius vs Indexing Co"></a>
</div>

</div>

## Analytics Platforms

<div class="compare-featured">

<div class="compare-card">
<div class="cc-header">
<span class="cc-competitor">Dune</span>
<span class="cc-vs">VS</span>
<span class="cc-us"><span class="cc-us-logo"></span></span>
</div>
<div class="cc-tags">
<span class="cc-tag">SQL Dashboards</span>
<span class="cc-tag">Community Data</span>
</div>
<div class="cc-split">
<div class="cc-legacy">
<span class="cc-split-label">Legacy Model</span>
<span class="cc-split-text">Great for analytics and dashboards. Not a data delivery platform — no webhooks, no streaming, no way to pipe data into your production database.</span>
</div>
<div class="cc-direct">
<span class="cc-split-label">Direct Execution</span>
<span class="cc-split-text">Real-time blockchain data delivered directly to your infrastructure. Use Dune for exploration, Indexing Co for production data pipelines.</span>
</div>
</div>
<span class="cc-cta">Compare them now →</span>
<a href="/compare/dune" class="cc-link" aria-label="Compare Dune vs Indexing Co"></a>
</div>

<div class="compare-card">
<div class="cc-header">
<span class="cc-competitor">Allium</span>
<span class="cc-vs">VS</span>
<span class="cc-us"><span class="cc-us-logo"></span></span>
</div>
<div class="cc-tags">
<span class="cc-tag">Enterprise Warehouse</span>
<span class="cc-tag">SOC 2</span>
</div>
<div class="cc-split">
<div class="cc-legacy">
<span class="cc-split-label">Legacy Model</span>
<span class="cc-split-text">Enterprise data warehouse delivery for analytics teams at Visa, Stripe, and Coinbase. Built for Snowflake and BigQuery, not application infrastructure.</span>
</div>
<div class="cc-direct">
<span class="cc-split-label">Direct Execution</span>
<span class="cc-split-text">Production data pipeline layer — real-time delivery to your application infrastructure, not just your analytics warehouse.</span>
</div>
</div>
<span class="cc-cta">Compare them now →</span>
<a href="/compare/allium" class="cc-link" aria-label="Compare Allium vs Indexing Co"></a>
</div>

</div>

## Building Your Own

<div class="compare-featured">

<div class="compare-card">
<div class="cc-header">
<span class="cc-competitor">Building In-House</span>
<span class="cc-vs">VS</span>
<span class="cc-us"><span class="cc-us-logo"></span></span>
</div>
<div class="cc-tags">
<span class="cc-tag">Custom Indexers</span>
<span class="cc-tag">Maximum Control</span>
</div>
<div class="cc-split">
<div class="cc-legacy">
<span class="cc-split-label">Legacy Model</span>
<span class="cc-split-text">Maximum control. Also means designing your own queue, backfill logic, chain abstraction, and transform pipeline before shipping anything.</span>
</div>
<div class="cc-direct">
<span class="cc-split-label">Direct Execution</span>
<span class="cc-split-text">Skip the infrastructure layer entirely. Define your transforms in TypeScript, point at your database, and ship the product.</span>
</div>
</div>
<span class="cc-cta">Compare them now →</span>
<a href="/compare/build-your-own" class="cc-link" aria-label="Compare Building In-House vs Indexing Co"></a>
</div>

</div>

## Quick Comparison

| Feature | Indexing Co | Goldsky | The Graph | Envio | Allium | Covalent | Alchemy | Dune | Build In-House |
|---------|------------|---------|-----------|-------|--------|----------|---------|------|----------------|
| Block-to-database delivery | sub-500ms (dedicated) | Seconds via Mirror | GraphQL API only | GraphQL API (HyperSync) | Warehouse batch | API only | API + webhooks | No | You build it |
| Data destination | Your DB/webhook | Your PostgreSQL via Mirror | Hosted GraphQL | GraphQL/DB | Snowflake/BigQuery | REST API | REST API | Dashboard | Your infra |
| Transform logic | TypeScript (custom) | AssemblyScript/SQL | AssemblyScript | TypeScript | None | None | None | SQL | Full control |
| Chains supported | 100+ live (any chain on request) | 150+ | 60+ | 70+ EVM | 100+ | 100+ | 50+ | 100+ | Whatever you build |
| Custom schemas | Yes | Limited | No | Yes | No | No | No | No | Yes |
| Historical backfill | Yes | Yes | Yes | Yes | Yes | Yes | Partial | Yes | Yes |
| Managed service | Yes | Yes | Managed/hosted | Optional | Yes | Yes | Yes | No | No |

[Talk to the Team](https://www.indexing.co/contact) | [Open the Console](https://console.indexing.co)


---
title: Indexing Co vs Neynar
url: https://www.indexing.co/compare/neynar
description: How Indexing Co's multi-chain pipeline platform compares to Neynar's Farcaster-specific data APIs.
tags: Compare
---

Neynar is the default data provider for Farcaster. It gives developers managed APIs for casts, channels, users, reactions, and everything else in the Farcaster protocol. Onboarding is fast, the free tier is generous, and if you're building exclusively on Farcaster, the developer experience is strong.

The limitation is scope. Neynar only covers Farcaster. No EVM chain data, no wallet indexing, no contract events. If your product touches both social protocol data and on-chain activity, you need a second data provider. Indexing Co covers both.

## Feature Comparison

| | Indexing Co | Neynar |
|---|---|---|
| **Scope** | Any blockchain + protocol data | Farcaster only |
| **Chain support** | 100+ EVM, Solana, Cosmos, Move | None (social protocol only) |
| **Contract event indexing** | Yes | No |
| **Wallet tracking** | Yes | No |
| **Social protocol data** | Via pipeline transforms | Native Farcaster APIs |
| **Data destination** | Your PostgreSQL, BigQuery, webhooks | Neynar-hosted API |
| **Transform language** | TypeScript | N/A (pre-built endpoints) |
| **Multi-chain pipelines** | Single definition | N/A |
| **Custom logic** | Full TypeScript control | API parameters only |
| **Pricing** | Pipeline subscription | Tiered API plans |

## Where Neynar Fits

- **Pure Farcaster apps.** If your product lives entirely within the Farcaster ecosystem and you don't need on-chain data, Neynar's APIs are purpose-built and fast to integrate.
- **Prototyping social features.** The free tier and pre-built endpoints let you ship a Farcaster integration in hours. No pipeline configuration needed.
- **Farcaster-native analytics.** Cast engagement, channel activity, user graphs. Neynar has these endpoints ready.

## Where Indexing Co Fits

- **Apps that combine social and on-chain data.** A Farcaster client that also shows token balances, NFT ownership, or DeFi positions. One platform instead of two.
- **Multi-protocol products.** If you index data from Ethereum, Base, Arbitrum, and Farcaster, Indexing Co handles all of it through pipelines. No vendor per data source.
- **Custom data models.** Neynar gives you pre-shaped API responses. Indexing Co lets you write TypeScript transforms that decode, filter, and reshape data into your own schema, delivered to your own database.

## Related Reading

- [Farcaster Data](/articles/farcaster-data)
- [Serving AI with Data Infra](/articles/serving-ai-with-data-infra)
- [Solutions for Agentic Engineering](/solutions/agentic-engineering)

## Get Started

Index Farcaster and on-chain data from a single platform.

[Get a Demo](https://www.indexing.co/contact) | [Open the Console](https://console.indexing.co)


---
title: Indexing Co vs The Graph / Subgraphs
url: https://www.indexing.co/compare/subgraphs
description: How Indexing Co's pipeline architecture compares to The Graph's subgraph model and decentralized indexing protocol.
tags: Compare
---

The Graph pioneered decentralized blockchain indexing. Its subgraph model gave developers a standard way to index smart contract events and query them via GraphQL. The protocol supports 60+ chains, has a large open-source community, and runs on a token-incentivized network of indexers. That matters.

But the architecture carries trade-offs that show up fast in production: AssemblyScript-only transforms, single-chain subgraphs, full re-indexes on schema changes, and variable GRT token pricing that makes costs unpredictable at scale. Indexing Co was built to solve these without sacrificing flexibility.

## Architecture

<div class="arch-cards">
<div class="arch-card">
<div class="arch-card-bar"></div>
<div class="arch-card-header"><div class="arch-card-dot"></div><span class="arch-card-title">Subgraphs: Contract-Centric, Coupled</span></div>
<div class="arch-card-body"><p>Subgraphs bundle indexing logic, database schema, and storage into one unit. They're contract-centric: you define which contract events to index, write mappings in AssemblyScript, and query results through a GraphQL endpoint.</p><p>This coupling creates friction:</p><ul><li>Change your schema? Re-index from block zero.</li><li>Need data from a new chain? Deploy a separate subgraph.</li><li>Want SQL access? Not available, GraphQL only.</li><li>Need wallet data, block data, or cross-chain data? Out of scope.</li></ul></div>
</div>
<div class="arch-card arch-card--us">
<div class="arch-card-bar"></div>
<div class="arch-card-header"><div class="arch-card-dot"></div><span class="arch-card-title">Indexing Co: Pipeline Architecture, Decoupled</span></div>
<div class="arch-card-body"><p>Indexing Co separates sourcing, transformation, and delivery into independent layers. Each layer can change without affecting the others.</p><ul><li><strong>Source</strong>: Connect to any chain. Add new chains without rewriting transforms.</li><li><strong>Transform</strong>: Write TypeScript (not AssemblyScript). Change your logic without re-indexing.</li><li><strong>Deliver</strong>: Data goes to your PostgreSQL, BigQuery, webhook, or GraphQL endpoint. Your choice.</li></ul></div>
</div>
</div>

## Feature Comparison

| | Indexing Co | The Graph / Subgraphs |
|---|---|---|
| **Language** | TypeScript | AssemblyScript |
| **Query interface** | SQL, GraphQL, webhooks | GraphQL only |
| **Data destination** | Your database | Hosted GraphQL endpoint |
| **Multi-chain** | Single pipeline definition | Separate subgraph per chain |
| **Schema changes** | Hot-swap transforms | Full re-index required |
| **Block-to-database delivery** | sub-500ms (dedicated infra) | Seconds when synced, hours to days for initial sync |
| **Data scope** | Contracts, wallets, blocks, transactions | Contract events only |
| **VM support** | EVM, Solana, Cosmos, Move | EVM-focused |
| **Chains** | 100+ | 60+ |
| **Pricing** | Fixed pipeline subscription | GRT token fees (variable) |
| **Reorg handling** | Built-in confirmation depth | Varies by host |
| **Backfill speed** | Hours for full history | Hours to days (re-index) |
| **Decentralization** | Managed service | Token-incentivized indexer network |

## Where Subgraphs Fall Short

<div class="use-case-cards">
<div class="uc-card">
<span class="uc-title">Performance at Scale</span>
<span class="uc-desc">A synced subgraph can keep up with the chain head in seconds, but initial syncs and re-indexes take hours to days for high-volume contracts. Under load, latency degrades as indexing falls behind. Indexing Co maintains sub-3-second latency regardless of volume because sourcing and computation are separated from storage.</span>
</div>
<div class="uc-card">
<span class="uc-title">Multi-Chain Pain</span>
<span class="uc-desc">A DeFi protocol on Ethereum, Base, Arbitrum, and Polygon needs four separate subgraphs, four databases, and four maintenance burdens. With Indexing Co, one pipeline definition covers all four chains with a unified output schema.</span>
</div>
<div class="uc-card">
<span class="uc-title">Schema Lock-In</span>
<span class="uc-desc">Need to add a field? Track a new event? Change your data model? With subgraphs, that means re-indexing from scratch, a process that can take days for high-volume contracts. Indexing Co lets you modify transforms and reprocess without starting over.</span>
</div>
<div class="uc-card">
<span class="uc-title">The AssemblyScript Tax</span>
<span class="uc-desc">AssemblyScript is a subset of TypeScript that compiles to WebAssembly. It's limited, poorly documented, and has a fraction of the ecosystem. Indexing Co uses standard TypeScript with access to the full npm ecosystem.</span>
</div>
</div>

## When The Graph Is the Right Call

- **Decentralization is a hard requirement.** If your project needs censorship-resistant data infrastructure with no single point of failure, The Graph's decentralized indexer network delivers that.
- **Simple single-chain frontends.** A straightforward dApp on one EVM chain that only needs contract event data via GraphQL.
- **Open-source ecosystem.** Large developer community, extensive documentation, and community-built subgraphs you can fork and deploy.

## When to Use What

<div class="when-cards"><div class="wc-card"><span class="wc-label">Use subgraphs if</span>
<p>You're building a simple, single-chain frontend that only needs contract event data and you're comfortable with GraphQL.</p>
</div>
<div class="wc-card wc-card--us"><span class="wc-label">Use Indexing Co if</span>
<p>You need multi-chain support, sub-500ms latency, SQL access, custom delivery targets, non-EVM chains, or data beyond contract events.</p>
</div>
</div>

## Related Reading

- [Subgraphs Suck: Crypto Data Infra is Changing](/articles/subgraphs-suck)
- [The Evolution of Blockchain Indexing](/articles/evolution-of-indexing)

## Make the Switch

Migrate from subgraphs to Indexing Co pipelines. Most teams are up and running in a day.

[Get a Demo](https://www.indexing.co/contact) | [Open the Console](https://console.indexing.co)


---
title: Indexing Co vs Moralis
url: https://www.indexing.co/compare/moralis
description: Moralis is a Web3 API platform for querying pre-built endpoints. Indexing Co is a data pipeline that delivers raw contract events to your own database.
tags: Compare
---

You're building a DeFi analytics dashboard. You reach for a Moralis endpoint, get a response in minutes, and ship the first version fast. Then a product requirement comes in: you need raw event data from a custom contract, filtered, transformed, and stored in your own Postgres table so your analytics engine can query it directly. Moralis doesn't have an endpoint for that. Now you're looking at a pipeline.

That's the gap between an API and a data pipeline.

## Architecture

Moralis is an API platform. It exposes 80+ pre-built endpoints covering NFTs, tokens, wallets, prices, DeFi positions, and on-chain streams. You call their API, you get structured data back. The schema is theirs — it's designed for broad applicability across common use cases. For teams building consumer-facing apps that need fast answers to standard questions, that's a major time saver.

Indexing Co is a data pipeline. It takes the on-chain events you care about, applies optional TypeScript transforms, and delivers the data to your PostgreSQL database, BigQuery instance, or webhook endpoint — on your schema. There's no intermediary API to query. The data is yours, in your database, in the shape you defined. You bring the storage; Indexing Co handles the extraction, transformation, and loading.

The difference is who controls the schema and where the data lives.

## Feature Comparison

| Feature | Moralis | Indexing Co |
|---|---|---|
| Data delivery | API endpoints (query their servers) | Direct to your PostgreSQL, BigQuery, or webhook |
| Schema control | Moralis-defined endpoints | You define the schema |
| Chain support | 80+ chains including EVM, Solana, Bitcoin, BNB, Base | 100+ chains including all major EVM and non-EVM |
| Custom contract events | Limited (Streams for webhooks, not raw DB delivery) | Full raw event indexing with custom transforms |
| Block-to-database delivery | API response time | sub-500ms (dedicated infra) |
| Data volume | API rate limits per tier | 1B+ events/day processed |
| Pre-built endpoints | 80+ (NFT, Token, Wallet, Price, DeFi) | Not applicable — pipeline, not API |
| Managed infrastructure | Yes | Yes |
| SDKs | Yes (multiple languages) | TypeScript transforms, console-based config |
| Pricing model | CU-based, tiered (Starter to Enterprise) | Contact for pipeline pricing |
| Real-time streaming | Streams (webhook delivery) | Webhook + direct DB delivery |
| Raw event access | Partial via Streams | Full access to raw contract events |

## When to Use Each

<div class="when-cards"><div class="wc-card"><span class="wc-label">Use Moralis if</span>
<ul>
<li>You need fast answers to standard questions: wallet balances, NFT holdings, token prices, DeFi positions</li>
<li>You're building a consumer app or dashboard that fits within the pre-built endpoint library</li>
<li>You want SDKs and a quick integration path without writing pipeline logic</li>
<li>Your data access patterns are read-heavy and query-driven, not storage-driven</li>
<li>You're prototyping and want the shortest path from chain to response</li>
</ul>
</div>
<div class="wc-card wc-card--us"><span class="wc-label">Use Indexing Co if</span>
<ul>
<li>You need data in your own database — not queried from someone else's servers</li>
<li>You're indexing custom smart contract events that don't map to a pre-built endpoint</li>
<li>You want to define your own schema, apply transforms, and own the data long-term</li>
<li>You're running analytics pipelines, data warehouses, or BI tools that need direct DB access</li>
<li>You process high event volumes and need throughput guarantees, not API rate limits</li>
</ul>
</div>
<div class="wc-note">Moralis is genuinely strong for standard Web3 queries. If your use case fits one of their 80+ endpoints, you'll ship faster with their API than building a pipeline. The limitation appears when you need custom event data, raw delivery to your own database, or a schema that matches your product — not theirs.</div>
</div>

## Get Started

If your data needs have grown past what a pre-built API can cover, the next step is a pipeline that delivers directly to your database.

[Talk to the Team](https://www.indexing.co/contact) | [Open the Console](https://console.indexing.co)


---
title: Indexing Co vs Envio
url: https://www.indexing.co/compare/envio
description: Envio is a fast EVM indexing tool for developers who want to self-host. Indexing Co is a managed pipeline that delivers to your own database across 100+ chains.
tags: Compare
---

Your team is indexing a multichain protocol — EVM on mainnet, plus a Solana program handling half the volume. You build the Envio indexer, deploy it, and then realize: HyperIndex doesn't support Solana. You need a second system, a second schema, and a second thing to keep running. Two weeks in, you're managing infrastructure instead of building product.

That's the fork in the road between a developer tool and a managed data pipeline.

## Architecture

<div class="arch-cards">
<div class="arch-card">
<div class="arch-card-bar"></div>
<div class="arch-card-header"><div class="arch-card-dot"></div><span class="arch-card-title">Envio: Developer-Controlled Indexing</span></div>
<div class="arch-card-body"><p>Envio is built for developers who want to define their own indexing logic, run it close to the chain, and query results through a GraphQL API. HyperSync pulls raw data fast, up to 2000x faster than standard RPC, and HyperIndex wraps it in an event-driven framework with hot-reloading and TypeScript support. It's an excellent self-hosted tool for EVM teams who want tight control over the indexing layer.</p></div>
</div>
<div class="arch-card arch-card--us">
<div class="arch-card-bar"></div>
<div class="arch-card-header"><div class="arch-card-dot"></div><span class="arch-card-title">Indexing Co: Managed Pipeline Delivery</span></div>
<div class="arch-card-body"><p>Indexing Co is a managed pipeline. You configure what you want indexed, define optional TypeScript transforms, and the data lands in your PostgreSQL database, BigQuery instance, or webhook endpoint. There's no indexer to deploy, no GraphQL layer to maintain, and no infrastructure to scale. The pipeline runs, and your data appears.</p><p>The difference is ownership: Envio gives you the tool; Indexing Co gives you the data.</p></div>
</div>
</div>

## Feature Comparison

| Feature | Envio | Indexing Co |
|---|---|---|
| Chain support | 70+ EVM networks only | 100+ chains including Solana, Bitcoin, and non-EVM |
| Delivery target | Self-hosted GraphQL API | Your PostgreSQL, BigQuery, or webhook |
| Managed service | Optional managed hosting | Fully managed, no infra to run |
| Block-to-database delivery | HyperSync to GraphQL API | sub-500ms (dedicated infra) |
| Custom transforms | TypeScript/JS/ReScript | TypeScript |
| Developer experience | Hot-reloading dev server, strong DX | Console-based config, no local tooling required |
| Data volume | Depends on your self-hosted infra | 1B+ events/day processed |
| Open source | Yes | No |
| Pricing | Not public (contact via Discord) | Public tiers available |
| Non-EVM chains | Not supported | Supported |
| Enterprise SLA | Not published | Available |
| Schema ownership | Yours (you define the indexer) | Yours (delivered directly to your DB) |

## When to Use Each

<div class="when-cards"><div class="wc-card"><span class="wc-label">Use Envio if</span>
<ul>
<li>Your stack is EVM-only with no plans to add non-EVM chains</li>
<li>You want to self-host and own the full indexing stack</li>
<li>You value open-source tooling and want to extend or fork the indexer</li>
<li>Your team has the infrastructure capacity to run and maintain it</li>
<li>You want a tight dev feedback loop with hot-reloading</li>
</ul>
</div>
<div class="wc-card wc-card--us"><span class="wc-label">Use Indexing Co if</span>
<ul>
<li>You index across EVM and non-EVM chains (Solana, Bitcoin, etc.)</li>
<li>You want data delivered directly to your existing database — no intermediary API</li>
<li>You don't want to run or scale indexing infrastructure</li>
<li>You need guaranteed latency SLAs and enterprise support</li>
<li>You're processing high data volumes and want a managed throughput guarantee</li>
</ul>
</div>
<div class="wc-note">Envio is a strong choice for EVM-focused teams who want a fast, open-source tool they control. If your architecture stays within that boundary, it's worth evaluating seriously. The limitation shows up when your chain footprint expands or when you'd rather own the data destination than the indexing runtime.</div>
</div>

## Get Started

If you're deciding between a self-hosted indexing tool and a managed pipeline, the fastest way to know is to see what your data looks like on the other side.

[Talk to the Team](https://www.indexing.co/contact) | [Open the Console](https://console.indexing.co)


---
title: Indexing Co vs SubQuery
url: https://www.indexing.co/compare/subquery
description: SubQuery offers an SDK for custom indexing projects across 300+ networks, including strong non-EVM and Polkadot support. Indexing Co is a managed pipeline that delivers data directly to your own database with no infrastructure to run.
tags: Compare
---

Your team needs token transfer data across six chains: three EVM, one Substrate-based, one Cosmos chain. You find SubQuery, which genuinely supports all of them. You clone the starter, wire up the manifest, write the mapping functions in TypeScript, and deploy to SubQuery's decentralized network. Now you're managing indexer operators, dealing with SQT token mechanics to pay for queries, and building a GraphQL client to consume the output. Three weeks later, the data is flowing. It's also locked behind a GraphQL API in a format your analytics team can't directly query.

That gap between broad chain coverage and getting data into your actual infrastructure, is where the two products diverge.

## Architecture

<div class="arch-cards">
<div class="arch-card">
<div class="arch-card-bar"></div>
<div class="arch-card-header"><div class="arch-card-dot"></div><span class="arch-card-title">SubQuery: Decentralized SDK and Query Network</span></div>
<div class="arch-card-body"><p>SubQuery is an SDK for building custom indexing projects. You define a manifest that specifies the chain, data sources, and handler functions. Your mapping functions transform raw events into entities, and SubQuery's runtime indexes those entities into a queryable store. The output is served as a GraphQL API.</p><p>Projects run on SubQuery's decentralized network of indexers: independent operators who run your indexing project and earn SQT tokens for doing so. Enterprise customers use managed hosting, but the broader network model assumes token-based consumer/operator economics. SubQuery also runs sharded data nodes for RPC access and is expanding into AI with AskSubQuery for natural language blockchain queries.</p><p>The 300+ network coverage is genuine and meaningful, particularly for non-EVM chains like Polkadot, Kusama, and Substrate-based networks where SubQuery has been the default tooling for years.</p></div>
</div>
<div class="arch-card arch-card--us">
<div class="arch-card-bar"></div>
<div class="arch-card-header"><div class="arch-card-dot"></div><span class="arch-card-title">Indexing Co: Managed Pipelines, Data to Your Infrastructure</span></div>
<div class="arch-card-body"><p>Indexing Co doesn't ask you to build or deploy an indexer. You define what you want indexed: chains, contracts, events, add optional TypeScript transforms to reshape the data, and choose a destination: PostgreSQL, BigQuery, or a webhook endpoint. The pipeline runs managed. Your data appears in your own database.</p><p>There's no GraphQL API sitting between you and your data. No operators to manage. No token balance to maintain. The pipeline processes over 1 billion events per day at sub-500ms block-to-storage on dedicated infrastructure.</p></div>
</div>
</div>

## Feature Comparison

| Feature | SubQuery | Indexing Co |
|---|---|---|
| **Architecture** | Indexer SDK + decentralized network | Managed pipeline service |
| **Chain support** | 300+ networks (broadest in category) | 100+ chains |
| **Non-EVM / Polkadot** | Strong (original Polkadot indexer) | Supported but narrower non-EVM coverage |
| **Data destination** | GraphQL API | Your PostgreSQL, BigQuery, or webhook |
| **Custom transforms** | TypeScript mapping functions | TypeScript transforms |
| **Infrastructure to run** | Yes, deploy and manage your indexer | None, fully managed |
| **Block-to-database delivery** | Depends on network operator | sub-500ms (dedicated infra) |
| **Payment model** | SQT token (or managed tier) | Fiat subscription |
| **Enterprise billing** | Managed tier available | Yes, standard fiat |
| **Output format** | GraphQL only | Raw data in your schema |
| **Schema ownership** | Entities defined in your project | Delivered to your own DB tables |
| **Data volume processed** | Not published | 1B+ events/day |

## When to Use Each

<div class="when-cards"><div class="wc-card"><span class="wc-label">Use SubQuery if</span>
<ul>
<li>Your stack includes Polkadot, Kusama, or other Substrate-based chains where SubQuery has the deepest support</li>
<li>You need the broadest possible multi-chain coverage and some of those chains aren't on other services</li>
<li>Your team is comfortable deploying and operating an indexer, or you're using SubQuery's managed hosting</li>
<li>GraphQL output fits your query patterns</li>
<li>You want an open, community-driven protocol rather than a SaaS service</li>
</ul>
</div>
<div class="wc-card wc-card--us"><span class="wc-label">Use Indexing Co if</span>
<ul>
<li>You want data delivered directly to your PostgreSQL database or BigQuery, no GraphQL layer</li>
<li>You need a fully managed pipeline with no indexing infrastructure to operate</li>
<li>Token mechanics or decentralized operator dependencies would create friction in your stack</li>
<li>You need predictable latency SLAs and enterprise billing without token exposure</li>
<li>Your chain footprint is within 100+ chains and you want a simpler operational model</li>
</ul>
</div>
<div class="wc-note">SubQuery's 300+ chain coverage is a real differentiator, especially for teams working with Polkadot or Substrate ecosystems. If your chains are in that long tail, SubQuery is worth evaluating seriously. The tradeoff is operational: you're building and deploying an indexer rather than configuring a pipeline, and your output is a GraphQL API rather than your own database tables.</div>
</div>

[Talk to the Team](https://www.indexing.co/contact) | [Open the Console](https://console.indexing.co)


---
title: Indexing Co vs Helius
url: https://www.indexing.co/compare/helius
description: Helius is the deepest Solana infrastructure available. Indexing Co is a multi-chain data pipeline covering 100+ chains. If you need both, you currently need two providers.
tags: Compare
---

You're building a wallet analytics product. Your users hold assets on Solana, Ethereum, Base, and Arbitrum. For the Solana side, you want enhanced transaction data, NFT metadata via DAS, and real-time streaming through gRPC. For the EVM side, you need raw contract events delivered to your PostgreSQL database with custom transforms.

Helius solves the first problem better than anyone. It doesn't touch the second.

## Architecture

<div class="arch-cards">
<div class="arch-card">
<div class="arch-card-bar"></div>
<div class="arch-card-header"><div class="arch-card-dot"></div><span class="arch-card-title">Helius: Deep Solana Infrastructure</span></div>
<div class="arch-card-body"><p>Helius is purpose-built for Solana. The product covers RPCs with staked connections for reliable transaction submission, enhanced transaction parsing (human-readable formats instead of raw instruction data), the DAS API for NFT and compressed NFT metadata, priority fee APIs, webhooks that track up to 100,000 addresses per webhook, and LaserStream, a gRPC streaming interface for low-latency real-time data. They also run Sender, a transaction submission service optimized for landing transactions in congested conditions.</p><p>The depth here is genuine. Helius handles the operational complexity of Solana infrastructure so you don't have to. They're SOC 2 certified, operate across 9 global endpoint regions, and maintain a 99.99% uptime SLA. Their customer list includes Phantom, Jupiter, Coinbase, and Bitwise, teams with serious Solana production requirements.</p><p>The boundary is equally clear: Helius is Solana only. No EVM chains, no Cosmos, no Move. If your product spans chains, Helius covers one of them.</p></div>
</div>
<div class="arch-card arch-card--us">
<div class="arch-card-bar"></div>
<div class="arch-card-header"><div class="arch-card-dot"></div><span class="arch-card-title">Indexing Co: Multi-Chain Data Pipelines</span></div>
<div class="arch-card-body"><p>Indexing Co runs data pipelines across 100+ blockchains. You configure a pipeline that sources events from one or more chains, applies TypeScript transforms you write, and delivers structured data directly to your PostgreSQL database, BigQuery dataset, or webhook endpoint. The schema is yours. The infrastructure is managed.</p><p>The model is different from Helius in a fundamental way: Helius delivers data to your application via API and gRPC. Indexing Co delivers data to your database or warehouse. One model is optimized for real-time application data access; the other is optimized for storage, analytics, and downstream processing.</p></div>
</div>
</div>

## Feature Comparison

| Feature | Helius | Indexing Co |
|---|---|---|
| Chain support | Solana only | 100+ chains (EVM, Solana, Cosmos, Move, others) |
| Data delivery model | RPC, API endpoints, gRPC streaming, webhooks | Direct to PostgreSQL, BigQuery, or webhook |
| Schema control | Helius-defined endpoints and formats | You define the schema |
| Solana-specific features | Enhanced transactions, DAS (NFTs), priority fees, LaserStream gRPC | Raw Solana event indexing with TypeScript transforms |
| Block-to-database delivery | gRPC stream to your endpoint | sub-500ms (dedicated infra) |
| Webhook support | Yes (100K addresses per webhook) | Yes |
| Transaction submission | Sender (staked connections, optimized landing) | Not applicable |
| Data volume | High-throughput RPC infrastructure | 1B+ events/day processed |
| Uptime SLA | 99.99% | Managed service |
| SOC 2 certified | Yes | Contact for compliance details |
| Pricing | Free plan, paid from ~$49/month | Contact for pipeline pricing |
| Managed infrastructure | Yes | Yes |

## When to Use Each

<div class="when-cards"><div class="wc-card"><span class="wc-label">Use Helius if</span>
<ul>
<li>You're building on Solana and need the deepest available infrastructure</li>
<li>You need enhanced transaction parsing, DAS for NFTs, or priority fee data on Solana</li>
<li>LaserStream gRPC fits your real-time application data access pattern</li>
<li>You need reliable transaction submission via staked connections</li>
<li>SOC 2 certification is a procurement requirement</li>
</ul>
</div>
<div class="wc-card wc-card--us"><span class="wc-label">Use Indexing Co if</span>
<ul>
<li>You need data pipelines across multiple chains, Ethereum, Base, Arbitrum, Solana, or others</li>
<li>You want contract events delivered to your own PostgreSQL or BigQuery on a schema you control</li>
<li>You need TypeScript transforms applied at ingest before data lands in your database</li>
<li>Your data ends up in a warehouse or analytics layer, not queried live from an API</li>
</ul>
</div>
<div class="wc-card"><span class="wc-label">Use both if</span>
<ul>
<li>You're building a multi-chain product where Solana depth matters on one side and EVM pipeline delivery matters on the other</li>
<li>Helius handles your Solana application layer; Indexing Co handles your multi-chain data warehouse</li>
</ul>
</div>
<div class="wc-note">Helius is not a replacement for a multi-chain pipeline, and Indexing Co is not a replacement for Solana-native infrastructure. If your product lives on Solana and only Solana, Helius is likely the right starting point. If you need chain coverage beyond Solana, you need a second provider regardless of how good Helius is.</div>
</div>

## Get Started

[Talk to the Team](https://www.indexing.co/contact) | [Open the Console](https://console.indexing.co)


---
title: Indexing Co vs Dune
url: https://www.indexing.co/compare/dune
description: How Indexing Co's real-time data pipelines compare to Dune's SQL-based blockchain analytics platform.
tags: Compare
---

Dune is the go-to platform for blockchain analytics. Write SQL, build dashboards, share them with the community. The interface is intuitive, the community library is massive, and broad chain support means you can query almost anything. For research and reporting, it works.

But Dune is an analytics tool, not a data delivery platform. No webhooks, no streaming, no way to pipe data into your production database in real time. If you need blockchain data powering an application, not just a dashboard, Dune wasn't built for that.

## Feature Comparison

| | Indexing Co | Dune |
|---|---|---|
| **Primary use** | Production data delivery | Analytics and dashboards |
| **Data access** | TypeScript transforms, direct DB access | SQL (DuneSQL) |
| **Block-to-database delivery** | Yes, sub-500ms (dedicated infra) | No (batch queries only) |
| **Webhooks / streaming** | Yes | No |
| **Data destination** | Your PostgreSQL, BigQuery, webhooks | Dune dashboard |
| **API access** | Direct database queries | Dune API (query results) |
| **Custom transforms** | Full TypeScript control | SQL only |
| **Multi-chain pipelines** | Single definition | Cross-chain SQL joins |
| **Visualization** | Not included (use your own tools) | Built-in charts and dashboards |
| **Community content** | N/A | Large public dashboard library |
| **Chains** | 100+ | 40+ |
| **Reorg handling** | Built-in confirmation depth | Handled by Dune |

## Where Dune Fits

- **Ad-hoc research and exploration.** Investigating a protocol, analyzing token flows, or answering one-off questions about on-chain activity. Dune's SQL interface and pre-built tables make this fast.
- **Public dashboards and reporting.** Sharing metrics with your community, investors, or team. Dune's visualization layer and public sharing model are built for this.
- **Cross-chain analytics without engineering.** Analysts who know SQL but don't write application code can query multiple chains and build dashboards without a data pipeline.

## Where Indexing Co Fits

- **Production applications.** Your app needs real-time blockchain data in its own database. Dune can't deliver data to your infrastructure. Indexing Co writes directly to your PostgreSQL, BigQuery, or webhooks.
- **Real-time event processing.** Trigger actions when on-chain events happen. Payment confirmations, liquidation alerts, token transfers. Dune queries are batch, not real-time.
- **Custom data models for your product.** Transform raw blockchain data into your application's schema with TypeScript. Dune gives you query results. Indexing Co gives you a production data layer.

## Related Reading

- [Data Pipelines for Prediction Markets](/articles/data-pipelines-for-prediction-markets)
- [The Evolution of Blockchain Indexing](/articles/evolution-of-indexing)
- [Solutions for DeFi](/solutions/defi)

## Get Started

Move from dashboards to production data. Set up your first pipeline in under 10 minutes.

[Get a Demo](https://www.indexing.co/contact) | [Open the Console](https://console.indexing.co)


---
title: Indexing Co vs Goldsky
url: https://www.indexing.co/compare/goldsky
description: How Indexing Co's custom pipeline platform compares to Goldsky's managed subgraph hosting and Mirror streaming service.
tags: Compare
---

Goldsky started as managed subgraph hosting, taking the operational pain out of running subgraphs yourself. They've since added Mirror, a data streaming product that pipes indexed data into your database. It's a step forward from raw subgraphs, but the underlying architecture carries the same limitations.

## Architecture

<div class="arch-cards">
<div class="arch-card">
<div class="arch-card-bar"></div>
<div class="arch-card-header"><div class="arch-card-dot"></div><span class="arch-card-title">Goldsky: Managed Subgraphs + Mirror Streaming</span></div>
<div class="arch-card-body"><p>Goldsky's core is hosted subgraph infrastructure with sub-second indexing latency. You deploy subgraphs to Goldsky instead of running them yourself. Mirror extends this by streaming subgraph output (or raw blockchain data) into PostgreSQL or other targets, with SQL transforms and external HTTP handlers for custom logic.</p><p>This means fast deploys, sub-second latency, and less operational overhead than self-hosted subgraphs. Mirror adds flexibility beyond raw subgraphs, but the subgraph side still carries the contract-centric model and AssemblyScript requirement.</p></div>
</div>
<div class="arch-card arch-card--us">
<div class="arch-card-bar"></div>
<div class="arch-card-header"><div class="arch-card-dot"></div><span class="arch-card-title">Indexing Co: Custom Pipelines, Full Control</span></div>
<div class="arch-card-body"><p>Indexing Co doesn't use subgraphs at all. You define pipelines that source events from any chain, transform them with TypeScript, and deliver directly to your infrastructure. The transformation layer is fully custom: you write the logic, not a subgraph mapping.</p></div>
</div>
</div>

## Feature Comparison

| | Indexing Co | Goldsky |
|---|---|---|
| **Architecture** | Custom pipelines | Managed subgraphs + Mirror |
| **Transform language** | TypeScript | AssemblyScript (subgraphs), SQL + HTTP handlers (Mirror) |
| **Data destination** | PostgreSQL, BigQuery, webhooks, GraphQL | PostgreSQL, webhooks (via Mirror) |
| **Multi-chain** | Single pipeline definition | Separate subgraph per chain |
| **Block-to-database delivery** | sub-500ms (dedicated infra) | Sub-second via Mirror; seconds via hosted GraphQL |
| **Chains** | 100+ | 150+ |
| **VM support** | EVM, Solana, Cosmos, Move | EVM + Solana, Starknet, Sui, others |
| **Custom transforms** | Full TypeScript control | Subgraph mappings or Mirror SQL/HTTP handlers |
| **Schema changes** | Hot-swap, no re-index | Re-index required |
| **Pricing model** | Pipeline-based | Subgraph + streaming based |

## Key Differences

<div class="use-case-cards">
<div class="uc-card">
<span class="uc-title">Transform Control</span>
<span class="uc-desc">Goldsky's subgraphs use AssemblyScript for transformation. Mirror adds SQL transforms and external HTTP handlers, giving you more flexibility at the streaming layer. But the two systems are separate: subgraph logic and Mirror logic don't share a unified pipeline model. With Indexing Co, transformation is a single TypeScript layer in every pipeline. One language, one model, no intermediate step.</span>
</div>
<div class="uc-card">
<span class="uc-title">Multi-Chain Approach</span>
<span class="uc-desc">Goldsky requires separate subgraphs for each chain. Mirror can stream from multiple subgraphs, but the indexing is still per-chain. Indexing Co defines multi-chain pipelines natively: one pipeline, multiple chains, unified output schema.</span>
</div>
<div class="uc-card">
<span class="uc-title">Beyond Contract Events</span>
<span class="uc-desc">Goldsky has expanded beyond EVM with support for Solana, Starknet, Sui, and others. Mirror can stream raw blockchain data beyond contract events. But the primary workflow is still subgraph-driven, and cross-chain analytics require stitching together separate subgraphs. Indexing Co indexes contracts, wallets, blocks, and transactions from the same pipeline with a unified multi-chain definition.</span>
</div>
</div>

## When to Use What

<div class="when-cards"><div class="wc-card"><span class="wc-label">Use Goldsky if</span>
<p>You have existing subgraphs and want managed hosting with sub-second latency, or Mirror's SQL transforms and streaming model fit your workflow.</p>
</div>
<div class="wc-card wc-card--us"><span class="wc-label">Use Indexing Co if</span>
<p>You want a unified pipeline model with TypeScript transforms, single-definition multi-chain pipelines, or need to combine contract events with wallet/block/transaction data in one pipeline.</p>
</div>
</div>

## Get Started

[Get a Demo](https://www.indexing.co/contact) | [Open the Console](https://console.indexing.co)


---
title: Indexing Co vs Alchemy
url: https://www.indexing.co/compare/alchemy
description: Alchemy is the leading Web3 developer platform for RPC, enhanced APIs, and webhooks. Indexing Co is a data pipeline that delivers indexed contract events to your own database in your schema.
tags: Compare
---

Your protocol has a custom staking contract. You need every `Staked`, `Unstaked`, and `RewardClaimed` event stored in your PostgreSQL database, decoded, enriched with a USD value at time of event, and queryable by your analytics team in real time. You open Alchemy's docs. The NFT API, Token API, Wallet API — none of them cover your contract. You look at Subgraphs. You write AssemblyScript mappings, deploy, wait for sync, and end up with a GraphQL endpoint that your analytics team can't connect to their BI tool directly. Now you're thinking about a pipeline.

That's where an RPC platform ends and a data pipeline begins.

## Architecture

<div class="arch-cards">
<div class="arch-card">
<div class="arch-card-bar"></div>
<div class="arch-card-header"><div class="arch-card-dot"></div><span class="arch-card-title">The RPC Layer: What Alchemy Does</span></div>
<div class="arch-card-body"><p>Alchemy sits at the RPC layer. It provides the connection to blockchain nodes: you send requests, the node responds. On top of raw RPC, Alchemy adds enhanced APIs (NFT API, Token API, Wallet API), webhooks for activity notifications, and Smart Websockets for subscriptions. Their Subgraphs product (via Graph Protocol) handles contract event indexing.</p><p>This is the right layer for most Web3 development work. You need to read a wallet balance, check an NFT's metadata, simulate a transaction, or subscribe to transfer events in real time. Alchemy is fast, reliable, and has the broadest set of enhanced APIs in the ecosystem.</p><p>The constraint is the same for every API layer: you work within their data model. When you need data shaped for your product, in your schema, in your database, transformed to match your domain, you're working against the grain of an API.</p></div>
</div>
<div class="arch-card arch-card--us">
<div class="arch-card-bar"></div>
<div class="arch-card-header"><div class="arch-card-dot"></div><span class="arch-card-title">The Pipeline Layer: What Indexing Co Does</span></div>
<div class="arch-card-body"><p>Indexing Co sits above the RPC layer. It reads from blockchain nodes (including Alchemy's), decodes contract events, runs your TypeScript transforms, and writes directly to your PostgreSQL database, BigQuery dataset, or webhook endpoint. Your schema, your destination, your logic.</p><p>There's no API to query. The data is in your database. Your analytics team, your BI tools, your ML models all connect to infrastructure you already own.</p><p>The two products answer different questions. Alchemy answers "give me this data now." Indexing Co answers "keep that data in my database, always up to date, shaped the way I need it."</p></div>
</div>
</div>

## Feature Comparison

| Feature | Alchemy | Indexing Co |
|---|---|---|
| **Primary function** | RPC endpoints + enhanced APIs | Custom blockchain data pipelines |
| **Data delivery** | API endpoints, webhooks, websockets | Direct to your PostgreSQL, BigQuery, or webhook |
| **Schema control** | Alchemy-defined (NFT/Token/Wallet API shapes) | You define the schema |
| **Custom contract events** | Via Subgraphs (AssemblyScript, GraphQL output) | Full raw event indexing with TypeScript transforms |
| **Chain support** | 50+ (Ethereum, Solana, BNB, Polygon, Arbitrum, Base, Starknet, others) | 100+ chains, all major EVM and non-EVM |
| **Block-to-database delivery** | API response time | sub-500ms (dedicated infra) |
| **Data volume** | CU-based rate limits per tier | 1B+ events/day processed |
| **Transform language** | Not applicable (API layer) | TypeScript |
| **Pre-built APIs** | NFT, Token, Wallet, Gas, Account Abstraction | Not applicable, pipeline, not API |
| **Managed infrastructure** | Yes | Yes |
| **Pricing model** | Free: 30M CUs/month. PAYG: ~$0.45/M CU. Enterprise: custom | Contact for pipeline pricing |
| **Customers** | OpenSea, Aave, Meta, Adobe, Maker | Data-heavy protocols, analytics teams, fintech |

## When to Use Each

<div class="when-cards"><div class="wc-card"><span class="wc-label">Use Alchemy if</span>
<ul>
<li>You need RPC access to Ethereum, Solana, or other major chains</li>
<li>You're using their NFT API, Token API, or Wallet API for standard queries, these are genuinely well-built products</li>
<li>You need webhooks for wallet activity or transfer events, delivered to your app in real time</li>
<li>You're building with Account Abstraction and want their Gas Manager and AA SDK</li>
<li>You want the broadest developer platform in the Web3 ecosystem with strong reliability guarantees</li>
</ul>
</div>
<div class="wc-card wc-card--us"><span class="wc-label">Use Indexing Co if</span>
<ul>
<li>You need custom smart contract events stored in your own database</li>
<li>Your schema has to match your product domain, not a pre-built API shape</li>
<li>You're feeding blockchain data into a data warehouse, BI tool, or ML pipeline that needs direct DB access</li>
<li>You want TypeScript transforms that run before the data reaches storage, decoding, enriching, filtering at the pipeline layer</li>
<li>You're processing high event volumes across many chains and need delivery guarantees, not CU-based rate limits</li>
</ul>
</div>
</div>

## They're Not Mutually Exclusive

Many teams use both. Alchemy handles RPC calls and enhanced API queries within the application. Indexing Co runs alongside as the pipeline that keeps their database current. Alchemy is upstream, it's one of the node providers Indexing Co uses to source raw chain data. The two products occupy different parts of the stack and solve different problems.

If your product works within Alchemy's pre-built API surface, you probably don't need a separate pipeline. If you've hit the edge of what their endpoints cover, a pipeline is the natural next step, not a replacement for Alchemy.

[Talk to the Team](https://www.indexing.co/contact) | [Open the Console](https://console.indexing.co)


---
title: Indexing Co vs QuickNode
url: https://www.indexing.co/compare/quicknode
description: QuickNode provides RPC infrastructure and Streams for real-time event data. Indexing Co delivers indexed contract events directly to your database in your own schema.
tags: Compare
---

You're tracking liquidity events across three DEXs on Arbitrum and Base. You set up QuickNode Streams to pipe `Swap`, `Mint`, and `Burn` events to your endpoint in real time. The events arrive. They're raw, ABI-encoded, in QuickNode's delivery format. Now you write decoding logic, transformation code, and storage logic on your end. You keep that code maintained as contracts update. A fourth DEX goes live on a new chain. You extend the pipeline again.

What you've built is a data pipeline. QuickNode gave you the stream, you built everything downstream of it.

## Architecture

<div class="arch-cards">
<div class="arch-card">
<div class="arch-card-bar"></div>
<div class="arch-card-header"><div class="arch-card-dot"></div><span class="arch-card-title">The RPC Layer: What QuickNode Does</span></div>
<div class="arch-card-body"><p>QuickNode is RPC infrastructure. It provides fast, globally distributed node access across 130+ networks with 99.99% uptime. On top of raw RPC, QuickNode offers WebSockets, gRPC, and Streams, their real-time data streaming product that fires on-chain events to a destination of your choice.</p><p>Streams is the closest QuickNode product to what Indexing Co does. It can deliver raw transaction data, log data, or filtered events as they happen. It's a meaningful step beyond polling RPC endpoints. The data arrives fast, and the network coverage is the broadest of any RPC provider.</p><p>The gap is what happens to that data after delivery. QuickNode Streams delivers events in their format, to your endpoint. The decoding, transformation, schema mapping, and storage are yours to build and maintain.</p></div>
</div>
<div class="arch-card arch-card--us">
<div class="arch-card-bar"></div>
<div class="arch-card-header"><div class="arch-card-dot"></div><span class="arch-card-title">The Pipeline Layer: What Indexing Co Does</span></div>
<div class="arch-card-body"><p>Indexing Co is what lives above the RPC layer. It sources raw block data from nodes (including QuickNode), decodes contract events, applies TypeScript transforms you define, and writes directly to your PostgreSQL database or BigQuery dataset in the schema you specify. The extraction, transformation, and loading are managed. You define what data you want and what shape it should arrive in.</p><p>The difference is where the work stops. QuickNode Streams gets the data moving. Indexing Co gets the data into your database, decoded and shaped, without you building or maintaining the transformation layer.</p></div>
</div>
</div>

## Feature Comparison

| Feature | QuickNode | Indexing Co |
|---|---|---|
| **Primary function** | RPC infrastructure + real-time streaming | Custom blockchain data pipelines |
| **Data delivery** | To your app endpoint (Streams), RPC responses | Direct to your PostgreSQL, BigQuery, or webhook |
| **Schema control** | QuickNode delivery format | You define the schema |
| **Custom contract events** | Streams delivers raw events, decoding and storage are yours | Full indexing with TypeScript transforms, direct DB write |
| **Chain support** | 130+ networks (broadest RPC coverage) | 100+ chains, all major EVM and non-EVM |
| **Block-to-database delivery** | Raw events to your endpoint | sub-500ms (dedicated infra) |
| **Data volume** | 5T+ requests processed in 2025 | 1B+ events/day processed |
| **Transform language** | Not applicable, you build transformation | TypeScript |
| **Managed infrastructure** | Yes (SOC 1/2 Type II, ISO 27001 certified) | Yes |
| **Pricing model** | Tiered plans + new Flat Rate RPS (EVM + Solana) | Contact for pipeline pricing |
| **Compliance** | SOC 1/2 Type II, ISO 27001 | Contact for compliance documentation |
| **Marketplace add-ons** | 80+ partner integrations | Not applicable |

## When to Use Each

<div class="when-cards"><div class="wc-card"><span class="wc-label">Use QuickNode if</span>
<ul>
<li>You need RPC access across the widest possible chain footprint, 130+ networks including newer chains like Hyperliquid, Robinhood Chain, and Tempo</li>
<li>You need Streams to receive real-time event data and you're building your own downstream processing</li>
<li>Your team is comfortable writing and maintaining decoding and transformation logic</li>
<li>You want SOC/ISO certified infrastructure for compliance requirements</li>
<li>You need gRPC access or Flat Rate RPS pricing for high-throughput RPC usage</li>
<li>You want Marketplace add-ons to extend your node with partner services</li>
</ul>
</div>
<div class="wc-card wc-card--us"><span class="wc-label">Use Indexing Co if</span>
<ul>
<li>You need contract events stored in your own database, decoded and shaped to your schema</li>
<li>You want to define TypeScript transforms that run before the data reaches storage, not after delivery</li>
<li>You're feeding blockchain data into a data warehouse, BI tool, or ML pipeline that needs direct database access</li>
<li>You want the transformation and loading layer managed, not just the streaming layer</li>
<li>You're indexing across 100+ chains with a single pipeline definition and unified output schema</li>
</ul>
</div>
</div>

## They're Not Mutually Exclusive

QuickNode and Indexing Co occupy different parts of the same stack. QuickNode is upstream node infrastructure, it's one of the RPC providers Indexing Co can source raw chain data from. Teams that need maximum chain coverage for RPC calls, or that use QuickNode Streams for certain real-time use cases, often run Indexing Co alongside for the database delivery layer.

If QuickNode Streams plus your own transformation code is working and the maintenance overhead is acceptable, that's a reasonable setup. When the transformation layer gets complex, multiple chains, multiple contracts, schema changes, enrichment logic, a managed pipeline is the point where the build-it-yourself cost starts to exceed a dedicated service.

[Talk to the Team](https://www.indexing.co/contact) | [Open the Console](https://console.indexing.co)


---
title: Indexing Co vs Covalent (GoldRush)
url: https://www.indexing.co/compare/covalent
description: How Indexing Co's custom pipeline platform compares to Covalent's unified multi-chain REST API.
tags: Compare
---

You hit the Covalent API, get token balances across ten chains in one call, and ship the feature in an afternoon. Three months later, you need to filter by a field their endpoint doesn't expose, reshape the response to match your data model, and stream updates to your database in real time. You're now writing a workaround around someone else's schema.

## Architecture

<div class="arch-cards">
<div class="arch-card">
<div class="arch-card-bar"></div>
<div class="arch-card-header"><div class="arch-card-dot"></div><span class="arch-card-title">Covalent (GoldRush): Unified Multi-Chain API</span></div>
<div class="arch-card-body"><p>Covalent's core proposition is simplicity across chains: one API key, one SDK, and a single path parameter to switch between 100+ blockchains. Their pre-built endpoints cover token balances, transactions, NFTs, DEX activity, and more. A TypeScript and Python SDK wraps the REST layer, and a WebSocket streaming API (beta) adds real-time capabilities. They also run an MCP server for AI agent integrations.</p><p>The model works well when Covalent's endpoint coverage matches what you need. Data is pre-structured, chain-switching is trivial, and onboarding takes minutes. The constraint is that you're working within their schema: the shape of the data is defined by Covalent, not by you.</p></div>
</div>
<div class="arch-card arch-card--us">
<div class="arch-card-bar"></div>
<div class="arch-card-header"><div class="arch-card-dot"></div><span class="arch-card-title">Indexing Co: Custom Pipelines, Your Schema</span></div>
<div class="arch-card-body"><p>Indexing Co starts from the other direction. You define what data you want, write TypeScript transforms that shape it, and the pipeline delivers it to your infrastructure. PostgreSQL, BigQuery, or webhook endpoint, your choice. The sub-500ms block-to-storage on dedicated infrastructure means events arrive quickly, and the schema is entirely yours from the first transform.</p><p>There's no pre-built query interface. Indexing Co is the delivery layer: it feeds your database or triggers your services. What you do with the data after that is up to you.</p></div>
</div>
</div>

## Feature Comparison

| Feature | Covalent (GoldRush) | Indexing Co |
|---|---|---|
| **Architecture** | Unified REST API | Custom pipeline to your infrastructure |
| **Schema** | Covalent-defined endpoints | Fully custom TypeScript transforms |
| **Data destination** | API response (your app calls it) | PostgreSQL, BigQuery, webhooks |
| **Block-to-database delivery** | API response only | sub-500ms (dedicated infra) |
| **Chains** | 100+ | 100+ |
| **Onboarding speed** | Minutes (one API key) | Pipeline configuration required |
| **Multi-chain** | Single path parameter | Native multi-chain pipeline definition |
| **Custom data shapes** | Not available, you get Covalent's model | Full control via TypeScript |
| **Webhook delivery** | Not available | Yes, for event-driven architectures |
| **Token component** | CXT token (enterprise friction) | No token dependency |
| **Pricing model** | API call-based | Pipeline-based |
| **Best for** | Quick access to structured chain data | Production pipelines with custom schemas |

## When to Use Each

<div class="when-cards"><div class="wc-card"><span class="wc-label">Use Covalent if</span>
<p>You need fast access to standard blockchain data across many chains and don't need to customize the schema. Token balances, wallet history, NFT metadata, and DEX activity are available out of the box. If your product can work with Covalent's data model and you want to avoid building indexing infrastructure, it's a quick path to chain data.</p>
</div>
<div class="wc-card wc-card--us"><span class="wc-label">Use Indexing Co if</span>
<p>Your app needs data shaped to your own model, delivered directly to your database or services. Custom transforms, webhook triggers, and direct DB delivery mean the pipeline fits your architecture, not the other way around. If you've hit the ceiling of what pre-built API endpoints can express, Indexing Co is the step up.</p>
</div>
<div class="wc-note">The products can complement each other early on: use Covalent to prototype and validate, switch to Indexing Co when you need control over schema and delivery.</div>
</div>

## Get Started

[Talk to the Team](https://www.indexing.co/contact) | [Open the Console](https://console.indexing.co)


---
title: Indexing Co vs SQD (Subsquid)
url: https://www.indexing.co/compare/sqd
description: SQD is a decentralized data lake with ZK-proof verification and impressive enterprise logos. Indexing Co is a real-time managed pipeline that delivers data directly to your own database as blocks arrive.
tags: Compare
---

Your protocol needs to trigger a risk engine within three seconds of an on-chain event. You evaluate SQD: it has enterprise clients including Deutsche Telekom, strong ZK-proof data guarantees, and 200+ chains. You dig into the architecture and find that the Portal is built around a batch data lake model. Data is ingested, archived, and made available for queries. Freshness is measured in batches, not in seconds. For historical analytics that's fine. For a real-time alert system, it's the wrong shape.

That's the core distinction: a data archive built for query throughput versus a pipeline built for low-latency delivery.

## Architecture

<div class="arch-cards">
<div class="arch-card">
<div class="arch-card-bar"></div>
<div class="arch-card-header"><div class="arch-card-dot"></div><span class="arch-card-title">SQD: Decentralized Data Lake and Query Gateway</span></div>
<div class="arch-card-body"><p>SQD's infrastructure is built around a decentralized data lake: 2,500+ nodes holding 2.1 petabytes of indexed blockchain data across 200+ networks. The Portal is SQD's high-performance query gateway that sits in front of this lake, serving around 5 million queries per day. Data integrity is secured with ZK proofs, which gives enterprises a verifiable guarantee that the data hasn't been tampered with.</p><p>The batch processing model is the right choice for SQD's use case: deep historical queries, full dataset scans, analytics workloads where you're asking questions across millions of blocks. Enterprise clients like Deutsche Telekom and Morpho are using it in that context. SQD was acquired by Rezolve AI (NASDAQ: RZLV) in October 2025 and is now part of a publicly traded company focused on AI and commerce infrastructure, a shift worth factoring into a long-term vendor assessment.</p><p>Enterprise billing is available through Portal Revenue Pools via fiat and stablecoins, launched in January 2026.</p></div>
</div>
<div class="arch-card arch-card--us">
<div class="arch-card-bar"></div>
<div class="arch-card-header"><div class="arch-card-dot"></div><span class="arch-card-title">Indexing Co: Real-Time Managed Pipelines</span></div>
<div class="arch-card-body"><p>Indexing Co runs as a managed pipeline service. You define your data sources: chains, contracts, events, blocks, wallet addresses, add TypeScript transforms to shape the output, and choose where it lands: PostgreSQL, BigQuery, or a webhook. The pipeline runs continuously. New blocks arrive, get processed, and appear in your database at sub-500ms block-to-storage on dedicated infrastructure.</p><p>There's no data lake to query. There's no Portal to configure. The data is yours, in your schema, in your infrastructure, as it happens.</p></div>
</div>
</div>

## Feature Comparison

| Feature | SQD | Indexing Co |
|---|---|---|
| **Architecture** | Decentralized data lake + query gateway | Managed real-time pipeline |
| **Processing model** | Batch (archive and query) | Continuous delivery to your database |
| **Block-to-database delivery** | Batch intervals via Portal | sub-500ms (dedicated infra) |
| **Chain support** | 200+ networks | 100+ chains |
| **Data destination** | Query via Portal | Your PostgreSQL, BigQuery, or webhook |
| **Data verification** | ZK-proof secured | Managed service guarantee + SLA |
| **Infrastructure to run** | Portal setup required | None, fully managed |
| **Enterprise billing** | Fiat/stablecoins via Revenue Pools | Standard fiat subscription |
| **Enterprise clients** | Deutsche Telekom, Morpho, PancakeSwap | Available, contact for case studies |
| **Data volume** | 2.1 PB indexed, ~5M queries/day | 1B+ events/day processed |
| **Custom transforms** | Squid processor (TypeScript) | TypeScript transforms |
| **Company status** | Acquired by Rezolve AI (NASDAQ: RZLV) | Independent |

## When to Use Each

<div class="when-cards"><div class="wc-card"><span class="wc-label">Use SQD if</span>
<ul>
<li>You need deep historical data access across a broad set of chains</li>
<li>Your workload is analytics-heavy: large scans, retrospective queries, full dataset analysis</li>
<li>ZK-proof data verification is a requirement for your compliance or trust model</li>
<li>You're comfortable with a Portal-based query model rather than direct database delivery</li>
<li>You're already in the Subsquid ecosystem and the Rezolve AI direction aligns with your roadmap</li>
</ul>
</div>
<div class="wc-card wc-card--us"><span class="wc-label">Use Indexing Co if</span>
<ul>
<li>You need data delivered within seconds of a block being finalized</li>
<li>Your system reacts to on-chain events, risk engines, alerts, real-time dashboards, automated workflows</li>
<li>You want data in your own PostgreSQL or BigQuery with no query gateway in the middle</li>
<li>You don't want to manage Portal infrastructure</li>
<li>You need a straightforward fiat subscription with guaranteed latency SLAs</li>
</ul>
</div>
<div class="wc-note">SQD's data lake is purpose-built for historical depth and query throughput, and the ZK-proof model gives it a credibility story that's hard to match. The tradeoff is that batch architecture isn't the right fit for latency-sensitive use cases. If your system needs to know what happened on-chain in the last two seconds, you're working against the grain of SQD's design. If you need to query what happened across the last two years, it's worth a serious look.</div>
</div>

[Talk to the Team](https://www.indexing.co/contact) | [Open the Console](https://console.indexing.co)


---
title: Indexing Co vs Self-Hosting
url: https://www.indexing.co/compare/self-hosting
description: The trade-offs between running your own blockchain indexing nodes and infrastructure versus using Indexing Co's managed pipelines.
tags: Compare
---

Self-hosting your indexing infrastructure means full control. You run the nodes, own the data pipeline, choose every tool in the stack. No vendor can change pricing, deprecate an API, or throttle your queries. For some teams, that control is non-negotiable.

The cost is time. A production-grade self-hosted indexer takes 3-6 months to build. Then it takes 0.5-1 FTE to maintain. Every new chain multiplies the effort. Every chain upgrade risks breaking your setup. Control is real, but so is the operational burden.

## What Self-Hosting Requires

Running your own indexing infrastructure means operating:

1. **Full or archive nodes** for each chain you index. Storage alone runs terabytes per chain.
2. **Block ingestion** that handles polling, websocket connections, missed blocks, and RPC failover.
3. **Reorg detection and rollback**: the hardest problem in blockchain indexing. Miss a reorg and your data is silently wrong.
4. **Event decoding** across different ABIs, proxy contracts, and chain-specific quirks.
5. **Transformation logic** that turns raw events into your data model.
6. **Database operations**: schema migrations, write throughput optimization, query performance tuning at scale.
7. **Monitoring and alerting** for every layer: node health, ingestion lag, data gaps, pipeline failures.

Multiply all of this by the number of chains you support.

## Feature Comparison

| | Indexing Co | Self-Hosting |
|---|---|---|
| **Time to production** | Hours to days | 3-6 months |
| **Ongoing maintenance** | Managed | 0.5-1 FTE |
| **Node operations** | Not required | You run them |
| **Multi-chain** | 100+ chains, single config | Each chain is a separate project |
| **Reorg handling** | Built-in confirmation depth | You build and maintain it |
| **Backfill** | Managed, parallelized | You build it |
| **Schema changes** | Hot-swap transforms | Re-index from scratch |
| **Monitoring** | Built-in dashboard | You build it |
| **Transform flexibility** | TypeScript | Whatever you choose |
| **Data ownership** | Data in your database | Data in your database |
| **Vendor dependency** | Yes (Indexing Co) | None |
| **Cost structure** | Pipeline subscription | Node hosting + storage + engineering salary |

## Where Self-Hosting Fits

- **Regulatory or compliance requirements.** Some organizations need infrastructure they fully control, in specific regions, with no third-party data processors in the chain.
- **Blockchain data is your core product.** If you're building a data platform yourself, like an analytics provider, an indexing service, a chain explorer, owning the infrastructure is part of the value proposition.
- **Single-chain, low-complexity use cases.** One chain, one contract, stable schema. The maintenance burden stays manageable.

## Where Indexing Co Fits

- **Multi-chain products.** Adding a chain to Indexing Co is a config change. Self-hosting means new nodes, new ingestion logic, new edge cases. Every chain triples the operational surface.
- **Teams without dedicated data infrastructure engineers.** Self-hosting needs someone who understands node operations, database performance, and reorg handling. Indexing Co abstracts all of that.
- **Fast iteration.** Change your schema, add new event sources, modify transforms. Indexing Co hot-swaps without re-indexing. Self-hosted infrastructure means re-processing from the start, which can take days for high-volume contracts.

## Self-Hosting vs Building In-House

This page focuses on running your own nodes and indexing infrastructure. For the broader question of building custom indexing code (with or without your own nodes), see [Indexing Co vs Building In-House](/compare/build-your-own).

## Related Reading

- [The Evolution of Blockchain Indexing](/articles/evolution-of-indexing)
- [Building the Data Economy Layer for Your Chain](/articles/building-the-data-economy-layer-for-your-chain)
- [Solutions for Infrastructure](/solutions/infra-stack)

## Get Started

Skip the months of infrastructure work. Deploy your first pipeline in under 10 minutes.

[Get a Demo](https://www.indexing.co/contact) | [Open the Console](https://console.indexing.co)


---
title: Indexing Co vs Bitquery
url: https://www.indexing.co/compare/bitquery
description: Bitquery offers GraphQL APIs and cloud streaming for blockchain data. Indexing Co delivers raw contract events directly to your own PostgreSQL or BigQuery with custom TypeScript transforms.
tags: Compare
---

You're building a cross-chain DEX analytics tool. Bitquery's GraphQL API covers the queries you need out of the box: trade data, OHLCV prices, mempool events. You ship v1 fast. Then your data team asks to run cohort analysis directly in BigQuery against a custom schema that joins on-chain events with your internal user table. Bitquery has a cloud delivery option, but the schema is theirs. You can't reshape it, and you can't join across tables that don't exist in your warehouse yet.

That's the moment the distinction between a query API and a data pipeline matters.

## Architecture

<div class="arch-cards">
<div class="arch-card">
<div class="arch-card-bar"></div>
<div class="arch-card-header"><div class="arch-card-dot"></div><span class="arch-card-title">Bitquery: GraphQL APIs with Cloud Streaming</span></div>
<div class="arch-card-body"><p>Bitquery exposes a GraphQL API across 40+ blockchains, with real-time WebSocket subscriptions (V2 API) for live data. Beyond the query layer, they offer cloud streaming integrations that push data to AWS, Snowflake, Google Cloud, Azure, and Kafka. The data model is Bitquery's: you query the shape they've defined, and their cloud delivery exports that same shape to your warehouse.</p><p>This is a strong fit if your queries map cleanly to their schema: DEX trades, token transfers, mempool data, price feeds. The WebSocket subscriptions give you real-time access without polling. Cloud delivery integrations reduce the work of getting data into Snowflake or BigQuery without building a pipeline yourself.</p><p>The constraint is schema ownership. You're querying their model of the blockchain. If you need a custom event schema, enriched fields, or a shape that maps to your internal data model, you're doing that transformation after the data lands, in your warehouse, with your own tooling.</p></div>
</div>
<div class="arch-card arch-card--us">
<div class="arch-card-bar"></div>
<div class="arch-card-header"><div class="arch-card-dot"></div><span class="arch-card-title">Indexing Co: Custom Pipelines, Your Schema</span></div>
<div class="arch-card-body"><p>Indexing Co doesn't expose a query API. It runs a pipeline: extract events from the chain, apply TypeScript transforms you write, and deliver structured rows directly to your PostgreSQL database, BigQuery dataset, or webhook endpoint. The schema is defined by you at pipeline configuration time. The data arrives in your database already shaped the way your application or analytics layer expects it.</p><p>There's no intermediate query step. You don't call Indexing Co servers to read your data: the data is in your database, indexed to your specification, ready for your queries.</p></div>
</div>
</div>

## Feature Comparison

| Feature | Bitquery | Indexing Co |
|---|---|---|
| Data delivery model | GraphQL API + WebSocket subscriptions | Direct to PostgreSQL, BigQuery, or webhook |
| Schema control | Bitquery-defined schema | You define the schema |
| Chain support | 40+ blockchains | 100+ chains |
| Custom contract events | Via GraphQL queries | Full raw event indexing with TypeScript transforms |
| Block-to-database delivery | WebSocket API (their servers) | sub-500ms (dedicated infra) |
| Cloud integrations | AWS, Snowflake, Google Cloud, Azure, Kafka | PostgreSQL, BigQuery, webhooks |
| DEX and price data | Strong, OHLCV, DEX trades, mempool data | Raw event delivery, no built-in price APIs |
| Transform language | Not applicable (you transform post-delivery) | TypeScript (run before data lands) |
| Data volume | Credit-based per plan | 1B+ events/day processed |
| Pricing model | Monthly credit allocations by plan tier | Contact for pipeline pricing |
| Managed infrastructure | Yes | Yes |
| Historical data | Yes | Yes |

## When to Use Each

<div class="when-cards"><div class="wc-card"><span class="wc-label">Use Bitquery if</span>
<ul>
<li>You need a GraphQL API for on-demand queries across 40+ chains</li>
<li>Real-time WebSocket subscriptions fit your application's data access pattern</li>
<li>You want pre-built DEX trade data, OHLCV price feeds, or mempool data without writing indexing logic</li>
<li>You're delivering to Snowflake, Kafka, or AWS and their schema fits your use case</li>
<li>You're prototyping and want the shortest path from chain to result</li>
</ul>
</div>
<div class="wc-card wc-card--us"><span class="wc-label">Use Indexing Co if</span>
<ul>
<li>You need data in your own database on a schema you control</li>
<li>You're indexing custom smart contract events that don't exist in Bitquery's model</li>
<li>You need to apply TypeScript transforms before the data lands, enriching, filtering, reshaping at ingest</li>
<li>You need 100+ chain coverage beyond Bitquery's 40</li>
<li>Your analytics team runs queries directly against a database or data warehouse and needs schema consistency with internal tables</li>
</ul>
</div>
<div class="wc-note">Bitquery is a legitimate choice for DEX-heavy use cases and teams that want a query API rather than a pipeline. Their cloud streaming integrations are real and reduce integration work for Snowflake or Kafka setups. The tradeoff is that the schema belongs to them, and your coverage is capped at 40 chains.</div>
</div>

## Get Started

[Talk to the Team](https://www.indexing.co/contact) | [Open the Console](https://console.indexing.co)


---
title: Indexing Co vs Allium
url: https://www.indexing.co/compare/allium
description: How Indexing Co's real-time pipeline platform compares to Allium's enterprise blockchain data warehouse.
tags: Compare
---

Your analyst queries last night's DeFi volume on Allium's dashboard in seconds. Your backend engineer is still waiting on the same data, it arrived in the warehouse twelve hours after the block settled, and the schema doesn't match what your app expects. Allium solves the first problem well. It wasn't built for the second.

## Architecture

<div class="arch-cards">
<div class="arch-card">
<div class="arch-card-bar"></div>
<div class="arch-card-header"><div class="arch-card-dot"></div><span class="arch-card-title">Allium: Enterprise Data Warehouse</span></div>
<div class="arch-card-body"><p>Allium ingests blockchain data across 100+ chains and 1,000+ protocols, normalizes it, and delivers it into the data warehouses analysts already live in: Snowflake, BigQuery, Databricks, via direct data shares and streams. SOC I and SOC II certified, with a query interface, dashboards, and an AI layer for natural language queries. The product is built for enterprise analytics teams: Visa, Coinbase, Stripe, and Grayscale use it to understand what's happening on-chain.</p><p>What Allium optimizes for is trust, depth, and analyst accessibility. The data model is Allium's, curated, normalized, and consistent across chains. That's its strength for analytics. It's also the constraint for production apps.</p></div>
</div>
<div class="arch-card arch-card--us">
<div class="arch-card-bar"></div>
<div class="arch-card-header"><div class="arch-card-dot"></div><span class="arch-card-title">Indexing Co: Real-Time Pipeline Delivery</span></div>
<div class="arch-card-body"><p>Indexing Co is not a warehouse. It's a pipeline: events leave the chain, pass through your TypeScript transform, and land in your PostgreSQL, BigQuery, or webhook endpoint, with sub-500ms block-to-storage on dedicated infrastructure. The schema is yours. You define what the data looks like before it reaches your infrastructure.</p><p>No dashboards, no query interface. Indexing Co is the layer that feeds your app, your database, or your downstream services. If you need to query that data afterward, you connect your own BI tool to your own database.</p></div>
</div>
</div>

## Feature Comparison

| Feature | Allium | Indexing Co |
|---|---|---|
| **Primary use case** | Enterprise analytics and reporting | Production data pipelines for apps and services |
| **Data destination** | Snowflake, BigQuery, Databricks, dashboards | PostgreSQL, BigQuery, webhooks |
| **Schema control** | Allium-defined, normalized | Fully custom TypeScript transforms |
| **Block-to-database delivery** | Warehouse batch delivery | sub-500ms (dedicated infra) |
| **Webhook delivery** | Not available | Yes, for event-driven architectures |
| **Chains** | 100+ | 100+ |
| **Protocol coverage** | 1,000+ protocols, 90M+ tokens | Contract- and wallet-level indexing |
| **Analyst interface** | Dashboards, query UI, Allium AI (NL queries) | None, pipeline delivery only |
| **Compliance** | SOC I and SOC II certified | Managed service, no cert disclosed |
| **Pricing model** | Enterprise contracts | Pipeline-based |
| **AI/MCP integration** | Allium AI, MCP server | Not available |
| **Target buyer** | Enterprise analytics teams | Engineering teams building data-driven products |

## When to Use Each

<div class="when-cards"><div class="wc-card"><span class="wc-label">Use Allium if</span>
<p>Your primary need is analytics, historical analysis, cross-protocol reporting, or sharing data across an enterprise analytics stack. Allium's normalized models, deep protocol coverage, and warehouse-native delivery are hard to match for that use case. If your team works in Snowflake or Databricks and needs a trusted, curated data layer, Allium is the right fit.</p>
</div>
<div class="wc-card wc-card--us"><span class="wc-label">Use Indexing Co if</span>
<p>You're an engineering team building something that depends on fresh blockchain data. If your app reacts to on-chain events, your backend needs a live feed, or you need data in your own database under your own schema, Indexing Co is the pipeline layer. Sub-500ms latency on dedicated infrastructure and custom transforms mean data arrives shaped the way your code expects it, not normalized for analyst consumption.</p>
</div>
<div class="wc-note">The two products can coexist. Some teams use Allium for reporting and Indexing Co for their production data path.</div>
</div>

## Get Started

[Talk to the Team](https://www.indexing.co/contact) | [Open the Console](https://console.indexing.co)


---
title: The Neighborhood
url: https://www.indexing.co/the-neighborhood
description: A distributed data processing protocol that moves compute to the data. Federated storage, distributed execution, and tokenized incentives for blockchain data infrastructure.
image: /assets/articles/the-neighborhood.png
---

Blockchain data is fragmented across hundreds of networks. Processing it today means pulling everything to one central location, transforming it, and pushing it back out. That model breaks at scale.

The Neighborhood takes a different approach. Instead of moving data to your pipeline, it moves your pipeline to the data.

## How it works

The protocol coordinates three layers:

### Federated Storage
Data stays where it originates. The network reads from distributed sources without centralizing or duplicating. Your pipelines connect to the chain directly, not to a copy of it sitting in someone else's data center.

### Distributed Compute
Processing happens across a global mesh of nodes. When you deploy a pipeline, the network routes execution to nodes closest to the data source. Lower latency. Lower cost. No single point of failure.

### Incentivization Layer
Node operators contribute compute and storage. Data consumers pay for what they use. Supply meets demand through a tokenized system that keeps the network economically sustainable without subsidies.

## What you can build

- **Real-time indexing** across 100+ chains with sub-second latency
- **Historical backfills** that process years of data in hours
- **Cross-chain pipelines** that unify data from multiple networks into a single output
- **Custom transformations** written in TypeScript, running on distributed compute

## Current state

The Neighborhood is live with Indexing Co as the primary operator. The protocol supports validator staking on partner chains including Syndicate. As the network grows, additional node operators will join to expand coverage and reduce latency.

---

[Read the Docs](https://docs.indexing.co)

[Read the Lite Paper](https://docsend.com/view/vpbawiqg5kvz9yv2)

[Explore the Console](https://console.indexing.co)


---
title: About Indexing Co
url: https://www.indexing.co/about
description: Blockchain data infrastructure for teams that need structured on-chain data at scale -- 100+ chains, sub-3-second latency, direct delivery.
---

<div class="about-hero">
<h1 class="text-jumbo-regular">About Indexing Co</h1>
<p class="about-hero-sub">Blockchain data infrastructure for teams that need structured on-chain data at scale. 100+ chains, sub-3-second latency, direct delivery.</p>
</div>

<div class="about-section">
<h2 class="about-section-title">What We Do</h2>
<p>Indexing Co builds blockchain data infrastructure. We ingest raw data from 100+ blockchain networks, transform it through custom pipelines, and deliver structured results directly into our customers' databases, warehouses, and APIs.</p>
<p>Payment platforms use us to confirm stablecoin transfers in real time. DeFi teams use us to track swaps, positions, and liquidations across chains. Data science teams use us to backfill years of transaction history for model training. AI agents use us to query on-chain state through MCP tools.</p>
<p>The pattern is the same: teams need structured blockchain data, fast, without running their own indexing infrastructure.</p>
</div>

<div class="about-stats">
<div class="about-stat">
<span class="about-stat-num">100+</span>
<span class="about-stat-label">Blockchain networks</span>
</div>
<div class="about-stat">
<span class="about-stat-num">&lt;3s</span>
<span class="about-stat-label">Block-to-query latency</span>
</div>
<div class="about-stat">
<span class="about-stat-num">1B+</span>
<span class="about-stat-label">Events processed daily</span>
</div>
<div class="about-stat">
<span class="about-stat-num">10TB+</span>
<span class="about-stat-label">Data delivered</span>
</div>
</div>

<div class="about-section">
<h2 class="about-section-title">Why We Exist</h2>
<p>Accessing on-chain data at scale is an infrastructure problem. Every team that builds on blockchain data hits the same wall: raw RPC responses are unstructured, multi-chain coverage is fragmented, and building custom indexers eats months of engineering time.</p>
<p>We built Indexing Co to remove that wall. One platform that handles ingestion, transformation, and delivery across every major chain. Teams spend time on their product, not on data plumbing.</p>
</div>

<div class="about-section">
<h2 class="about-section-title">What We Ship</h2>
<div class="about-ship-grid">
<div class="about-ship-card">
<strong>100+ blockchain networks</strong>
<span>Indexed in parallel</span>
</div>
<div class="about-ship-card">
<strong>Sub-3-second latency</strong>
<span>From block confirmation to queryable data</span>
</div>
<div class="about-ship-card">
<strong>1B+ events processed daily</strong>
<span>Across production pipelines</span>
</div>
<div class="about-ship-card">
<strong>Direct delivery</strong>
<span>PostgreSQL, BigQuery, webhooks, GraphQL, S3, and Kafka</span>
</div>
<div class="about-ship-card">
<strong>Custom transforms</strong>
<span>In TypeScript. Your business logic, your schema</span>
</div>
</div>
</div>

<div class="about-section">
<h2 class="about-section-title">Who Uses It</h2>
<p>Fintech companies, DeFi protocols, enterprise platforms, AI agent builders, and data teams. From startups indexing their first contract to institutions tracking millions of wallets across dozens of chains.</p>
<a href="/case-studies" class="button-link button-link-medium">Read Our Case Studies</a>
</div>

<div class="about-section">
<h2 class="about-section-title">Get in Touch</h2>
<p>We work directly with teams to design data pipelines that fit their stack. No generic onboarding. Tell us what you're building and we'll show you how the data gets there.</p>
<a href="/contact" class="button-link button-link-medium">Contact Us</a>
</div>

<style>
#page-about #content {
  width: min(1100px, calc(100vw - 48px));
  display: block;
  gap: 0;
}
#page-about #content > h1:first-of-type { display: none; }
#page-about #content > h2:first-of-type { display: none; }

.about-hero {
  background: var(--Brand-Indexing-Green);
  color: #000;
  padding: 80px 56px;
  border-radius: 16px;
  margin-bottom: 64px;
}
.about-hero h1 {
  color: #000;
  margin-bottom: 16px;
}
.about-hero-sub {
  font-size: 18px;
  line-height: 1.5;
  max-width: 600px;
  opacity: 0.8;
}

.about-section {
  margin-bottom: 64px;
}
.about-section-title {
  font-size: 28px;
  font-weight: 500;
  letter-spacing: -0.5px;
  margin-bottom: 20px;
  color: var(--Text-Primary);
}
.about-section p {
  font-size: 16px;
  line-height: 1.7;
  color: var(--Text-Secondary);
  margin-bottom: 16px;
  max-width: 680px;
}

.about-stats {
  display: grid;
  grid-template-columns: repeat(4, 1fr);
  gap: 16px;
  margin-bottom: 64px;
}
.about-stat {
  display: flex;
  flex-direction: column;
  gap: 8px;
  padding: 32px 24px;
  border-radius: 12px;
  background: light-dark(#f5f5f5, #1c1c1e);
}
.about-stat-num {
  font-size: 36px;
  font-weight: 600;
  letter-spacing: -1px;
  color: var(--Brand-Indexing-Green);
}
.about-stat-label {
  font-size: 14px;
  color: var(--Text-Secondary);
}

.about-ship-grid {
  display: grid;
  grid-template-columns: repeat(2, 1fr);
  gap: 12px;
  margin-top: 16px;
}
.about-ship-card {
  padding: 24px;
  border-radius: 12px;
  background: light-dark(#f5f5f5, #1c1c1e);
  display: flex;
  flex-direction: column;
  gap: 6px;
}
.about-ship-card strong {
  font-size: 15px;
  color: var(--Text-Primary);
}
.about-ship-card span {
  font-size: 14px;
  color: var(--Text-Secondary);
}

@media screen and (max-width: 768px) {
  .about-hero {
    padding: 48px 32px;
  }
  .about-stats {
    grid-template-columns: repeat(2, 1fr);
  }
  .about-ship-grid {
    grid-template-columns: 1fr;
  }
}
</style>


---
title: Indexing Co Brand Kit
url: https://www.indexing.co/brand-kit
description: Logos, colors, typography, and brand guidelines for the Indexing Company.
---

<h1 class="text-headline-regular" style="display:none">Indexing Co Brand Kit</h1>

<div class="bk-layout">

<aside class="bk-sidebar">
<div class="bk-sidebar-inner">
<div class="bk-sidebar-title">Brand Kit</div>
<button class="bk-nav-toggle" aria-expanded="false">
<span class="bk-nav-toggle-label">Logo & Mark</span>
<svg class="bk-nav-toggle-icon" width="12" height="12" viewBox="0 0 12 12" fill="none"><path d="M3 4.5L6 7.5L9 4.5" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/></svg>
</button>
<nav class="bk-sidebar-nav">
<a href="#ch-logo" class="bk-nav-link active"><span class="bk-nav-num">01</span> Logo & Mark</a>
<a href="#ch-colors" class="bk-nav-link"><span class="bk-nav-num">02</span> Color Palette</a>
<a href="#ch-type" class="bk-nav-link"><span class="bk-nav-num">03</span> Typography</a>
<a href="#ch-voice" class="bk-nav-link"><span class="bk-nav-num">04</span> Voice & Personality</a>
<a href="#ch-rules" class="bk-nav-link"><span class="bk-nav-num">05</span> Usage Rules</a>
<a href="#ch-downloads" class="bk-nav-link"><span class="bk-nav-num">06</span> Downloads</a>
</nav>
<div class="bk-sidebar-actions">
<a href="/tools/brand-assets.html" class="bk-sidebar-btn">Generate Assets</a>
</div>
</div>
</aside>

<main class="bk-main">

<!-- ============================================ -->
<!-- 01 — Logo & Mark                             -->
<!-- ============================================ -->
<section class="bk-chapter" id="ch-logo">
<div class="bk-chapter-header">
<span class="bk-chapter-num">01</span>
<h2>Logo & Mark</h2>
</div>

<p class="bk-intro">The Indexing Company identity distills clarity, speed, and intelligence into a single system. The wordmark carries the brand at every scale, and Dex (our geometric rabbit) grounds it with personality.</p>


<h3 class="bk-subsection-title">Wordmark</h3>
<p class="bk-body">The primary logo for most contexts. Horizontal layout for headers, footers, and wide spaces.</p>

<div class="bk-showcase-row">
<a href="/assets/wordmark-new.svg" download class="bk-showcase bk-showcase-light bk-showcase-dl">
<img src="/assets/wordmark-new.svg" alt="Indexing Co Wordmark on light" />
<span class="bk-dl-hint">SVG</span>
</a>
<a href="/assets/wordmark-new.svg" download class="bk-showcase bk-showcase-dark bk-showcase-dl">
<img src="/assets/wordmark-new.svg" alt="Indexing Co Wordmark on dark" style="filter: invert(1)" />
<span class="bk-dl-hint">SVG</span>
</a>
</div>

<h3 class="bk-subsection-title">Wordmark (Vertical)</h3>
<p class="bk-body">For square or compact contexts: social avatars, app icons, stacked layouts.</p>

<div class="bk-showcase-row">
<a href="/assets/wordmark-vertical.svg" download class="bk-showcase bk-showcase-light bk-showcase-dl" style="max-width: 340px">
<img src="/assets/wordmark-vertical.svg" alt="Indexing Co Vertical Wordmark on light" />
<span class="bk-dl-hint">SVG</span>
</a>
<a href="/assets/wordmark-vertical.svg" download class="bk-showcase bk-showcase-dark bk-showcase-dl" style="max-width: 340px">
<img src="/assets/wordmark-vertical.svg" alt="Indexing Co Vertical Wordmark on dark" style="filter: invert(1)" />
<span class="bk-dl-hint">SVG</span>
</a>
</div>

<h3 class="bk-subsection-title">Dex (Brandmark)</h3>
<p class="bk-body">Dex is our mascot, a geometric rabbit representing speed and intelligence. Use as a standalone mark or alongside the wordmark.</p>

<div class="bk-showcase-row">
<a href="/assets/dex.svg" download class="bk-showcase bk-showcase-light bk-showcase-dl" style="max-width: 260px">
<img src="/assets/dex.svg" alt="Dex Brandmark on light" style="max-height: 120px" />
<span class="bk-dl-hint">SVG</span>
</a>
<a href="/assets/dex.svg" download class="bk-showcase bk-showcase-dark bk-showcase-dl" style="max-width: 260px">
<img src="/assets/dex.svg" alt="Dex Brandmark on dark" style="filter: invert(1); max-height: 120px" />
<span class="bk-dl-hint">SVG</span>
</a>
<a href="/assets/dex.svg" download class="bk-showcase bk-showcase-green bk-showcase-dl" style="max-width: 260px">
<img src="/assets/dex.svg" alt="Dex Brandmark on green" style="max-height: 120px" />
<span class="bk-dl-hint">SVG</span>
</a>
</div>

<h3 class="bk-subsection-title">Dex Emoji</h3>
<p class="bk-body">A ready-made 128×128 PNG for Slack, Discord, and other platforms.</p>

<div class="bk-showcase-row">
<a href="/assets/dex-emoji.png" download class="bk-showcase bk-showcase-light bk-showcase-dl" style="max-width: 200px">
<img src="/assets/dex-emoji.png" alt="Dex Emoji" style="max-height: 64px" />
<span class="bk-caption">128×128 PNG</span>
</a>
</div>

<h3 class="bk-subsection-title">Legacy Assets</h3>
<p class="bk-body">Older marks still available, but the above versions are preferred for new materials.</p>

<div class="bk-showcase-row">
<a href="/assets/dex-bit.svg" download class="bk-showcase bk-showcase-light bk-showcase-dl" style="max-width: 200px">
<img src="/assets/dex-bit.svg" alt="Dex 2-Bit" style="max-height: 80px" />
<span class="bk-caption">Dex 2-Bit</span>
</a>
<a href="/assets/dex-retro.svg" download class="bk-showcase bk-showcase-light bk-showcase-dl" style="max-width: 200px">
<img src="/assets/dex-retro.svg" alt="Dex Retro" style="max-height: 80px" />
<span class="bk-caption">Dex Retro</span>
</a>
<a href="/assets/wordmark.svg" download class="bk-showcase bk-showcase-light bk-showcase-dl">
<img src="/assets/wordmark.svg" alt="Legacy Wordmark" style="max-height: 60px" />
<span class="bk-caption">Legacy Wordmark</span>
</a>
</div>

</section>

<!-- ============================================ -->
<!-- 02 — Color Palette                           -->
<!-- ============================================ -->
<section class="bk-chapter" id="ch-colors">
<div class="bk-chapter-header">
<span class="bk-chapter-num">02</span>
<h2>Color Palette</h2>
</div>

<p class="bk-intro">The palette is minimal and intentional. Black and white carry the brand; green and pink provide energy and character.</p>

<h3 class="bk-subsection-title">Primary</h3>

<div class="bk-color-grid">
<div class="bk-color-swatch bk-swatch-black" style="background:#000000; color:#ffffff">
<span class="bk-color-name">Black</span>
<span class="bk-color-hex">#000000</span>
</div>
<div class="bk-color-swatch" style="background:#FFFFFF; color:#000000; border: 1px solid var(--UI-Gray-5)">
<span class="bk-color-name">White</span>
<span class="bk-color-hex">#FFFFFF</span>
</div>
<div class="bk-color-swatch" style="background:#4AF120; color:#000000">
<span class="bk-color-name">Indexing Green</span>
<span class="bk-color-hex">#4AF120</span>
</div>
<div class="bk-color-swatch" style="background:#DD67AB; color:#ffffff">
<span class="bk-color-name">Pink</span>
<span class="bk-color-hex">#DD67AB</span>
</div>
</div>

<h3 class="bk-subsection-title">Neutral</h3>

<div class="bk-color-grid">
<div class="bk-color-swatch" style="background:#8E8E93; color:#ffffff">
<span class="bk-color-name">Gray</span>
<span class="bk-color-hex">#8E8E93</span>
</div>
<div class="bk-color-swatch" style="background:#EDEDED; color:#000000">
<span class="bk-color-name">White Smoke</span>
<span class="bk-color-hex">#EDEDED</span>
</div>
</div>

<h3 class="bk-subsection-title">Usage</h3>
<div class="bk-usage-notes">
<div class="bk-usage-note">
<strong>Indexing Green</strong> Our most distinctive color. Use for hero backgrounds, section blocks, and CTA buttons (with dark text). Also works as a text accent on dark backgrounds. Fails WCAG AA on white (~1.5:1). Passes on black (~13.9:1). Pair with black text when used as a background.
</div>
<div class="bk-usage-note">
<strong>Pink</strong> Secondary accent for highlights, data visualizations, and variety.
</div>
<div class="bk-usage-note">
<strong>Black + White</strong> Primary content colors. Most of the brand is black and white.
</div>
<div class="bk-usage-note">
<strong>Grays</strong> UI elements, borders, secondary text.
</div>
</div>

</section>

<!-- ============================================ -->
<!-- 03 — Typography                              -->
<!-- ============================================ -->
<section class="bk-chapter" id="ch-type">
<div class="bk-chapter-header">
<span class="bk-chapter-num">03</span>
<h2>Typography</h2>
</div>

<p class="bk-intro">Inter is our only typeface. It's clean, highly legible, and available everywhere. Fira Code supplements it for monospace contexts.</p>

<div class="bk-type-specimen bk-type-specimen-dark">
<div class="bk-type-specimen-label">Inter / Variable Weight</div>
<div class="bk-type-specimen-display">
<span style="font-weight:300">Inter</span> <span class="bk-type-weights">300 400 500</span>
</div>
</div>

<div class="bk-type-specimen bk-type-specimen-light">
<div class="bk-type-specimen-label">Fira Code / Monospace</div>
<div class="bk-type-specimen-display" style="font-family: 'Fira Code', monospace; font-size: clamp(28px, 4vw, 48px)">
<span style="font-weight:400">Fira Code</span> <span class="bk-type-weights" style="font-family: 'Fira Code', monospace">400 500</span>
</div>
</div>

<h3 class="bk-subsection-title">Type Scale</h3>

<div class="bk-type-samples">
<div class="bk-type-sample">
<span class="bk-type-sample-label">Jumbo / 60px / Light 300</span>
<span class="text-jumbo-regular">Build with clarity</span>
</div>
<div class="bk-type-sample">
<span class="bk-type-sample-label">Display / 48px / Regular 400</span>
<span class="text-display-regular">Real-time indexing</span>
</div>
<div class="bk-type-sample">
<span class="bk-type-sample-label">Headline / 28px / Medium 500</span>
<span class="text-headline-bold">The data layer for onchain</span>
</div>
<div class="bk-type-sample">
<span class="bk-type-sample-label">Subhead / 24px / Regular 400</span>
<span class="text-subhead-regular">Pipelines integrate directly to your storage</span>
</div>
<div class="bk-type-sample">
<span class="bk-type-sample-label">Body / 16px / Regular 400</span>
<span class="text-body-base-regular">The Indexing Company transforms complex blockchain data into structured, accessible information. Faster decisions, smoother payments, scalable digital products.</span>
</div>
<div class="bk-type-sample">
<span class="bk-type-sample-label">Caption / 14px / Regular 400</span>
<span class="text-caption-regular">No middlemen, direct to you.</span>
</div>
</div>

<h3 class="bk-subsection-title">Type Hierarchy</h3>

<div class="bk-table-wrap">
<table class="bk-table">
<thead>
<tr><th>Role</th><th>Weight</th><th>Size</th><th>Use</th></tr>
</thead>
<tbody>
<tr><td>Jumbo</td><td>Light 300</td><td>60px / 36px mobile</td><td>Hero statements</td></tr>
<tr><td>Display</td><td>Regular 400</td><td>48px / 30px mobile</td><td>Section titles</td></tr>
<tr><td>Headline</td><td>Medium 500</td><td>28px / 22px mobile</td><td>Page titles, cards</td></tr>
<tr><td>Subhead</td><td>Regular 400</td><td>24px / 20px mobile</td><td>Section subtitles</td></tr>
<tr><td>Body</td><td>Regular 400</td><td>16px</td><td>Paragraph text</td></tr>
<tr><td>Caption</td><td>Regular 400</td><td>14px</td><td>Labels, metadata</td></tr>
<tr><td>Code</td><td>Fira Code 500</td><td>16px</td><td>Code snippets</td></tr>
</tbody>
</table>
</div>

</section>

<!-- ============================================ -->
<!-- 04 — Voice & Personality                     -->
<!-- ============================================ -->
<section class="bk-chapter" id="ch-voice">
<div class="bk-chapter-header">
<span class="bk-chapter-num">04</span>
<h2>Voice & Personality</h2>
</div>

<p class="bk-intro">We are a blockchain infrastructure company that simplifies complexity. Our brand voice is confident and direct. Technical without being inaccessible.</p>

<div class="bk-personality-grid">
<div class="bk-personality-trait">Innovative</div>
<div class="bk-personality-trait">Fast</div>
<div class="bk-personality-trait">Clean</div>
<div class="bk-personality-trait">Sophisticated</div>
<div class="bk-personality-trait">Intelligent</div>
</div>

</section>

<!-- ============================================ -->
<!-- 05 — Usage Rules                             -->
<!-- ============================================ -->
<section class="bk-chapter" id="ch-rules">
<div class="bk-chapter-header">
<span class="bk-chapter-num">05</span>
<h2>Usage Rules</h2>
</div>

<p class="bk-intro">These guidelines ensure the brand remains consistent and recognizable across all touchpoints.</p>

<h3 class="bk-subsection-title">Logo Usage</h3>

<div class="bk-rules-grid">
<div class="bk-rule bk-rule-do">
<strong>Do</strong>
<ul>
<li>Use on solid backgrounds (black, white, or dark gray)</li>
<li>Maintain clear space equal to the height of the "X" in the wordmark</li>
<li>Use the provided SVGs. They adapt to light and dark contexts</li>
</ul>
</div>
<div class="bk-rule bk-rule-dont">
<strong>Don't</strong>
<ul>
<li>Distort, rotate, or stretch the logo</li>
<li>Place on busy or low-contrast backgrounds</li>
<li>Modify the letterforms or Dex's proportions</li>
<li>Add effects (shadows, outlines, gradients)</li>
<li>Use the logo below 76px wide (digital) or 27mm (print)</li>
</ul>
</div>
</div>

<h3 class="bk-subsection-title">Color Usage</h3>

<div class="bk-showcase-row">
<div class="bk-showcase bk-showcase-dark" style="flex: 1">
<img src="/assets/wordmark-new.svg" alt="Wordmark on black" style="filter: invert(1); max-height: 48px" />
</div>
<div class="bk-showcase" style="background: #4AF120; flex: 1">
<img src="/assets/wordmark-new.svg" alt="Wordmark on green" style="max-height: 48px" />
</div>
</div>
<div class="bk-showcase-row" style="margin-top: 12px">
<div class="bk-showcase bk-showcase-light" style="flex: 1">
<img src="/assets/wordmark-new.svg" alt="Wordmark on light" style="max-height: 48px" />
</div>
<div class="bk-showcase" style="background: #DD67AB; flex: 1">
<img src="/assets/wordmark-new.svg" alt="Wordmark on pink" style="filter: invert(1); max-height: 48px" />
</div>
</div>

</section>

<!-- ============================================ -->
<!-- 06 — Downloads                               -->
<!-- ============================================ -->
<section class="bk-chapter" id="ch-downloads">
<div class="bk-chapter-header">
<span class="bk-chapter-num">06</span>
<h2>Downloads</h2>
</div>

<p class="bk-intro">All assets and references you need to create on-brand materials.</p>

<h3 class="bk-subsection-title">Assets</h3>

<div class="bk-table-wrap">
<table class="bk-table">
<thead>
<tr><th>Asset</th><th>Format</th><th>Download</th></tr>
</thead>
<tbody>
<tr><td>Wordmark (horizontal)</td><td>SVG</td><td><a href="/assets/wordmark-new.svg">Download</a></td></tr>
<tr><td>Wordmark (vertical)</td><td>SVG</td><td><a href="/assets/wordmark-vertical.svg">Download</a></td></tr>
<tr><td>Dex brandmark</td><td>SVG</td><td><a href="/assets/dex.svg">Download</a></td></tr>
<tr><td>Dex emoji (Slack/Discord)</td><td>PNG</td><td><a href="/assets/dex-emoji.png">Download</a></td></tr>
</tbody>
</table>
</div>

<h3 class="bk-subsection-title">CSS Variables</h3>

<pre class="bk-code"><code>--Brand-Indexing-Green: #4AF120;
--Brand-Indexing-Pink: #DD67AB;
--Brand-White-Smoke: #EDEDED;</code></pre>

<div style="margin-top: 48px">
<a href="/tools/brand-assets.html" class="bk-cta-btn">Generate Branded Assets →</a>
</div>

</section>

</main>
</div>

<style>
/* ============================================
   Brand Kit — Content Override
   ============================================ */
#page-brand-kit #content {
  width: min(1200px, calc(100vw - 48px));
  max-width: calc(100vw - 48px);
  display: block;
  gap: 0;
}
#page-brand-kit #content > h1 { display: none; }

/* ============================================
   Layout — Sidebar + Main
   ============================================ */
.bk-layout {
  display: grid;
  grid-template-columns: 220px 1fr;
  gap: 64px;
  min-height: 80vh;
}
.bk-main {
  min-width: 0;
}
.bk-sidebar {
  position: relative;
}
.bk-sidebar-inner {
  position: sticky;
  top: 100px;
  display: flex;
  flex-direction: column;
  gap: 32px;
}
.bk-sidebar-title {
  font-size: 13px;
  font-weight: 500;
  text-transform: uppercase;
  letter-spacing: 1.5px;
  color: var(--Text-Secondary);
}

/* ============================================
   Sidebar Navigation
   ============================================ */
.bk-nav-toggle {
  display: none;
}
.bk-sidebar-nav {
  display: flex;
  flex-direction: column;
  gap: 0;
}
.bk-nav-link {
  display: flex;
  align-items: center;
  gap: 12px;
  padding: 10px 0;
  padding-left: 16px;
  text-decoration: none;
  color: var(--Text-Secondary);
  font-size: 14px;
  font-weight: 400;
  border-left: 2px solid transparent;
  transition: color 0.2s, border-color 0.2s;
}
.bk-nav-link:hover {
  color: var(--Text-Primary);
}
.bk-nav-link.active {
  color: var(--Text-Primary);
  font-weight: 500;
  border-left-color: var(--Brand-Indexing-Green);
}
.bk-nav-num {
  font-size: 12px;
  font-weight: 400;
  color: var(--Text-Secondary);
  min-width: 18px;
  font-variant-numeric: tabular-nums;
}
.bk-nav-link.active .bk-nav-num {
  color: var(--Text-Primary);
}

/* ============================================
   Sidebar Actions
   ============================================ */
.bk-sidebar-actions {
  display: flex;
  flex-direction: column;
  gap: 8px;
  padding-top: 16px;
  border-top: 1px solid var(--UI-Gray-5);
}
.bk-sidebar-btn {
  display: block;
  padding: 10px 16px;
  text-align: center;
  font-size: 13px;
  font-weight: 500;
  text-decoration: none !important;
  border-radius: 8px;
  background: var(--Text-Primary);
  color: var(--UI-Backgrounds-Primary) !important;
  transition: opacity 0.2s;
}
.bk-sidebar-btn:hover { opacity: 0.85; }

/* ============================================
   Chapters
   ============================================ */
.bk-chapter {
  padding: 72px 0;
  border-bottom: 1px solid var(--UI-Gray-5);
}
.bk-chapter:first-child {
  padding-top: 0;
}
.bk-chapter:last-child {
  border-bottom: none;
}
.bk-chapter-header {
  display: flex;
  align-items: baseline;
  justify-content: space-between;
  margin-bottom: 40px;
}
.bk-chapter-num {
  font-size: clamp(48px, 6vw, 72px);
  font-weight: 300;
  color: var(--Text-Secondary);
  letter-spacing: -3px;
  line-height: 1;
  opacity: 0.4;
}
.bk-chapter-header h2 {
  font-size: clamp(36px, 5vw, 64px);
  font-weight: 300;
  letter-spacing: -2px;
  line-height: 1;
  color: var(--Text-Primary);
  margin: 0;
}

/* ============================================
   Content Elements
   ============================================ */
.bk-intro {
  font-size: 16px;
  line-height: 1.6;
  color: var(--Text-Secondary);
  max-width: 620px;
  margin-bottom: 48px;
}
.bk-body {
  font-size: 15px;
  line-height: 1.5;
  color: var(--Text-Secondary);
  max-width: 560px;
  margin-bottom: 24px;
}
.bk-caption {
  font-size: 13px;
  color: var(--Text-Secondary);
  margin-top: 8px;
}
.bk-subsection-title {
  font-size: 16px;
  font-weight: 500;
  color: var(--Text-Primary);
  margin: 48px 0 12px;
  letter-spacing: -0.2px;
}
.bk-section-row {
  display: flex;
  justify-content: flex-start;
  gap: 24px;
  margin-bottom: 40px;
}
.bk-download-link {
  font-size: 14px;
  color: var(--Text-Secondary);
  text-decoration: underline;
  text-underline-offset: 3px;
}
.bk-download-link:hover {
  color: var(--Text-Primary);
}

/* ============================================
   Logo Showcases
   ============================================ */
.bk-showcase-row {
  display: flex;
  gap: 12px;
  flex-wrap: wrap;
  margin: 16px 0 32px;
}
.bk-showcase {
  display: flex;
  flex-direction: column;
  align-items: center;
  justify-content: center;
  gap: 12px;
  padding: 56px 40px;
  border-radius: 12px;
  flex: 1;
  min-width: 180px;
}
.bk-showcase img {
  max-height: 140px;
  max-width: 85%;
  width: auto;
}
.bk-showcase-light {
  background: light-dark(#EDEDED, #2c2c2e);
}
.bk-showcase-light img {
  filter: light-dark(none, invert(1));
}
.bk-showcase-dark {
  background: light-dark(#000000, #111111);
  border: light-dark(none, 1px solid #333);
}
.bk-showcase-green { background: var(--Brand-Indexing-Green); }
a.bk-showcase-dl {
  text-decoration: none;
  cursor: pointer;
  position: relative;
  transition: opacity 0.2s, box-shadow 0.2s;
}
a.bk-showcase-dl:hover {
  opacity: 0.9;
  box-shadow: 0 0 0 2px var(--Brand-Indexing-Green);
}
.bk-dl-hint {
  position: absolute;
  top: 12px;
  right: 12px;
  font-size: 11px;
  font-weight: 500;
  text-transform: uppercase;
  letter-spacing: 0.5px;
  padding: 3px 8px;
  border-radius: 4px;
  background: rgba(0,0,0,0.08);
  color: var(--Text-Secondary);
  opacity: 0;
  transition: opacity 0.2s;
}
.bk-showcase-dark .bk-dl-hint {
  background: rgba(255,255,255,0.15);
  color: rgba(255,255,255,0.7);
}
.bk-showcase-green .bk-dl-hint {
  background: rgba(0,0,0,0.1);
  color: rgba(0,0,0,0.6);
}
a.bk-showcase-dl:hover .bk-dl-hint {
  opacity: 1;
}

/* ============================================
   Color Swatches
   ============================================ */
.bk-color-grid {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  gap: 12px;
  margin: 16px 0 32px;
}
.bk-color-swatch {
  aspect-ratio: 1;
  border-radius: 12px;
  padding: 20px;
  display: flex;
  flex-direction: column;
  justify-content: flex-end;
  gap: 4px;
  min-height: 140px;
}
.bk-color-name {
  font-weight: 500;
  font-size: 15px;
}
.bk-color-hex {
  font-family: "Fira Code", monospace;
  font-size: 13px;
  opacity: 0.7;
}
.bk-swatch-black {
  border: light-dark(none, 1px solid #333);
}

/* ============================================
   Usage Notes
   ============================================ */
.bk-usage-notes {
  display: flex;
  flex-direction: column;
  gap: 12px;
  margin: 16px 0;
}
.bk-usage-note {
  font-size: 15px;
  line-height: 1.5;
  color: var(--Text-Secondary);
  padding-left: 16px;
  border-left: 2px solid var(--UI-Gray-5);
}
.bk-usage-note strong {
  color: var(--Text-Primary);
}

/* ============================================
   Typography Specimens
   ============================================ */
.bk-type-specimen {
  padding: 56px 48px;
  border-radius: 12px;
  margin: 16px 0 12px;
}
.bk-type-specimen-dark {
  background: light-dark(#000, #111);
  color: #fff;
  border: light-dark(none, 1px solid #333);
}
.bk-type-specimen-light {
  background: light-dark(#EDEDED, #2c2c2e);
  color: var(--Text-Primary);
}
.bk-type-specimen-label {
  font-size: 13px;
  opacity: 0.5;
  margin-bottom: 24px;
  letter-spacing: 0.5px;
}
.bk-type-specimen-display {
  font-size: clamp(40px, 6vw, 80px);
  font-weight: 300;
  line-height: 1.2;
  letter-spacing: -2px;
}
.bk-type-weights {
  font-size: clamp(28px, 4vw, 56px);
  opacity: 0.4;
  font-weight: 400;
}
.bk-type-samples {
  display: flex;
  flex-direction: column;
  gap: 32px;
  margin: 24px 0;
}
.bk-type-sample {
  display: flex;
  flex-direction: column;
  gap: 8px;
  padding-bottom: 24px;
  border-bottom: 1px solid var(--UI-Gray-5);
}
.bk-type-sample:last-child {
  border-bottom: none;
}
.bk-type-sample-label {
  font-size: 13px;
  color: var(--Text-Secondary);
}

/* ============================================
   Personality Traits
   ============================================ */
.bk-personality-grid {
  display: flex;
  flex-wrap: wrap;
  gap: 12px;
  margin: 32px 0;
}
.bk-personality-trait {
  font-size: clamp(28px, 4vw, 48px);
  font-weight: 300;
  letter-spacing: -1.5px;
  color: var(--Text-Primary);
  padding: 24px 40px;
  border-radius: 12px;
  background: light-dark(#EDEDED, #2c2c2e);
}

/* ============================================
   Usage Rules
   ============================================ */
.bk-rules-grid {
  display: grid;
  grid-template-columns: 1fr 1fr;
  gap: 16px;
  margin: 16px 0 40px;
}
.bk-rule {
  padding: 24px;
  border-radius: 12px;
}
.bk-rule strong {
  font-size: 15px;
  display: block;
  margin-bottom: 12px;
}
.bk-rule ul {
  margin: 0;
  padding-left: 20px;
  font-size: 14px;
  line-height: 1.6;
  color: var(--Text-Secondary);
}
.bk-rule-do {
  background: rgba(74, 241, 32, 0.06);
  border: 1px solid rgba(74, 241, 32, 0.25);
}
.bk-rule-do strong { color: var(--Brand-Indexing-Green); }
.bk-rule-dont {
  background: rgba(221, 103, 171, 0.06);
  border: 1px solid rgba(221, 103, 171, 0.25);
}
.bk-rule-dont strong { color: var(--Brand-Indexing-Pink); }

/* ============================================
   Tables
   ============================================ */
.bk-table-wrap {
  overflow-x: auto;
  -webkit-overflow-scrolling: touch;
  margin: 16px 0 32px;
}
.bk-table {
  width: 100%;
  border-collapse: collapse;
  font-size: 14px;
}
.bk-table th,
.bk-table td {
  text-align: left;
  padding: 12px 16px;
  border-bottom: 1px solid var(--UI-Gray-5);
}
.bk-table th {
  font-weight: 500;
  font-size: 13px;
  color: var(--Text-Secondary);
  text-transform: uppercase;
  letter-spacing: 0.5px;
}
.bk-table td {
  color: var(--Text-Primary);
}
.bk-table td a {
  color: var(--Text-Primary);
  text-decoration: underline;
  text-underline-offset: 3px;
}

/* ============================================
   Code Block
   ============================================ */
.bk-code {
  background: #1a1a1a;
  color: var(--Brand-Indexing-Green);
  padding: 24px 32px;
  border-radius: 12px;
  font-family: "Fira Code", monospace;
  font-size: 14px;
  line-height: 1.8;
  overflow-x: auto;
  margin: 16px 0;
}
.bk-code code {
  color: var(--Brand-Indexing-Green) !important;
  font-size: 14px;
}

/* ============================================
   CTA Button
   ============================================ */
.bk-cta-btn {
  display: inline-block;
  padding: 14px 32px;
  background: var(--Text-Primary);
  color: var(--UI-Backgrounds-Primary) !important;
  font-size: 15px;
  font-weight: 500;
  text-decoration: none !important;
  border-radius: 8px;
  transition: opacity 0.2s;
}
.bk-cta-btn:hover { opacity: 0.85; }

/* ============================================
   Responsive
   ============================================ */
@media screen and (max-width: 900px) {
  #page-brand-kit #content {
    width: 100%;
    max-width: 100%;
    overflow-x: hidden;
  }
  .bk-layout {
    display: block;
  }
  .bk-sidebar {
    position: relative;
    margin-bottom: 24px;
  }
  .bk-sidebar-inner {
    position: relative;
    top: 0;
    gap: 12px;
  }
  .bk-sidebar-title {
    font-size: 12px;
  }
  .bk-nav-toggle {
    display: flex;
    align-items: center;
    justify-content: space-between;
    width: 100%;
    padding: 10px 14px;
    background: light-dark(#EDEDED, #1c1c1e);
    border: 1px solid light-dark(#d1d1d6, #333);
    border-radius: 8px;
    color: var(--Text-Primary);
    font-size: 14px;
    font-weight: 500;
    font-family: inherit;
    cursor: pointer;
    transition: border-color 0.15s;
  }
  .bk-nav-toggle:hover {
    border-color: var(--Brand-Indexing-Green);
  }
  .bk-nav-toggle[aria-expanded="true"] .bk-nav-toggle-icon {
    transform: rotate(180deg);
  }
  .bk-nav-toggle-icon {
    transition: transform 0.2s;
    opacity: 0.5;
  }
  .bk-sidebar-nav {
    display: none;
    flex-direction: column;
    gap: 0;
    background: light-dark(#EDEDED, #1c1c1e);
    border: 1px solid light-dark(#d1d1d6, #333);
    border-top: none;
    border-radius: 0 0 8px 8px;
    margin-top: -4px;
    padding: 4px 0;
    overflow: hidden;
  }
  .bk-sidebar-nav.open {
    display: flex;
  }
  .bk-nav-link {
    border-left: none;
    padding: 10px 14px;
    font-size: 14px;
    border-bottom: none;
  }
  .bk-nav-link:hover {
    background: light-dark(rgba(0,0,0,0.04), rgba(255,255,255,0.06));
  }
  .bk-nav-link.active {
    border-left: none;
    color: var(--Brand-Indexing-Green);
  }
  .bk-nav-link.active .bk-nav-num {
    color: var(--Brand-Indexing-Green);
  }
  .bk-sidebar-actions {
    flex-direction: row;
  }
  .bk-sidebar-btn {
    flex: 1;
    font-size: 12px;
    padding: 8px 12px;
  }
  .bk-chapter {
    padding: 36px 0;
  }
  .bk-chapter-header {
    margin-bottom: 20px;
  }
  .bk-chapter-header h2 {
    font-size: 24px;
    letter-spacing: -1px;
  }
  .bk-chapter-num {
    font-size: 28px;
    letter-spacing: -1px;
  }
  .bk-intro {
    font-size: 14px;
    margin-bottom: 24px;
  }
  .bk-body {
    font-size: 14px;
  }
  .bk-subsection-title {
    margin: 24px 0 8px;
    font-size: 15px;
  }
  .bk-rules-grid {
    grid-template-columns: 1fr;
  }
  .bk-color-grid {
    grid-template-columns: repeat(2, 1fr);
    gap: 8px;
  }
  .bk-color-swatch {
    aspect-ratio: auto;
    min-height: 80px;
    padding: 14px;
  }
  .bk-color-name {
    font-size: 13px;
  }
  .bk-color-hex {
    font-size: 11px;
  }
  .bk-showcase-row {
    gap: 8px;
    margin: 8px 0 20px;
  }
  .bk-showcase-row > * {
    max-width: 100% !important;
  }
  .bk-showcase {
    padding: 24px 16px;
    min-width: 120px;
  }
  .bk-showcase img {
    max-height: 48px;
  }
  .bk-type-specimen {
    padding: 24px 16px;
  }
  .bk-type-specimen-display {
    font-size: clamp(28px, 5vw, 48px) !important;
  }
  .bk-type-weights {
    font-size: clamp(20px, 3vw, 36px) !important;
  }
  .bk-personality-grid {
    gap: 8px;
    margin: 20px 0;
  }
  .bk-personality-trait {
    padding: 12px 20px;
    font-size: 20px;
  }
  .bk-code {
    padding: 16px;
    font-size: 13px;
  }
  .bk-code code {
    font-size: 13px !important;
  }
  .bk-table th,
  .bk-table td {
    padding: 8px 10px;
    font-size: 13px;
    white-space: nowrap;
  }
  .bk-rule {
    padding: 16px;
  }
  .bk-rule strong {
    font-size: 14px;
  }
  .bk-rule ul {
    font-size: 13px;
    padding-left: 16px;
  }
  .bk-usage-note {
    font-size: 14px;
  }
  .bk-cta-btn {
    padding: 12px 24px;
    font-size: 14px;
  }
  .bk-type-sample-label {
    font-size: 12px;
  }
}
</style>

<script>
(function() {
  var chapters = document.querySelectorAll('.bk-chapter');
  var navLinks = document.querySelectorAll('.bk-nav-link');
  var toggle = document.querySelector('.bk-nav-toggle');
  var toggleLabel = document.querySelector('.bk-nav-toggle-label');
  var nav = document.querySelector('.bk-sidebar-nav');
  if (!chapters.length || !navLinks.length) return;

  function updateToggleLabel(link) {
    if (toggleLabel && link) {
      toggleLabel.textContent = link.textContent.trim();
    }
  }

  if (toggle && nav) {
    toggle.addEventListener('click', function() {
      var expanded = this.getAttribute('aria-expanded') === 'true';
      this.setAttribute('aria-expanded', !expanded);
      nav.classList.toggle('open');
    });
  }

  var observer = new IntersectionObserver(function(entries) {
    entries.forEach(function(entry) {
      if (entry.isIntersecting) {
        navLinks.forEach(function(l) { l.classList.remove('active'); });
        var link = document.querySelector('.bk-nav-link[href="#' + entry.target.id + '"]');
        if (link) {
          link.classList.add('active');
          updateToggleLabel(link);
        }
      }
    });
  }, { rootMargin: '-100px 0px -60% 0px', threshold: 0 });

  chapters.forEach(function(ch) { observer.observe(ch); });

  navLinks.forEach(function(link) {
    link.addEventListener('click', function(e) {
      e.preventDefault();
      var target = document.querySelector(this.getAttribute('href'));
      if (target) {
        target.scrollIntoView({ behavior: 'smooth', block: 'start' });
      }
      if (nav) {
        nav.classList.remove('open');
        if (toggle) toggle.setAttribute('aria-expanded', 'false');
      }
    });
  });
})();
</script>


---
title: Privacy Policy
url: https://www.indexing.co/privacy-policy
---

<embed
    src="/assets/The Indexing Co. - Privacy Policy (1.30.24).pdf#view=FitH"
    type="application/pdf"
    width="100%"
    height="600px" />


---
title: Pricing
url: https://www.indexing.co/pricing
description: Built to scale with your workloads — from small experiments to enterprise-grade deployments.
---

# Pricing {: .text-display-regular }

<div class="pricing-header">
  <div class="pricing-toggle">
    <button
      class="pricing-toggle-btn text-body-base-regular active"
      data-period="annual"
    >
      Annual
    </button>
    <button
      class="pricing-toggle-btn text-body-base-regular"
      data-period="monthly"
    >
      Monthly
    </button>
  </div>
</div>

<div class="pricing-grid">
  <div class="pricing-card" data-card-image="/assets/pricing/N.jpg">
    <div class="pricing-card-header">
      <h3 class="text-subhead-regular">Starter</h3>
      <p class="text-caption-regular">
        For teams getting started with real-time data
      </p>
    </div>
    <div class="pricing-card-price">
      <div class="price-amount">
        <span class="price-value text-headline-regular" data-monthly="$10"
          >$10</span
        >
        <span class="price-period text-body-base-regular">to start</span>
      </div>
      <div class="price-usage">
        <span class="text-legal-regular"
          >Then $1 per 1,000 transactions processed</span
        >
      </div>
    </div>
    <div class="pricing-card-features">
      <p class="text-caption-medium">Includes:</p>
      <ul class="feature-list">
        <li class="text-caption-regular">
          Access to all supported
          <a href="https://docs.indexing.co/networks">networks</a>
        </li>
        <li class="text-caption-regular">
          Real-time
          <a href="https://docs.indexing.co/guide/pipelines/create#destinations"
            >delivery to 1 of 3 self-serve destinations</a
          >
        </li>
        <li class="text-caption-regular">Shared network compute</li>
        <li class="text-caption-regular">Self-serve setup in minutes</li>
        <li class="text-caption-regular">Shared SLA</li>
      </ul>
    </div>
    <a
      href="https://accounts.indexing.co"
      class="button-link button-link-small pricing-card-cta"
      >Get Started</a
    >
  </div>

  <div class="pricing-card" data-card-image="/assets/pricing/N.jpg">
    <div class="pricing-card-header">
      <h3 class="text-subhead-regular">Advanced</h3>
      <p class="text-caption-regular">
        For growing projects with scaling workloads.
      </p>
    </div>
    <div class="pricing-card-price">
      <div class="price-amount">
        <span
          class="price-value text-headline-regular"
          data-monthly="$4,500"
          data-annual="$3,750"
          >$3,750</span
        >
        <span class="price-period text-body-base-regular">/ month</span>
        <span class="price-savings text-caption-regular annual-period"
          >(save 15%)</span
        >
      </div>
    </div>
    <div class="pricing-card-features">
      <p class="text-caption-medium">Includes everything in Starter, plus:</p>
      <ul class="feature-list">
        <li class="text-caption-regular">Unlimited usage on shared infra</li>
        <li class="text-caption-regular">Priority backfill support</li>
        <li class="text-caption-regular">
          Unlimited self-service filters and transformations
        </li>
        <li class="text-caption-regular">White Glove Setup</li>
        <li class="text-caption-regular">
          First Certified Transformation included
        </li>
        <li class="text-caption-regular">Slack channel & 24/7 support</li>
      </ul>
    </div>
    <a href="/contact" class="button-link button-link-small pricing-card-cta"
      >Get Advanced</a
    >
  </div>

  <div class="pricing-card" data-card-image="/assets/pricing/N.jpg">
    <div class="pricing-card-header">
      <h3 class="text-subhead-regular">Dedicated</h3>
      <p class="text-caption-regular">
        For teams needing dedicated performance and workloads.
      </p>
    </div>
    <div class="pricing-card-price">
      <div class="price-amount">
        <span
          class="price-value text-headline-regular"
          data-monthly="$8,500"
          data-annual="$7,000"
          >$7,000</span
        >
        <span class="price-period text-body-base-regular">/ month</span>
        <span class="price-savings text-caption-regular annual-period"
          >(save 15%)</span
        >
      </div>
    </div>
    <div class="pricing-card-features">
      <p class="text-caption-medium">Includes everything in Advanced, plus:</p>
      <ul class="feature-list">
        <li class="text-caption-regular">Dedicated infrastructure & SLAs</li>
        <li class="text-caption-regular">Sub-100ms processing</li>
        <li class="text-caption-regular">
          Multi-destination, parallel delivery
        </li>
        <li class="text-caption-regular">Curated monitoring & alerting</li>
        <li class="text-caption-regular">Dedicated support</li>
        <li class="text-caption-regular">
          CI/CD integrations and siloed runtimes
        </li>
        <li class="text-caption-regular">Offchain integrations</li>
      </ul>
    </div>
    <a href="/contact" class="button-link button-link-small pricing-card-cta"
      >Talk to Sales</a
    >
  </div>

  <div class="pricing-card" data-card-image="/assets/pricing/N.jpg">
    <div class="pricing-card-header">
      <h3 class="text-subhead-regular">Enterprise</h3>
      <p class="text-caption-regular">
        Fully managed infrastructure at <s>global</s> your scale.
      </p>
    </div>
    <div class="pricing-card-price">
      <div class="price-amount">
        <span class="price-value text-headline-regular">Let's talk</span>
      </div>
    </div>
    <div class="pricing-card-features">
      <p class="text-caption-medium">Includes everything in Dedicated, plus:</p>
      <ul class="feature-list">
        <li class="text-caption-regular">Multi-node deployments</li>
        <li class="text-caption-regular">On-prem and VPC deployments</li>
        <li class="text-caption-regular">Integrated monitoring & alerting</li>
        <li class="text-caption-regular">
          Private caching & network isolation
        </li>
        <li class="text-caption-regular">
          Delivery to 16+ supported destinations
        </li>
        <li class="text-caption-regular">
          ... and anything else you can dream up
        </li>
      </ul>
    </div>
    <a href="/contact" class="button-link button-link-small pricing-card-cta"
      >Talk to Sales</a
    >
  </div>
</div>

<div class="addons-section">
  <div class="addons-header">
    <p class="text-label-regular">Add-ons & Services</p>
  </div>
  <div class="addons-grid">
    <div class="addon-card">
      <span class="material-symbols-outlined addon-icon">cloud</span>
      <h3 class="text-label-regular">Setup Fee</h3>
      <p class="text-caption-regular">
        Starting at $1K (waived on annual plans)
      </p>
    </div>
    <div class="addon-card">
      <span class="material-symbols-outlined addon-icon">history</span>
      <h3 class="text-label-regular">Backfills</h3>
      <p class="text-caption-regular">Billed per request</p>
    </div>
    <div class="addon-card">
      <span class="material-symbols-outlined addon-icon">verified</span>
      <h3 class="text-label-regular">Certified Transformations</h3>
      <p class="text-caption-regular">
        Leave the transformation logic (and the maintenance) to us
      </p>
    </div>
    <div class="addon-card">
      <span class="material-symbols-outlined addon-icon">support_agent</span>
      <h3 class="text-label-regular">Managed RPC Nodes</h3>
      <p class="text-caption-regular">
        Dedicated, managed RPC nodes for the most demanding use cases
      </p>
    </div>
  </div>
</div>

## FAQ

### What's included in the Starter plan?
The Starter plan costs $10 to start, then $1 per 1,000 transactions processed. It includes access to all 100+ supported networks, real-time delivery to one of three self-serve destinations, shared network compute, and self-serve setup.

### Can I switch plans later?
Yes. You can upgrade from Starter to Advanced or Dedicated at any time. Downgrades are handled through our support team. Annual plans include a 15% discount.

### What counts as a "transaction" for billing?
A transaction is one processed blockchain event that passes through your pipeline. Events that are filtered out before processing are not counted.

### Is there a free trial?
The Starter plan at $10 is the lowest barrier to entry. There is no free tier, but setup takes minutes and you only pay for what you process.

### What's the difference between shared and dedicated infrastructure?
Shared infrastructure runs your pipelines on multi-tenant compute with sub-3-second latency and 99.9% uptime SLA. Dedicated infrastructure gives you isolated compute with sub-500ms latency, 99.99% uptime SLA, and priority support.

<div id="cta">
  <div>
    <h1 class="text-display-regular">Need help finding<br />the right fit?</h1>
    <div class="cta-buttons">
      <a href="/contact">Talk to Sales</a>
    </div>
  </div>
</div>

<script>
  // Pricing toggle functionality
  document.addEventListener("DOMContentLoaded", function () {
    const toggleButtons = document.querySelectorAll(".pricing-toggle-btn");
    const monthlyElements = document.querySelectorAll(".monthly-period");
    const annualElements = document.querySelectorAll(".annual-period");
    const priceValues = document.querySelectorAll(".price-value");

    toggleButtons.forEach((button) => {
      button.addEventListener("click", function () {
        const period = this.dataset.period;

        // Update toggle button states
        toggleButtons.forEach((btn) => btn.classList.remove("active"));
        this.classList.add("active");

        // Update price displays
        priceValues.forEach((el) => {
          const monthlyPrice = el.dataset.monthly;
          const annualPrice = el.dataset.annual;
          if (period === "annual" && annualPrice) {
            el.textContent = annualPrice;
          } else if (period === "monthly" && monthlyPrice) {
            el.textContent = monthlyPrice;
          }
        });

        // Toggle period text visibility
        if (period === "annual") {
          monthlyElements.forEach((el) => (el.style.display = "none"));
          annualElements.forEach((el) => {
            // Check if element is a block-level element (p, div) or inline
            const isBlock = el.tagName === "P" || el.tagName === "DIV";
            el.style.display = isBlock ? "block" : "inline";
          });
        } else {
          monthlyElements.forEach((el) => (el.style.display = "inline"));
          annualElements.forEach((el) => (el.style.display = "none"));
        }
      });
    });

    // Set background images for pricing cards from data attributes
    const pricingCards = document.querySelectorAll(
      ".pricing-card[data-card-image]",
    );
    pricingCards.forEach((card) => {
      const imageUrl = card.getAttribute("data-card-image");
      if (imageUrl) {
        const beforeElement = window.getComputedStyle(card, "::before");
        card.style.setProperty("--card-bg-image", `url(${imageUrl})`);
        // Use a style element or set it directly on the pseudo-element via a class
        const style = document.createElement("style");
        style.textContent = `.pricing-card[data-card-image="${imageUrl}"]::before { background-image: url(${imageUrl}); }`;
        document.head.appendChild(style);
      }
    });
  });
</script>


---
title: Avalanche Indexing with The Neighborhood
url: https://www.indexing.co/articles/avalanche-indexing-with-the-neighborhood
description: How to index Avalanche L1s with The Neighborhood, creating unified pipelines that span multiple chains for real-time and historical data.
date: 2025-09-02
author: Dennis Verstappen
tags: Guide
---

Avalanche is home to a growing set of high-performance L1s, each optimized for its own community and use case. This design opens the door to faster innovation but also creates a challenge: how can builders and product teams access clean, reliable data across all these L1s without maintaining custom infrastructure for each one?

The Indexing Company built **The Neighborhood**, a distributed compute network for high-performance indexing. The Neighborhood can onboard any Avalanche L1 into its network and provide pipelines that span multiple L1s at once. This makes it possible to stream real-time activity from several chains into a single schema, while also running complete historical backfills from genesis.

## Solving the Indexing Problem on Avalanche

Today, many teams rely on brittle systems like subgraphs or centralized APIs. These approaches come with rigid schemas, long reindexing times, and high infrastructure costs. They are especially limiting in a multi-chain ecosystem like Avalanche, where each L1 may introduce its own set of contracts and events.

The Neighborhood removes these bottlenecks. By ingesting raw block data directly from Avalanche RPCs, it lets developers apply programmable transformations in JavaScript and stream structured output into any database, warehouse, or webhook. The result is flexible, chain-aware pipelines that can handle multiple L1s side by side.

## Examples of Avalanche Data You Can Index

Here are some of the datasets teams can build pipelines for today:

- Token transfers: Track ERC20 and stablecoin movements such as AVAX, USDC, and USDT across several Avalanche L1s.

- DEX activity: Capture swaps and liquidity events from protocols including Dexalot, Blackhole, LFJ, and Uniswap deployments.

- Lending and borrowing: Stream deposits, borrows, repayments, and liquidations from Avalanche-native money markets.

- NFT activity: Index NFT transfers, mints, and marketplace events to power dashboards or wallets.

- Wallet-level analytics: Monitor balances, positions, and historical activity for specific addresses.

- Custom contracts: Add your own L1 contracts and decode events specific to your application.

By combining these pipelines, developers can merge data from multiple Avalanche L1s into a single dataset—removing the complexity of stitching together siloed sources.

## Benefits for Builders

**Programmable pipelines**

Developers define what gets indexed, from specific contracts to wallet sets. Pipelines can be adjusted on the fly without costly reindexing.

**Real-time and historical coverage**

Support for both sub-second data streams and full historical backfills ensures complete datasets for analytics, compliance, and research.

**Local indexing options**

Neighborhood nodes can run close to Avalanche validators or inside your own infrastructure, delivering lower latency and giving teams full control over reliability and security.

**Cost and efficiency**

The distributed design of The Neighborhood processes Avalanche workloads more efficiently than centralized cloud systems, reducing costs for data-heavy use cases like DeFi analytics or AI model training.

## Why This Matters for Avalanche

Avalanche’s multi-L1 ecosystem is only going to grow. Without robust indexing, developers risk spending more time maintaining ETL pipelines than building products. The Neighborhood provides a unified data layer that adapts as new L1s launch, allowing product managers to ship faster, CTOs to cut costs, and data engineers to focus on insights instead of infrastructure.

## Getting Started

The Neighborhood already supports Avalanche and its expanding family of L1s. Developers can define pipelines through our console and APIs, stream data into Postgres, BigQuery, Kafka, or webhooks, and build analytics that span multiple chains.
For teams building on Avalanche, The Neighborhood makes it possible to go from raw chain data to production-ready pipelines—whether you’re indexing a single L1 or unifying activity across the entire Avalanche ecosystem.

If your team needs faster, cheaper, and more flexible access to Avalanche and Avalanche L1 data, The Neighborhood is ready to help. Explore our platform at [indexing.co](https://www.indexing.co) or contact us at [hello@indexing.co](mailto:hello@indexing.co) to discuss your data needs.


---
title: Web3 Data is NOT the Problem
url: https://www.indexing.co/articles/web3-data-is-not-the-problem
description: An argument that web3's data accessibility challenges stem from infrastructure problems, not the data itself, and how composable infrastructure solves this.
date: 2023-02-09
image: /assets/articles/web3-data-is-not-the-problem.png
author: Stephen King
tags: Post
---

**Web3 Data is NOT the Problem**

## **An In-depth Look into the World of Web3 Data**

![](https://images.mirror-media.xyz/publication-images/V79JhhmfFQPKa6MDawfAx.png?height=512&width=512)

Welcome to the forefront of the digital revolution. In the world of web3, with its vast data, blockchain networks, protocols, and tokens, accessing and understanding information can be challenging. Developers often build custom solutions due to the lack of accessible options. This piece addresses the infrastructure problem underlying web3 data accessibility, exploring strategies for transformative success. Let's dive in.

**The Challenges of Accessing Web3 Data**

The world of web3 data is vast and ever-growing, but it can be incredibly frustrating to access. With all the different blockchains, protocols, and tokens, navigating and understanding this complex data ecosystem requires an upfront investment of time, patience, and money. The data is raw, unindexed, and brutal to merge with third-party data sets. Dapp providers often find themselves building custom tools over leveraging open source and paid solutions.

The current attempts to address these issues are futile as they focus on treating the symptom instead of the disease.

#### **Identifying the Real Problem**

The data accessibility problem in web3 is not a _data_ problem, it’s an _infrastructure_ problem.

![](https://images.mirror-media.xyz/publication-images/IhxoX--Hd-k1X3s38gebp.png?height=512&width=512)

Now that we’ve properly defined the problem, we can implement a strategy that leads to success.

Throughout the last two years, we used several web3 indexing products. Some, open-source, provided value in the short term. Over time the value was reversed through unannounced deprecated services and the additional resources we invested in making the product work. We later found centralized products that charge for their APIs. It was like having two versions of our town library next to each other. One makes you pay but gives you access to their card catalog. The other is free but requires more than a decade bit more time and creativity to find your book. After a few times navigating and getting comfortable in the free library, there is zero value in paying for admission next door. Like the soon-bankrupt library, companies charging for API access will soon reevaluate their business models.

#### **The Future: An Ecosystem with Free Indexing APIs and Transformers**

As we transition into an ecosystem with free indexing APIs, there is an additional hurdle that needs to be addressed. Simplifying access to indexed data is great but not useful if it's not easily configurable into different forms. Please welcome, transformers.

Transformers transform the raw, indexed data into configurable forms. The result is a composable infrastructure that any individual, company, industry, or government building in web3 can configure to their needs.

Looking at data from a single NFT project via an indexed API can give us insight into transaction data. Who is the largest holder? When did they buy? Where did they buy? Powerful, yes. However, scaling across thousands of transactions or adding web2 data into the model is hard. Transformers give builders the ability to overcome these challenges, create, and provide valuable datasets to their users.

#### **The Promise of Composable Infrastructure**

![](https://images.mirror-media.xyz/publication-images/_2LkbtLN5MPh08DNveaji.png?height=512&width=512)

Leveraging this infrastructure, let's use the Ethereum, Tezos and Polygon NFT Indexers to get a few baseline stats on chain data. Next, we’ll configure the transformer to compare net new purchases from September 2022-December 2022 on Solona, Ethereum and Polygon using wallet addresses.

1. There are over 7.5 million wallets on Ethereum that have ever owned an NFT

2. The average NFT price in 2022 on Ethereum was $343

3. There are 45,000 ERC721 and 30,000 ERC1155 NFT contracts on Ethereum.

4. During 2022, Tezos NFT sales (XTZ) were up 115%

5. NFT Market place volume peaked at 1.7 billion on Ethereum in August 2021

6. NFT wash trading peaked in Jan 2022 on Ethereum with 4.1 billion in wash trades versus 1.1 billion in organic trading volume.

7. From Sept 2022-Dec 2022, new users buying NFTs on Solona dropped 63% and 36% on Ethereum. During that same time, new users buying NFTs on Polygon grew more than 500%.

8. With composable infrastructure, developers reduce superfluous costs and technical debt while providing more value to their users.

9. To realize Web3's goal of surpassing web2, the applications must be significantly superior to their web2 counterparts. Developers require the same, if not better, tools and infrastructure as those available in web2. With seven years of experience building custom data solutions and paying for what should be free, we’ve gone all in on solving web3’s data infrastructure problem.

#### **The Real-World Impact of Configurable Data**

Taking our understanding of configurable infrastructure a step further, we can begin to see its profound implications on real-world blockchain applications. Consider, for example, the way in which DeFi applications can leverage this technology to provide their users with highly personalized and detailed financial metrics. In fact, a study from the[ University of Cambridge](https://www.jbs.cam.ac.uk/faculty-research/centres/alternative-finance/publications/2nd-global-enterprise-blockchain-benchmarking-study/) highlights how adopting a more configurable data approach can lead to enhanced user experiences and improved decision-making capabilities in financial markets.

#### **Looking Ahead: The Future of Web3 Data Infrastructure**

Moving forward, we must remember that the full potential of web3 data will only be unlocked when we prioritize building and maintaining a robust, scalable, and flexible data infrastructure. This sentiment is echoed in a recent report by Deloitte, which emphasizes the crucial role of a strong data infrastructure in harnessing the transformative power of blockchain technology. By fostering an ecosystem of free and efficient indexing APIs, we are setting the stage for digital transformation and a future where web3 data is not only more accessible but also more impactful.

#### **The Best Web3 Indexing Tools for Strategic Advantage**

In today's increasingly decentralized digital landscape, effective web3 indexing tools can provide a strategic edge. These web 3 indexing tools not only provide access to vast amounts of blockchain data, but they also simplify the process of filtering and interpreting this data. Here, we highlight some of the top indexing tools designed to navigate the web3 data universe effectively:

#### **[The Graph](https://thegraph.com/)**

The Graph is a powerful protocol that revolutionizes blockchain by enabling easy access to data through a network of open APIs called subgraphs.

#### **[Covalent](https://www.covalenthq.com/)**

Covalent is a unified API that offers visibility into vast amounts of blockchain data, providing comprehensive insights for web3 strategies the blockchain network.

#### **[Nansen](https://www.nansen.ai/)**

Nansen offers blockchain analytics for Ethereum-based finance protocols, providing insights into DeFi, NFTs, and more. Their sophisticated tools simplify navigation, understanding, and decision-making based on blockchain data.

#### **[QuickNode](https://www.quicknode.com/)**

QuickNode is an exceptional web3 indexing tool that enhances blockchain development efficiency. It offers reliable, fast, and scalable access to indexes, to Ethereum, Bitcoin, and other blockchain networks. With QuickNode, there's no need to run your own nodes, eliminating operational hassle and overhead.

Embracing these innovative web3 indexing tools can help stakeholders derive meaningful insights from blockchain data in real time, fueling informed strategies and decisions in the web3 ecosystem.

#### **Overcoming Challenges in Web3 Data Indexing**

Despite the significant advantages of web3 indexing tools, it's important to acknowledge the challenges that remain. One key hurdle is the sheer volume of blockchain data. As blockchains grow and proliferate, storing, indexing, and querying this data become increasingly resource-intensive. As a result, developing scalable solutions multiple blockchains remains a top priority.

Moreover, issues of data privacy and security in the distributed ledger and web3 space pose significant concerns. Public blockchains are inherently transparent, which may lead to unwanted disclosures of sensitive information. Ensuring the privacy-preserving computation and storage of blockchain data is thus a crucial area of ongoing research and development.

## **Final thoughts**

![](https://images.mirror-media.xyz/publication-images/gUANST_LBs-Ugph9YQfZH.png?height=200&width=200&size=large)

In conclusion, the world of web3 data presents immense opportunities and challenges. While accessing and understanding this vast and complex web of data landscape may seem daunting, solutions offered by indexing companies like "[The Indexing Company](https://www.indexing.co/)" provide a way forward. By simplifying complex data systems and offering tailored indexing tools, businesses can harness the power of web3 data for strategic advantage.

"[The Indexing Company](https://www.indexing.co/)" stands out as a leading provider in this space, offering innovative solutions that enable faster build times, cost savings, and streamlined side chain workflows. Their expertise in web3 data indexing empowers businesses to navigate the intricacies of blockchain networks, protocols, and tokens with ease, unlocking valuable insights and informed decision-making.

For businesses seeking to stay at the forefront of the digital revolution, embracing the capabilities and technologies of "[The Indexing Company](https://www.indexing.co/)" is a call to action. By partnering with them, businesses can simplify their data systems, gain a competitive edge, and unleash the transformative potential of web3 data. Don't miss out on the opportunity to revolutionize your data strategy and drive success in the evolving landscape of web3. Contact "The Indexing Company" today to embark on this journey towards streamlined and impactful web3 data utilization.


---
title: Block by Block with 0xSplits
url: https://www.indexing.co/articles/block-by-block-ep-6-0xsplits
description: Splits is becoming the financial structure for onchain teams, from revenue distribution to treasury operations and yield.
date: 2026-01-21
tags: Podcast, Block by Block
link: https://x.com/indexingco/status/2013910032249676081
---


---
title: Mint to the Future
url: https://www.indexing.co/articles/mint-to-the-future
description: A project that recycles Ethereum-based NFTs and transforms them into new NFTs on the Flow blockchain using AI-generated art.
date: 2023-08-22
image: /assets/articles/mint-to-the-future.png
author: Stephen King
tags: Announcement
---

**Mint to the Future: Breathing New Life into NFTs**

<https://www.flowcapacitor.xyz/>

In the ever-evolving world of Web3, NFTs (Non-Fungible Tokens) have taken center stage. But as with any gold rush, there's an inevitable oversaturation. Many NFTs now sit dormant in digital wallets, their value diminished or even non-existent. This posed a question to our team: How can we breathe new life into these forgotten digital assets?

Enter "Mint to the Future," a project that emerged from our desire to rejuvenate the NFT landscape and introduce users to the Flow blockchain. The concept was simple: a recycle contract that would allow users to repurpose their Ethereum-based NFTs, which had lost their value, and in return, receive brand-new, vibrant NFTs minted on the Flow blockchain.

**The Perfect Blend of Design and Tech**

Our team, a blend of design and technical expertise, was uniquely positioned to bring this vision to life. We weren't just looking to create another NFT platform; we aimed to revolutionize the user experience, making it seamless, enjoyable, and rewarding.

**Why Flow and Cadence?**

Flow, with its robust documentation and user-friendly approach, was a natural choice. We crafted a smart contract using Cadence, Flow's native programming language, ensuring a smooth and secure transition for NFTs from one blockchain to another.

**Sustainability**

Flow’s commitment to energy efficiency and sustainability is admirable. By using a proof-of-stake consensus mechanism, Flow significantly reduces its energy consumption. To put it into perspective, the network’s annual energy usage is astoundingly low at 0.18 GWh. To compare, minting an NFT on Flow requires less energy than making a simple Instagram post, making it a leader in energy efficiency, especially when juxtaposed with other blockchains. This conscious choice not only bolsters the platform's commitment to a greener environment but also empowers users and developers to make an eco-friendly choice.

In the context of “Mint to the Future,” this alignment with sustainability means that while users are rejuvenating their NFTs, they are also actively participating in a greener and more responsible digital ecosystem. The assurance that each NFT minted isn't draining vast amounts of energy or contributing significantly to carbon emissions is invaluable in today's conscientious digital age.

**Embracing AI, a tool that will greatly enhance web3**

The tech world is currently witnessing an AI explosion, but the actual value can be clouded by mainstream headlines. Headlines aside, there are practical things AI excels at, a major one being generative art. We leveraged OpenAI's DALLE via a feature that generates unique NFT images in real-time. The new image is generated by collecting keywords words from the NFT’s being recycled and combining them into a prompt that generates a new image. This not only enhances the user experience but also significantly reduces our design costs. It was a win-win!

A Glimpse into the Future

Imagine a world where your once-forgotten NFTs are given a fresh lease of life. With "Mint to the Future," that's precisely what we offer. As our website aptly puts it, "Help Marty McFlow move to a more decentralized, secure, and innovative future by transforming your old NFTs into something dynamic and new."

We were excited to create Flow to the Future because it shows how AI will impact the web3 ecosystem while also demonstrating new and creative user onboarding tools.

By combining strengths from [Wovn](https://www.wovn.xyz/) & [Indexing Co](https://indexing.co), we were able to design and deploy the app in about a month. We had a great experience learning about and building in the Flow ecosystem. Overall, the Flow ecosystem was the perfect choice for Mint to the Future and we’re excited follow its continued growth & success!


---
title: Network Update: Hyperliquid, SUI, MegaETH and more
url: https://www.indexing.co/articles/network-update-hyperliquid-sui-megaeth-and-more
description: Indexing Co adds support for 11 new networks including Hyperliquid, SUI, MegaETH, and 8 more chains.
author: Jake Horn
date: 2025-04-01
image: /assets/articles/network-update-hyperliquid-sui-megaeth-and-more.avif
tags: Announcement
---

Indexing Co now supports 11 new networks, bringing our total to 100+ chains. The additions include high-demand networks that our customers have been requesting:

- **Hyperliquid** -- the fastest-growing perpetuals DEX, processing billions in daily volume
- **SUI** -- Move-based L1 with object-centric data model
- **MegaETH** -- real-time EVM chain targeting sub-millisecond block times

Plus 8 additional chains. Each network gets full indexing support: real-time event streaming, historical backfills, and webhook delivery.

[View the complete list of supported networks](https://docs.indexing.co/networks)


---
title: Devcon VI and the State of EVM Data
url: https://www.indexing.co/articles/devcon-vi-and-the-state-of-evm-data
description: Reflections on Devcon VI and the state of EVM data, covering EIPs 4488, 4444, and 3668 and their implications for Ethereum's future.
date: 2022-10-21
image: /assets/articles/devcon-vi-and-the-state-of-evm-data.jpg
author: runninyeti.eth
tags: Post
---

By all measures, Devcon VI was a huge success. Over 6000 participants from around the world met in Bogota, Colombia to build, network, and celebrate together in _the_ official Ethereum conference.

This is coming about a month after The Merge in which Ethereum switched from Proof of Work (PoW) to Proof of Stake (PoS). That transition worked far better than any could have hoped and has lead to ETH even being deflationary at times 🔥

![https://ultrasound.money/](https://images.mirror-media.xyz/publication-images/vM0lJq0K4AcSfcqTz_yT0.png?height=720&width=1180)

So what’s next for Ethereum and its ecosystem? In short, far too much is happening to cover in a single post, but we’re going to touch on “the state of data”.

## Today

Let’s take a step back and remember how we got to today. Ethereum launched in 2015 with a vision of being the world’s computer. At its core, Ethereum processes transactions in its Ethereum Virtual Machine (EVM) and reaches consensus with its nodes (network of servers). In order to do this, each node in the ecosystem must keep track of a history of _all_ blocks and transactions that have ever existed.

Fast forward to today, there are well over 15 million blocks and over 1 billion transactions on the Ethereum mainnet. And these numbers don’t even reflect the growing ecosystem of secondary blockchains on and around Ethereum such as Polygon, Optimism, Arbitrum, Starknet, etc. Point being, there’s a lot of data out there and it’s only continuing to grow.

In order for Ethereum, and its ecosystem, to truly reach “internet scale”, we need to drastically increase adoption. That adoption, though, inevitably comes with a sharp increase in data and we need to be ready for this.

![https://a16zcrypto.com/state-of-crypto-report-a16z-2022/](https://images.mirror-media.xyz/publication-images/pX3soQBZf8TaKYGhRH96V.png?height=1163&width=2048)

#### Today’s Problems

Focusing primarily on solving for adoption, some of the common themes in Ethereum today are:

1. Too few transactions per second - not enough support for simultaneous users

2. Too few \[independent\] node operators - not enough decentralization

3. On-chain storage is expensive - and standards are missing for off-chain

## Looking Forward

Thankfully, the sharp minds of the industry have already been working on solutions; many of which should be rolling out in the coming months and years. Let’s dig into a few of these Ethereum Improvement Proposals (EIPs):

**EIP-4488: Working on Throughput**

<https://eips.ethereum.org/EIPS/eip-4488>

The leading way to increase throughput on Ethereum is simply to move transactions _off_ of Ethereum. This may sound counter-intuitive, but bear with me.

Layer 2’s such as Optimism and Arbitrum offer developers and consumers lower gas fees, fast transaction times, and the full security of the Ethereum blockchain itself. How? By allowing transactions to use their own set of nodes, entirely independent of Ethereum, and then adding _proof_ of those transactions to the Ethereum. Effectively, Layer 2’s keep their data self-contained except for the proof that something has happened (this is all a rough approximation, but close enough for our purposes here).

Circling back to EIP-4488, these Layer 2s frequently leverage what’s known as `calldata` to batch add these proofs to Ethereum. `calldata` is a specific type of data in the EVM that’s particularly cheap. That being said, if we’re hoping to reach internet scale, paying [$0.30+](https://public-grafana.optimism.io/d/9hkhMxn7z/public-dashboard?orgId=1&refresh=5m&from=now-90d&to=now) for something as simple as transferring ETH is still too much. EIP-4488 introduces an explicitly lower cost for `calldata` on Ethereum, which will decrease the cost of Layer 2s, and ultimately save users money.

**EIP-4444: Everyone Gets a Node**

<https://eips.ethereum.org/EIPS/eip-4444>

The biggest problem with running your own Ethereum node at home generally isn’t the technical complexity involved. The terminal commands are simple and there are even products like [Dappnode](https://www.dappnode.io/en-us) offer plug’n’play ease. What gets tricky to solve for though is the sheer amount of storage costs you need to run a node. Each node must remember the entire history of the Ethereum blockchain. The storage requirements for that currently sit at \~1 TB and are closer to 6 TBs if you want to run what’s known as an “archive” node. And with proposals like EIP-4488 above, the size requirements are likely to increase even quicker (up to 3 TB _per year_ in the extreme case).

EIP-4444 aims to address this by introducing a prune limit on historical data. Ethereum nodes would no longer have to remember the _entire_ history of the blockchain. Instead, they can keep only the last year of data. This makes running Ethereum nodes at home considerably less resource intensive. And, importantly, more nodes directly translates into better decentralization for Ethereum as a whole.

If you’re like us, you’re probably wondering where all that old data is going to be stored? That is a fantastic question without an answer unfortunately. There seems to be consensus around some ideas though:

- Have a separate “historical” node that people can choose to run

- Introduce a P2P protocol for downloading past data (remember the BitTorrent days?)

- Rely on centralized authorities to remember all past data - and make it available to the rest of us (likely for a fee…)

In any case, more nodes and more decentralization is a net positive for the ecosystem. With time we’ll find an appropriate solution to accessing historical data.

**EIP-3668: Accessing Off-Chain Data**

<https://eips.ethereum.org/EIPS/eip-3668>

Spearheaded by [ENS](https://ens.domains/) and [Chainlink](https://chain.link/), EIP-3668 introduces a standard for Ethereum developers to securely incorporate off-chain data into the ecosystem. This is a potentially _huge_ win for everyone. Ethereum is meant to the world’s computer and it makes sense that we’d want the ability to “plug-in” an external hard-drive to that. This is roughly what the Cross-Chain Interoperability Protocol (CCIP) introduces.

CCIP works by allowing a smart contract to say “I don’t have the data, but I can verify it from Source X”. A client (e.g. browser) asking that contract for data can then reach out to Source X, receive raw data, and offer it back to the contract to verify. In this way, the data is _safe_ to use (because it’s validated by the contract), but also cheap to store + access because it’s _not_ stored on-chain. Even better, Source X could be anything - another blockchain, an API gateway, etc - CCIP simply provides us with a standard way of implementing this sort of off-Ethereum communication.

Early concepts around CCIP are promising. Chainlink and SWIFT [are partnering](https://chainlinktoday.com/chainlink-and-swift-announce-ccip-proof-of-concept-at-smartcon-2022/) on a way to bridge the web2 banking world with web3. ENS is expanding beyond primarily `.eth` to support any domain, on any chain; [Coinbase has already implemented this](https://help.coinbase.com/en/wallet/managing-account/coinbase-ens-support).

![Devcon IV](https://images.mirror-media.xyz/publication-images/JmLvtWs3LZ6b3Pr2KBVcE.jpg?height=3072&width=4080)

In the end, growing pains are a great sign for the Ethereum ecosystem and the future looks bright 🌕 See you all at the next Devcon!


---
title: ENS: A Practical Guide
url: https://www.indexing.co/articles/ens-a-practical-guide
description: A comprehensive guide to Ethereum Name Service, covering how to buy, set up, and use ENS names for both users and developers.
date: 2022-09-23
image: /assets/articles/ens-a-practical-guide.png
author: runninyeti
tags: Guide
---

So you’ve made it to this site and this particular blog post. Great! But do you know _how_ you actually got here?

_(For those wanting to dive in, feel free to scroll past this to “The DIY Section” below)_

The internet today (web2) works, and more importantly gained adoption, in part thanks to the magical world of the Domain Name System (DNS for short). At the highest level, DNS effectively allows users of web2 to say “I want to visit [longdogechallenge.com](https://longdogechallenge.com/)” and reliably be taken to the content (website) that lives there. Let’s break down how that works a bit:

1. A user enters the domain name, `longdogechallenge.com`, in their browser’s address bar

2. A _DNS lookup_ occurs to resolve that domain name to a server’s IP address (an Internet Protocol address is a way to uniquely identify every device on the internet)

3. The browser is given the IP address for the requested domain name and asks the server behind that IP address for content

4. The server returns the content and the browser renders that to the end user (aka the resulting website)

_(The above is admittedly a major simplification of DNS, and for those wishing to dive deeper, [Cloudflare has a great technical write up](https://www.cloudflare.com/learning/dns/what-is-dns/))_

For our purposes though, the general idea is that users of web2 can use DNS to get content behind an IP address while only knowing a domain name. This abstraction is enormously powerful. For starters, IP addresses are _not_ easy to remember - the “common” IPv4 format looks something like `192.168.1.1` and the newer IPv6 format, `2001:0db8:85a3:0000:0000:8a2e:0370:7334`, certainly isn’t any easier. IP addresses are designed for uniquely identifying the billions of internet devices and facilitating communication between _them_; not with humans. And of equal importance, because humans are accessing content via domain names, the server providing that content can be swapped out simply by changing which IP address a domain name points to.

#### Okay, but what does this have to do with web3?

Allowing mere humans to remember just `google.com` instead of `142.250.113.102` was a massive accessibility win for web2. The Ethereum Name System, ENS, provides a similar system for the Ethereum ecosystem. And while Ethereum is of course _not_ equivalent to all of web3, it does represent a large portion of the current web3 user base in some capacity (even if you aren’t directly using Ethereum, many protocols and services are built atop the same basic technologies - more on that another time).

ENS, in short, allows a web3 user to say “I want to send funds to alice.eth” without actually knowing the wallet address behind `alice.eth`.

## The DIY Section

Alright, we’ve covered what ENS is and why you should have one. Now let’s dig into how to acquire and use ENS; for both web3 users and developers.

#### For Users

Go buy an ENS! Seriously, go right now and buy one if you haven’t already. Some steps to get you started:

**Setup your wallet**

If you haven’t already, make sure you have a web3 wallet. [MetaMask](https://metamask.io/) is a great place to get started if you haven’t already joined web3.

From there, make sure you have “some” Ethereum in your wallet. A quarter (0.25) ETH should be plenty to get started (unless you’re trying to get a [highly prized ENS](https://espressoinsight.com/2022/05/15/most-expensive-ens-sales-ever/)). If you don’t have any ETH yet, look towards exchanges like [Coinbase](https://www.coinbase.com/) to get you started.

**Buy an ENS**

Visit a site like [https://app.ens.domains](https://app.ens.domains/) to look up names you’re interested in. There’s no wrong answer here - it’s a lot like choosing an email or a Twitter handle. If your name is available, then great! Follow the registration process (yes, this will involve 2 transactions) and secure your shiny new ENS.

If the name you like is already registered, then you have a few options for purchasing it on the “secondary markets”. ENS, at least in part, is officially a standard NFT collection. That means you can use your favorite NFT marketplaces to trade registered ENS items. Some options in no particular order:

- <https://opensea.io/>

- <https://nft.coinbase.com/>

- <https://www.ens.vision/>

**Tie your ENS to your wallet address**

This is the important piece. Now that you own your ENS, you need to make sure that it’s setup to point to your wallet address. There are two different pieces to this. Go back to <https://app.ens.domains/> once again and click “My Account” in the upper right-hand corner and then do the following:

**Define the ENS => wallet address lookup** -- Select the ENS you just purchased and set the “Record” for “ETH” address to your wallet address. During this step, feel free to set as many of the other text records you see there as you want - this is all part of your new web3 profile.

![Setting ENS records](https://images.mirror-media.xyz/publication-images/ddserphWtEKHUx3K9ZIMs.png?height=2062&width=3150)

**Define the wallet address => ENS reverse lookup** -- Go back to your “My Account” page and you’ll have an option to select your “Primary ENS Name”. Submit the corresponding transaction to make it permanent 🔥

![Setting a Primary ENS Name](https://images.mirror-media.xyz/publication-images/7zElgz3C7-UA7Er-8X4UH.png?height=1690&width=3150)

_NOTE: Both of the above steps will also require submitting Ethereum transactions and paying a small amount of ETH in “gas”. This is to pay the network to store the new data you just added._

And just like that, you’ll now have an official, named identity in web3 🎉 A simple way you can try it out is by looking up your name or wallet address on [Etherscan](https://etherscan.io/) and seeing that the two are linked in the results.

**BONUS: Add an NFT as your avatar**

Thanks to the wonderful world of web3, you can also link pieces of decentralized data together. Specifically in this case, you can say that the photo for your shiny new ENS name should be another NFT that you own. For instance, the avatar field for runninyeti.eth is set to `` `eip155:1/erc1155:0x495f947276749ce646f68ac8c248420045cb7b5e/87433597745683365960201176492736871205018189775129059226749288698845216112641` `` which points to this lovely image:

![](https://lh3.googleusercontent.com/6Jd7V99bdOdRlUOQ-9V44oYfoRVGU3OMnsbzG6uxWQ1nWX2naO-OheqJwEFJBb9FbVqUziaebWMm6cq9iq4GUN5zXZZJtUrHMP8vkA)

For a good overview of how to do this, check out [this post](https://medium.com/the-ethereum-name-service/step-by-step-guide-to-setting-an-nft-as-your-ens-profile-avatar-3562d39567fc) by the ENS team.

#### For Developers

Also go buy an ENS! For yourself, for your project, whatever it might be, just start participating. See the “For Users” section above and follow along.

Now that that’s done, here’s some how-to’s for adding ENS functionality to your projects. We’re going to focus on using [web3.js](https://www.npmjs.com/package/web3) since it’s usable on both frontend and backend codebases, but these same principles can be used with any language.

We’re also going to focus on some of the low-hanging fruit based on what is available to the developer community _today_, but we encourage everyone to go far beyond this (e.g. “ENS Profiles” or [deploying ENS on a private chain](https://docs.ens.domains/deploying-ens-on-a-private-chain)). There are also existing packages to obfuscate working with ENS (mainly JavaScript based, like [ensjs](https://www.npmjs.com/package/@ensdomains/ensjs)), but for this post we’ll be looking at how we can do it ourselves and handle all data directly.

**Look up the current owner of an ENS**

_tl;dr - ask the NFT contract for ENS who the current owner is_

We’ll start with an easy one. To grab the address of the current owner of a given ENS name:

1. Define a web3.js contract instance with the `ownerOf` [ABI input](https://docs.openzeppelin.com/contracts/2.x/api/token/erc721#IERC721-ownerOf-uint256-)

2. Convert the `name` to a `tokenId`

3. Ask the contract who owns that `tokenId`

```
async function getOwnerAddressForENSName(name) {
  // do a basic null check
  if (!name) {
    return null;
  }

  // define a new contract instance for ENS NFTs
  const nftContract = new web3.eth.Contract(
    [
      {
        inputs: [{ internalType: 'uint256', name: 'tokenId', type: 'uint256' }],
        name: 'ownerOf',
        outputs: [{ internalType: 'address', name: '', type: 'address' }],
        stateMutability: 'view',
        type: 'function',
      },
    ],
    ENS_NFT_ADDRESS
  );

  // convert the name to a tokenId
  const tokenId = new BigNumber(Web3.utils.sha3(name.replace(/\.eth$/, ''))).toString();

  // ask the contract for the current owner and return the result
  return nftContract.methods
    .ownerOf(tokenId)
    .call()
    .catch(() => null);
}
```

**Swap ENS names for wallet addresses**

_tl;dr - ask the ENS resolver for the address of a given ENS name_

Let’s kick things up a notch. In order to get the resolved address for a given ENS name, we’ll need a few things:

1. First we want to define a contract instance for the ENS resolver with the `addr` [method](https://docs.ens.domains/ens-improvement-proposals/ensip-9-multichain-address-resolution). The current contract address is `0x4976fb03C32e5B8cfe2b6cCB31c09Ba78EBaBa41`

2. We then leverage the `namehash`[ algorithm](https://docs.ens.domains/ens-improvement-proposals/ensip-1-ens#namehash-algorithm) to convert the given `name` to a sha3 `node`

3. Ask the contract for the current `addr` value of the given `node`

```
async function getAddressFromENSName(name) {
  // some basic validity checks
  // @NOTE: non .eth names are valid, but may require a different resolver contract address
  if (!name || !name.endsWith('.eth')) {
    return null;
  }

  // define a new contract instance for our ENS resolver
  const resolverContract = new web3.eth.Contract(
    [
      {
        constant: true,
        inputs: [{ internalType: 'bytes32', name: 'node', type: 'bytes32' }],
        name: 'addr',
        outputs: [{ internalType: 'address', name: '', type: 'address' }],
        payable: false,
        stateMutability: 'view',
        type: 'function',
      },
    ],
    ENS_RESOLVER_ADDRESS
  );

  // convert our name to a node hash
  const node = namehash(name);

  // ask the contract for the current address and return the result
  return resolverContract.methods
    .addr(node)
    .call()
    .catch(() => null);
}
```

**Swap wallet addresses for ENS names**

_tl;dr - ask the ENS reverse resolver for the ENS name of a given address; double check against the name => address method above_

A final example here, getting the ENS name for a given wallet address is almost identical to the other two methods above:

1. Again, start by defining a new contract instance for the ENS reverse resolver with the `getNames` [method](https://docs.ens.domains/ens-improvement-proposals/ensip-3-reverse-resolution). The current contract address is `0x3671aE578E63FdF66ad4F3E12CC0c0d71Ac7510C`

2. Ask the contract for the name that corresponds to our given address

3. Double check that the name => address mapping matches. While this step isn’t _necessary_, it’s best practice to ensure no one is manipulating the reverse resolver - more info [from ENS here](https://docs.ens.domains/dapp-developer-guide/resolving-names#reverse-resolution)

```
async function getENSNameFromAddress(address) {
  // some basic validity checks
  if (!address || address.length !== 42) {
    return null;
  }

  // make sure our address is the checksum version
  address = Web3.utils.toChecksumAddress(address);

  // define a new contract instance for our ENS reverse resolver
  const reverseResolverContract = new web3.eth.Contract(
    [
      {
        inputs: [{ internalType: 'address[]', name: 'addresses', type: 'address[]' }],
        name: 'getNames',
        outputs: [{ internalType: 'string[]', name: 'r', type: 'string[]' }],
        stateMutability: 'view',
        type: 'function',
      },
    ],
    ENS_REVERSE_RESOLVER_ADDRESS
  );

  // ask the contract for the name that maps from the address
  // @NOTE: you can pass multiple addresses in a single call with this method
  const [name] = await reverseResolverContract.methods
    .getNames([address])
    .call()
    .catch(() => []);

  // @NOTE: ideally we double check that the reverse resolver is correct
  //        this can be done by comparing against the name => address mapping
  if (address !== (await getAddressFromENSName(name))) {
    return null;
  }

  return name;
}
```

#### Wrapping up

There you have it, that’s a quick run down on working with ENS! Both as a web3 user and as a developer in the space. For deeper dives, definitely check out the official [ENS documentation](https://docs.ens.domains/dapp-developer-guide/ens-enabling-your-dapp) and feel free to explore the code from this post on [Github](https://gist.github.com/brock-haugen/e2fe9920b9d2069912b77fe5f0826733). And please reach out if you find this post interesting or just want to chat more about ENS, indexing, and Data 3.0.

![](https://media.giphy.com/media/KctrWMQ7u9D2du0YmD/giphy.gif)


---
title: Data Pipelines for Prediction Markets
url: https://www.indexing.co/articles/data-pipelines-for-prediction-markets
description: A guide to indexing EVM-compatible chains with The Neighborhood, enabling unified data pipelines across Ethereum, Base, Arbitrum, and more.
date: 2025-11-13
author: Dennis Verstappen
tags: Guide
---

#### Indexing Co powers real-time, high-precision data for prediction markets.

Prediction markets depend on perfect information. Whether you’re building something like Polymarket or Kalshi, running your own onchain venue, arbitraging markets across chains, or integrating external prediction feeds into an analytics product, the foundation is always the same: fast, clean, reliable data.
Indexing Co delivers that data layer. Built on **The Neighborhood**, our distributed compute network, we index onchain and offchain market events with sub-second latency across 125+ chains. We stream liquidity changes, order flow, collateral movements, token transfers, settlement events, and user activity directly into your backend, dashboards, agents, or pricing models.

Why it matters for prediction markets:

#### Trading and Arbitrage

Latency determines edge. Firms running cross-market or cross-chain arbitrage need deterministic, high-speed indexing that doesn’t degrade when markets spike. Our dedicated Neighborhood nodes colocate with RPCs or validators to deliver the fastest possible feed. This setup is outperforming standard indexers or Subgraphs..

#### Your Own Prediction Market

If you're launching a new venue, you need more than block data. You need decoded events, stablecoin flows, oracle updates, and settlement logic delivered exactly as you define it. Our pipelines give you full control over transformations and schema, so you can design the mechanics of your market instead of fighting data infra.

#### Analytics & Insights Products

If you’re building dashboards, forecasting tools, or modeling engines, you need structured, query-ready data without ETL overhead. We transform raw network activity into clean streams you can plug directly into your warehouse, AI system, or API.

#### Integrating External Markets

Aggregators and research platforms that want to pull in Polymarket, Kalshi, or chain-native markets can unify everything through a single pipeline. Mix offchain APIs with onchain settlement and liquidity data in one transformation layer.
Prediction markets thrive on clarity, speed, and truth. Indexing Co gives you all three with enterprise-grade reliability, customizable pipelines, and nodes tuned for sub-second performance.
If you're building trading systems, arbitrage bots, new markets, or analytics on top of prediction-market data, we can power the full stack end-to-end. Reach out to us at [mailto:hello@indexing.co](hello@indexing.co) for your custom setup.


---
title: Farcaster Data
url: https://www.indexing.co/articles/farcaster-data
description: Indexing Co integrates Farcaster into its indexing pipelines, offering free public access to casts, profiles, reactions, and verifications data.
date: 2024-02-23
image: /assets/articles/farcaster-data.png
author: Stephen King
tags: Announcement
---

Farcaster, a Web3 social protocol, has seen a surge in user engagement since launching Frames. From 3,000 daily users in late January to nearly 370k users today, with daily "casts" jumping from 200,000 to 2.9 million. This impressive growth offers valuable insights into where social media is going.

Farcaster's architecture is a blend of on-chain and off-chain systems, which includes registry contracts deployed on the Ethereum network via Optimism. Messages are cast to a network of servers called 'Hubs', ensuring the reliability of user data. This hybrid architecture is spurring some innovative ideas like Frames. Frames allow developers to embed interactive experiences within Farcaster posts, known as Casts. There are [fun and different](https://topframes.xyz/) frames being created, including one for Girl Scout cookies. This allows you to shop within the Frame and then checkout via Coinbase without ever leaving Warpcast.

[Of course we had to create our own frame : )](https://warpcast.com/runninyeti.eth/0xefcbfecd)

![](https://images.mirror-media.xyz/publication-images/z4Iy44rNwWTrDblWT_knw.png?height=812&width=1202)

We’re committed to the Farcaster ecosystem and are excited about its potential. We integrated Farcaster into our indexing pipelines, positioning it alongside prominent chains like Base, Syndicate, and Solana. We're proud to offer this dataset entirely free as a public good, fueled by our passion for easy and open access to data.

Our approach with this dataset has been to take a semi-opinionated stance on normalizing hub events into views that more easily work for products and analytics (e.g. "user_data" from Hubs maps to "profiles" in BigQuery).

To start, we have 5 tables available: casts, links, reactions, verifications, and profiles.

> #### Looking where to start? Try seeing who the most [active reply guys are](https://console.cloud.google.com/bigquery?sq=867429816176:87fef9a0cc334c199363075701d50e74).

Currently, [BigQuery](https://console.cloud.google.com/bigquery?project=glossy-odyssey-366820&ws=!1m4!1m3!3m2!1sglossy-odyssey-366820!2sfarcaster) is updated every hour with the latest snapshot of data. Depending on feedback, we'll likely try to make this truly real-time using some materialized views.

A huge shout out and thanks to @pinatacloud for their public hub support!

Looking where to start? Try seeing who the most [active reply guys are](https://console.cloud.google.com/bigquery?sq=867429816176:87fef9a0cc334c199363075701d50e74).

If you have questions or other data needs, contact us!

Warpcast: [Indexing Co](https://warpcast.com/~/channel/indexing) - [Brock](https://warpcast.com/runninyeti.eth) - [Stephen](https://warpcast.com/stephenking)

Email: [hello@indexing.co](hello@indexing.co)


---
title: BitCourier - Indexing Co: Addressing Challenges in The On-chain Data Space
url: https://www.indexing.co/articles/bitcourier-indexing-co-addressing-challenges-in-the-on-chain-data-space
description: BitCourier's review of Indexing Co and how it addresses challenges in the on-chain data space.
author: BitCourier
date: 2025-09-28
image: /assets/articles/bitcourier.avif
tags: Social
link: https://bitcourier.co.uk/blog/indexing-co-review
---


---
title: Accessing Data 3.0: Indexing 101
url: https://www.indexing.co/articles/accessing-data-3-0-indexing-101
description: An introduction to indexing in web3, explaining what indexing is, why it matters, and how it enables access to decentralized data.
date: 2022-09-14
image: /assets/articles/accessing-data-3-0-indexing-101.png
author: runninyeti
tags: Post
---

_This is an entry in our long running series, “Accessing Data 3.0”, where we talk about the “whats” and the “hows” of working with data in web3. Enjoy!_

Remember libraries? The walls of books and the fearless librarians somehow always knowing exactly where everything is. Well, two things: 1) libraries still exist, 2) those libraries are each _indexed_. Librarians around the world categorize all of the books under their purview into what are known as a “[library catalogs](https://en.wikipedia.org/wiki/Library_catalog)”. These catalogs serve as a means of quickly finding books by given keywords: genres, authors, titles, etc.

The internet works in much the same way. There are [billions of websites](https://www.internetlivestats.com/total-number-of-websites/) on the internet (our books in the example above) and each contains some amount of content. In order to find anything online we ask our almighty catalogs for direction - we “Google” a question or search someone’s name on Facebook. And for any of that to be possible, our trusted librarians (Google, Facebook, etc) had to first sort through the sea of content, categorize it, and then build intelligent indexes (catalogs). Now when you [search “weather today”](https://www.google.com/search?q=weather+today), Google is aware of sites that are relevant to the keyword “weather” and presents those. Of course, Google is also aware of your physical location, today’s date, your previous search history, and which website is paying the most to be matched on the keyword “weather” … but we’ll leave the darker details of the indexing industry for another day.

The point is, **indexing is everywhere** - a book’s table of contents, your phone’s set of contacts, the grocery list pinned to the fridge … you get the gist. Any time a given data set is too large to be easily consumed, indexing of some sort is employed to aid in its digestion.

Let’s refocus with some definitions:

1. [Data](https://www.dictionary.com/browse/data): bits of information

2. [Decentralization](https://en.wikipedia.org/wiki/Decentralization): the distribution of control and ownership away from a central authority

3. [Index](https://www.dictionary.com/browse/index): a catalog to help find data more quickly

4. [Web3](https://www.dictionary.com/e/web3/): the decentralized web; empowering individuals to _own_ their data

From the above we can surmise that “**indexing**”, as it relates to web3, **is the act of cataloging decentralized information**. Simple as that.

Generally speaking, indexing, in all scenarios, is done to make data more easily searched, and therefore to make that data more accessible. When the data itself is _decentralized_ though, it opens the door to entirely new models of indexing. Take for instance the basic flow of indexed data in web2:

![Web2 Data Indexing](https://images.mirror-media.xyz/publication-images/XKzIQY6AIgSau6X4CZCew.png?height=429&width=1302)

In the current, web2 world, centralized authorities **control** the flow of data. They are responsible for discovering, aggregating, indexing, and ultimately serving data. When a user performs a “search” for instance, Google chooses which information is relevant and provides it back to the end user. Historically this has been “okay”, but when those centralized authorities start to [drop their “don’t be evil” mottos](https://gizmodo.com/google-removes-nearly-all-mentions-of-dont-be-evil-from-1826153393), it’s worth pausing to rethink this centralized model.

Enter the world of web3 and decentralized data:

![Web3 Data Indexing](https://images.mirror-media.xyz/publication-images/mxrT-BhVsto3TBcKTakNA.png?height=959&width=1790)

There’s two important pieces to call out in this web3 scenario:

1. Users are adding their data directly to decentralized networks (Ethereum, IPFS, Arweave, etc)

2. Because these networks are decentralized, _anybody_ can go through and index the data

That second point has some significant ramifications. For starters, that means that the individual user, whether that’s a single human or a company, can ultimately index and access their own data directly from the network; no middlemen deciding what information is “right”. Furthermore, this model doesn’t stop centralized authorities from _also_ indexing that data and providing it to users - and that’s also good!

By enabling open data access, decentralized networks effectively create an incentive strategy for truly providing what’s best for the _users._ Because the centralized authorities no longer control the influx of data, they must cater to the needs of their users. Otherwise, a new competitor will come along to meet those needs. And, the best part of all of this is, that new competitor could simply be the users themselves.

Although this access isn’t always _simple_ today in many decentralized networks, the barriers to entry are lowering and the potential continues to increase. For those interested in following along, this series on “Accessing Data 3.0” will dive deeper into the various aspects of data in web3 and how we can all start participating in it.


---
title: BlockPI × Indexing Co: A New Era for Onchain Data
url: https://www.indexing.co/articles/blockpi-indexing-co-partnership
description: BlockPI and Indexing Co have formed a strategic partnership to deliver real-time, high-performance onchain data on dedicated node infrastructure.
date: 2026-04-21
tags: Partnership
link: https://x.com/RealBlockPI/status/2046463203262206189
---


---
title: Block by Block Ep. 8 – Agentic Coding and the Future of Data Integration
url: https://www.indexing.co/articles/block-by-block-ep-8-agentic-coding-and-the-future-of-data-integration
description: Block by Block podcast episode with Brock Haugen (Indexing Co).
author: Dennis
date: 2026-04-02
image: https://dbffdfcgucdezodnkido.supabase.co/storage/v1/object/public/content-images/fb64d288-b6a6-43ad-b6ca-990378fe7353/c510f4f7-59ca-4ac1-a383-caab6b5ecef5.png
tags: Podcast, Block by Block
---

AI agents are changing how developers build, deploy, and interact with data infrastructure. In this episode, Dennis and Brock explore the practical impact of agentic coding on crypto data pipelines, business workflows, and the future of software development. From automating complex blockchain integrations to rethinking how companies serve both human users and AI agents, they break down what's real, what's hype, and where the industry is headed.

**Topics covered:**

- How AI agents are transforming developer onboarding and data pipeline creation
- Using Claude's MCP and skills to automate blockchain data collection and analysis
- Why data silos will break apart as agents demand better API access
- The survival test for SaaS companies in an AI-first world
- Building collective business memory with AI while preserving tribal knowledge
- Security, control, and enterprise adoption challenges for autonomous agents
- Why crypto rails are positioned to power AI-to-AI payments
- The real gap between AI technology and mainstream adoption

**Guest:** Brock Haugen (@runninyeti), CEO at Indexing Co (@indexingco)

**Host:** Dennis Verstappen (@ape_rture), Indexing Co

### Guest + Links
- [Guest X](https://x.com/runninyeti)
- [MCP installation](https://www.indexing.co/articles/indexing-co-mcp)
- [Company X](https://x.com/indexingco)
Company Website: www.indexing.co

### Hosted by The Indexing Company
- [Dennis](https://x.com/ape_rture)
- [Website](https://indexing.co)
- [Docs](https://docs.indexing.co)
- [X](https://x.com/indexingco)

---

## Listen & Watch
- [Watch on YouTube](https://youtu.be/fBbiiXn6D0c)
- [Listen on Spotify](https://open.spotify.com/episode/0oDU8uYTMXkluIjGYiDl01?si=rVOvSM1cQUC5sNca6TbRpQ)


---
title: Introducing: Mirror Mirror
url: https://www.indexing.co/articles/introducing-mirror-mirror
description: A free search engine for Mirror.xyz content, indexing all posts stored on Arweave to enable discovery across the decentralized publishing platform.
date: 2022-11-07
image: /assets/articles/introducing-mirror-mirror.png
author: runninyeti.eth
tags: Announcement
---

Hot of the presses - we’re happy to present the latest free service from The Indexing Company, [Mirror Mirror](https://www.mirrormirror.page/) 🎊

![searching the important topics of today](https://images.mirror-media.xyz/publication-images/YdB8DNV6ObJNpbKrg_TJ_.png?height=2474&width=3824)

In short, this is a search engine for [Mirror.xyz](https://mirror.xyz/). For those that don’t know, Mirror is a web3 publishing platform akin to [Medium](https://medium.com/) in the web2 world. Unlike Medium though, Mirror is merely an interface to help writers put their content out into Data 3.0. That is, everything written on Mirror is ultimately stored on [Arweave](https://www.arweave.org/).

_(For those curious, we spoke in more depth on Data 3.0 storage options like Arweave [here](https://blog.indexing.co/articles/FDyv8i8c15ATs_KIpAtEdeMP20WZ00FfssPYOj3EZRY))_

This intentional decentralization of data has important implications:

1. Writers _own_ their own data - only they can add, modify, and sign their data

2. Mirror does _not_ control the data - theoretically someone else could come along and build a competitor to Mirror, leveraging the exact same underlying data source

3. All of the posts from Mirror are publicly available, forever thanks to Arweave

And we at Indexing Co have been able to leverage the 3rd point there to successfully index every Mirror post written - i.e. creating a “mirror” of Mirror if you will 😎 And now that we’ve got a running index of posts ([here’s the skinny on how that’s done](https://blog.indexing.co/articles/FDyv8i8c15ATs_KIpAtEdeMP20WZ00FfssPYOj3EZRY)), we can expose them via an API and ultimately create the simple UI that you see today.

<https://www.mirrormirror.page/>

Let us know what you think!


---
title: Indexing EVM Chains with The Neighborhood
url: https://www.indexing.co/articles/indexing-evm-chains-with-the-neighborhood
description: A guide to indexing EVM-compatible chains with The Neighborhood, enabling unified data pipelines across Ethereum, Base, Arbitrum, and more.
date: 2025-09-02
author: Dennis Verstappen
tags: Guide
---

Ethereum and its expanding family of EVM-compatible chains have become the backbone of Web3. From Ethereum Mainnet to Base, Arbitrum, Optimism, Polygon, Avalanche, and many others, each chain carries its own developer community and data-rich ecosystem. For product teams and data engineers, this growth means one thing: **how do you reliably index and unify data across all these chains without the burden of maintaining custom infrastructure for each one?**

The Indexing Company built **The Neighborhood**, a distributed compute network for high-performance indexing. It supports all major EVM chains today and makes it possible to create pipelines that span multiple chains, combining real-time streams and historical backfills into one coherent dataset.

## Why Indexing EVM Chains Is Hard

EVM chains share the same virtual machine, but in practice they differ in RPC implementations, throughput, and ecosystem activity. Data engineers often face:
Fragmented datasets across multiple RPCs and providers

- High costs of running custom indexers for every chain

- Rigid APIs or subgraphs that require reindexing when contracts change

- Latency issues for applications that need real-time data

The Neighborhood solves this by ingesting raw block data from any EVM RPC, applying programmable JavaScript transformations, and streaming the results directly into databases, warehouses, or webhooks. Developers stay in full control of the schema and transformations while skipping the overhead of building their own infrastructure.

## EVM Chains Supported

The Neighborhood is live across all major EVM chains. The full, always-updated list of supported networks can be found at: [docs.indexing.co/networks](https://docs.indexing.co/networks).

Some of the most popular chains include: **Ethereum, Base, Arbitrum, Optimism, Polygon, Avalanche, BNB Chain, Linea, ZkSync, and Scroll**.

This breadth of coverage allows teams to unify data across the EVM ecosystem with a single pipeline approach.

And while The Neighborhood also supports non-EVM ecosystems such as Solana, Aptos, and Sui, we’ll cover those in a separate article.

## Examples of EVM Data You Can Index

Here are some practical pipelines developers build with The Neighborhood:

- Token transfers: ERC20 transfers across Ethereum, Base, Optimism, and others for balance tracking and portfolio tools.

- DEX activity: Swaps and liquidity events from Uniswap, Curve, Balancer, and chain-native DEXs.

- Lending and borrowing: Events from Aave, Compound, Morpho, and other money markets.

- NFT activity: Transfers, mints, and marketplace sales across EVM chains.

- Wallet analytics: Transaction history, token balances, and activity classification for specific addresses.

- Custom contracts: Protocol-specific contracts on any EVM chain, decoded into your own data model.

## Low-Latency and Local Indexing for High-Performance Chains

Not all EVM chains are equal when it comes to speed. New high-performance networks like **RISE, MegaETH, and Base** are pushing the limits of block production and transaction throughput. For these chains, latency becomes critical: traders, DeFi protocols, and real-time dApps cannot afford multi-second delays.

The Neighborhood addresses this with **local indexing**. Nodes can run close to validators or inside your own infrastructure, processing data directly at the source. This setup provides:

- Sub-second latency for real-time trading and MEV strategies

- Local control over uptime and data quality, reducing reliance on third-party APIs

- Programmable pipelines to decode events and normalize them for immediate downstream use

For developers building on RISE or MegaETH, where performance is the differentiator, local indexing ensures your data pipelines keep up with the chain itself. On Base, where scale and consumer apps drive adoption, local indexing helps wallets and DeFi platforms deliver faster UX without sacrificing accuracy.

## Benefits for Builders

**Programmable pipelines**

Customize exactly what you index and transform, without rigid schemas.

**Cross-chain unification**

Combine Ethereum Mainnet activity with Base, Optimism, Arbitrum, and more into one dataset.

**Real-time and historical coverage**

Stream new blocks in sub-second latency while also backfilling history from genesis.

**Cost and efficiency**

Leverage a horizontally scalable compute network that processes workloads faster and cheaper than centralized cloud setups.

**Local deployment options**

Run Neighborhood nodes alongside validators or within your own infra for maximum control and performance.

## Why This Matters for the EVM Ecosystem

As Ethereum expands through its rollup-centric roadmap and more L2s and sidechains launch, indexing becomes the hidden infrastructure problem that every product team eventually faces. Building and maintaining your own indexers is costly and brittle. The Neighborhood provides a unified solution that scales with the ecosystem and lets teams focus on product, not pipelines.

## Getting Started

The Neighborhood supports all major EVMs today and can onboard new ones rapidly. Developers can configure pipelines through our console and APIs, stream data into Postgres, BigQuery, Kafka, or webhooks, and unify analytics across chains.

For product managers, CTOs, and data engineers building on EVM chains, The Neighborhood is the fastest way to go from raw chain data to production-ready pipelines.

_Explore our documentation at [docs.indexing.co](https://docs.indexing.co) or contact us at [hello@indexing.co](mailto:hello@indexing.co) to start indexing your EVM data today._


---
title: Block by Block Ep. 7 – Building for the Next Stablecoin Yield Wave
url: https://www.indexing.co/articles/block-by-block-ep-7-building-for-the-next-stablecoin-yield-wave
description: Block by Block podcast episode with Ryan Rodenbaugh (vaults.fyi).
author: Dennis
date: 2026-03-03
image: https://dbffdfcgucdezodnkido.supabase.co/storage/v1/object/public/content-images/26800167-b6e5-4b9c-810c-5073de66da97/da2e96a5-d5ad-4f07-a8c4-5920cd474ee9.png
tags: Podcast, Block by Block
---

Ryan Rodenbaugh has spent his entire career in crypto, from early RWA experiments at TrustToken to building TrueFi's on-chain credit protocol. Now as CEO of vaults.fyi, he's tackling the infrastructure problem every fintech hits after launching stablecoins: how do you actually offer yield without building integrations to 75+ protocols yourself? In this episode, we explore what it takes to maintain production-grade DeFi data infrastructure, why even sophisticated teams choose not to build it in-house, and how the next wave of crypto adoption will come from distribution platforms embedding yield rather than converting new native DeFi users.

Topics covered:
- Why on-chain maximalism matters — deriving APYs from hourly share price data instead of protocol-reported estimates
- The operational reality of indexing 1,000+ yield opportunities across 18 chains with minimal off-chain dependencies
- How reputation scoring based on TVL longevity (Lindy-ness) separates established protocols from new experiments
- What it actually takes to build transaction execution infrastructure that stays non-custodial across dozens of different protocol interfaces
- The 6-12 month enterprise sales cycle for fintechs and why most have crypto teams but move slowly on compliance
- Why 95% of new protocol integrations are customer-driven, not internal roadmap decisions
- Building for the future: AI agents, account abstraction batch transactions, and cross-chain deposit infrastructure

**Guest:**
Ryan Rodenbaugh — CEO & Co-founder, vaults.fyi (@ryanrodenbaugh, @vaultsfyi)

**Host:**
Dennis Verstappen (@ape_rture)

### Guest + Links
- [Guest X](https://x.com/ryanrodenbaugh)
- [Company X](https://x.com/vaultsfyi)
- [Company Website](https://app.vaults.fyi/)

### Hosted by The Indexing Company
- [Dennis](https://x.com/ape_rture)
- [Website](https://indexing.co)
- [Docs](https://docs.indexing.co)
- [X](https://x.com/indexingco)

---

## Listen & Watch
- [Watch on YouTube](https://youtu.be/ZNE6U5kdZfo)
- [Listen on Spotify](https://open.spotify.com/episode/27J3gY45PSfHs0JzCuTSjJ?si=U0OQ8no8T7WcCxKM35wOuA)


---
title: Better Payments with Better Data
url: https://www.indexing.co/articles/better-payments-with-better-data
description: A webinar on all things indexing and how onchain data leads to payments.
date: 2026-02-04
tags: Post
link: https://x.com/indexingco/status/2019079321281835259
---


---
title: Mesh Partners with Indexing Co to Unlock New Possibilities in Crypto Transfers
url: https://www.indexing.co/articles/mesh-unlocks-new-possibilities-in-crypto-transfers
description: How Mesh leveraged Indexing Co's webhook infrastructure to monitor onchain transfers across multiple chains, improving transaction accuracy and transparency.
date: 2024-04-04
author: Mesh Connect
image: /assets/articles/mesh-unlocks-new-possibilities-in-crypto-transfers.png
tags: Case Study
---

In the rapidly evolving world of digital finance, the ability to seamlessly manage and track on-chain transactions is paramount for both businesses and their customers. Recognizing this need, Mesh has partnered with Indexing Co, a trailblazer in blockchain data solutions, to revolutionize the way crypto transfers are monitored and processed.

## The Challenge: Bridging the Data Gap in Centralized Exchanges

Centralized exchanges, while offering a plethora of services, often fall short when it comes to providing comprehensive data for onchain transfers. This limitation poses a significant challenge for platforms like Mesh that aim to deliver an exceptional user experience by ensuring the accuracy and transparency of every transaction.

## The Solution: A Unified Approach to Onchain Data

To address this challenge, Indexing Co stepped in with its innovative solution - dedicated webhook infrastructure capable of monitoring onchain transfers with a dynamic set of parameters. This groundbreaking technology allows for complex filtering of transactions across multiple chains, including Bitcoin, Ethereum, and Solana, all through a unified interface.

> Capturing onchain transaction records from centralized exchanges posed a significant challenge for us. However, with Indexing Co's innovative infrastructure, we were able to swiftly implement dynamic webhooks that function seamlessly across multiple chains. Their web3 data infrastructure is truly transformative—it's like the AWS of web3 data.

> -Arjun Mukherjee, CTO

## The Value: Streamlining Operations and Enhancing User Experience

By leveraging Indexing Co's specialized infrastructure, Mesh can now access the critical data it needs without the substantial cost and overhead of building indexing infrastructure in-house. This collaboration not only streamlines Mesh's operations but also significantly enhances the user experience by providing more detailed and accurate transaction information.

## The Impact: A New Era in Crypto Transfers

The partnership between Mesh and Indexing Co marks a significant milestone in the crypto industry. It sets a new standard for how onchain data can be utilized to improve transaction monitoring and processing. This collaboration is a testament to the power of innovation and strategic partnerships in driving the future of finance.

## Looking Ahead: Expanding Horizons

As Mesh continues to innovate and expand its services, the partnership with Indexing Co will play a crucial role in enabling more advanced features and capabilities. The ability to seamlessly integrate data from various blockchain networks opens up a world of possibilities for developing new financial products and services that cater to the evolving needs of users.

## Conclusion: A Partnership for the Future

In conclusion, the collaboration between Mesh and Indexing Co is a prime example of how leveraging cutting-edge technology can solve complex challenges in the crypto space. By joining forces, these two companies are not only enhancing their own offerings but also contributing to the broader advancement of the digital finance ecosystem.

Stay tuned as Mesh and Indexing Co continue to push the boundaries and unlock new possibilities in the world of crypto transfers.

---

Read the original post [here](https://www.linkedin.com/pulse/unlocking-new-possibilities-crypto-transfers-mesh-partners-89kjc/)


---
title: Build Blockchain Data Pipelines with Your AI Coding Agent
url: https://www.indexing.co/articles/indexing-co-mcp
description: Connect your AI coding agent directly to the Indexing Co API. Describe what onchain data you need, and the agent builds the pipeline.
author: Dennis Verstappen
date: 2026-03-09
tags: Guide
---

You tell your agent what onchain data you need. It builds the pipeline. No dashboard, no configuration files, no context switching.

The Indexing Co MCP (Model Context Protocol) server connects AI coding agents directly to the Indexing Co API. Whether you use Claude Code, Codex CLI, or another MCP-compatible agent, you get a conversational workflow for creating filters, writing transformations, deploying pipelines, and streaming live blockchain events.

## What You Get
Three components work together:

**MCP Server** — Connects your agent to the Indexing Co API and live event stream via WebSocket. Gives it direct access to pipeline operations, transformation testing, and event subscriptions.

**Skill** — Teaches the agent the full pipeline workflow: filter patterns, transformation syntax, destination adapters, event signatures, and debugging steps. This is how the agent knows what questions to ask and what validations to run. Currently available for Claude Code, with Codex CLI task support coming soon.

**Preview CLI** — Streams live pipeline events to your terminal with colorized output. Addresses appear in magenta, transaction hashes in blue, numbers in yellow. Nested objects render with recursive colorization and indentation. Press Ctrl+C to see a summary with total event count, duration, and average throughput.

## How It Works
You describe what you want in natural language:

- "Index all USDC transfers on Base to my Postgres database"
- "Set up a webhook for Uniswap V3 swaps on Ethereum"
- "Stream Aave supply events on Arbitrum so I can see them live"

The agent walks through the workflow: creates a filter with the contract addresses, writes a transformation function using the event ABI, tests it against a recent block, sets up the destination adapter, deploys the pipeline, and backfills historical data.

Each step runs against live data. When the agent tests a transformation, it fetches actual transaction data from the chain, runs your function, and shows the output. If the schema needs adjustment or an event signature is wrong, you iterate in the conversation.

## Example Session
**You:** "I want to track all USDC transfers on Base"

**Agent:** Creates a filter with the Base USDC contract address (0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913)

**Agent:** Writes a transformation using `utils.evmDecodeLogWithMetadata` for Transfer events

**Agent:** Tests the transformation against block 25384920, shows decoded output

**Agent:** Asks where you want the data — Postgres? Webhook? Direct stream?

**You:** "Postgres, same schema as our other transfers table"

**Agent:** Generates the delivery config, creates matching database schema, deploys the pipeline

**Agent:** Backfills the last 100 blocks and confirms data arrives in your database

**You:** "Stream the next events so I can see them"

**Agent:** Launches the preview CLI with your channel name, triggers a backfill — live events appear in your terminal as they process

## What the Agent Can Do
The MCP server exposes these capabilities to any connected agent:

**Pipeline management** — List, create, read, and delete pipelines. Check status, view configuration, pause and resume.

**Filter management** — Create address filters for specific contracts, list existing filters, add or remove addresses from filters.

**Transformation handling** — Write transformation code, test transformations against live blocks, view and update existing transformations.

**Backfill control** — Backfill historical blocks for a pipeline, monitor backfill progress.

**Event streaming** — Subscribe to live event channels, stream events to the terminal, query stored events with SQL.

**Data exploration** — Run SQL queries against indexed data, describe table schemas, preview results.

Each operation runs through the API with your credentials. The agent sees the same data you'd see in the dashboard, but you never leave the terminal.

## Live Event Streaming
Pipelines using the DIRECT adapter send events to a named channel. You stream those events with the preview CLI:

```
node /path/to/indexing-co-mcp/dist/cli/preview.js my-channel-name
```

The DIRECT adapter only sends events when at least one subscriber is connected. This keeps the stream lightweight — no persistent queue, no storage overhead.

You can run DIRECT alongside any other adapter. Set up two pipelines with the same filter and transformation: one delivers to Postgres, the other to your preview channel. Both process the same events. One gives you queryable history, the other gives you a live terminal view.

## Setup
### Claude Code
**1. Install the MCP server**

```
git clone https://github.com/indexing-co/indexing-co-mcp.git
cd indexing-co-mcp
npm install && npm run build
```

Register it with Claude Code:

```
claude mcp add --scope user indexing-co -- node /path/to/indexing-co-mcp/dist/index.js
```

**2. Add your credentials**

Create `~/.indexing-co/credentials` with your API key:

```
API_KEY=your_api_key
```

Sign up at [accounts.indexing.co](https://accounts.indexing.co) if you need an API key.

**3. Install the skill**

```
claude skill add --scope user https://github.com/indexing-co/indexing-co-pipeline-skill
```

This loads the pipeline patterns, event signature database, and debugging workflows into the agent's context.

### Codex CLI
**1. Install the MCP server**

Same installation steps as above — clone, build, and add your credentials.

**2. Register with Codex**

```
codex mcp add indexing-co -- node /path/to/indexing-co-mcp/dist/index.js
```

Codex picks up the MCP tools automatically. The skill system differs from Claude Code, but the MCP server works the same way — same tools, same API access, same live event streaming.

### Other MCP-Compatible Agents
Any agent that supports the Model Context Protocol can connect to the Indexing Co MCP server. Point it at the built server entry point and provide your API credentials. The tool interface is standardized — pipeline operations, filter management, transformation testing, and event subscriptions all work through MCP tool calls.

## What This Enables
**Conversational debugging** — Describe the problem. The agent checks pipeline status, reviews recent events, tests the transformation against a failing block, and suggests fixes.

**Schema iteration** — Change your transformation logic, test it against historical data, see the new output, deploy when it looks right.

**Multi-chain setup** — "Index the same events on Ethereum, Base, and Arbitrum" — the agent creates three pipelines with the same transformation logic but different chain configurations.

**Ad-hoc queries** — "Show me all transfers above $100k from the last hour" — the agent writes and runs the SQL query against your indexed data.

**Live monitoring** — Stream events from a new deployment, watch for anomalies, kill the stream when you're confident it's working.

The skill teaches the agent how to chain these operations. It knows to test a transformation before deploying, to backfill a small range before a large one, to check delivery status after a backfill completes.

## Workflow Patterns
**New pipeline from scratch:**
1. Describe the onchain data you need
2. The agent identifies the contract(s) and event(s)
3. The agent writes a transformation and tests it against a recent block
4. You review the output, request adjustments if needed
5. Choose your destination (Postgres, webhook, direct stream)
6. The agent deploys and backfills a test range
7. Verify data arrives, then backfill historical blocks if needed

**Modify existing pipeline:**
1. "Update the USDC pipeline to include the token symbol"
2. The agent retrieves the current transformation
3. The agent adds the new field and tests against a known block
4. You confirm the output looks correct
5. The agent updates the transformation and reprocesses recent blocks

**Debug delivery issues:**
1. "My Aave pipeline stopped delivering events"
2. The agent checks pipeline status, reviews error logs
3. The agent tests the transformation against the block where delivery failed
4. Identifies the issue (schema mismatch, network timeout, malformed event)
5. Suggests a fix, implements it after confirmation

## When to Use This
This workflow fits if you:

- Prefer terminal-based development over web dashboards
- Want to iterate on transformations with instant feedback
- Need to set up similar pipelines across multiple chains
- Debug issues by testing against specific historical blocks
- Stream live data to verify pipeline behavior before full deployment

The MCP server runs locally. Your API key stays on your machine. The agent operates with the same permissions as your API key — it can create and delete pipelines, backfill historical data, and query indexed events. Treat the MCP connection with the same security posture as your API credentials.

Full documentation: [docs.indexing.co](https://docs.indexing.co/examples/claude-code)

MCP server repository: [github.com/indexing-co/indexing-co-mcp](https://github.com/indexing-co/indexing-co-mcp)

Skill repository: [github.com/indexing-co/indexing-co-pipeline-skill](https://github.com/indexing-co/indexing-co-pipeline-skill)

Questions: [hello@indexing.co](mailto:hello@indexing.co)


---
title: The Road to Data 3.0
url: https://www.indexing.co/articles/the-road-to-data-3-0
description: Exploring the challenges of accessing decentralized data in web3 and why Data 3.0 infrastructure is essential for the future of the ecosystem.
date: 2022-08-31
image: /assets/articles/the-road-to-data-3-0.png
author: runninyeti
tags: Post
---

## Welcome!

If you are reading this, congratulations on being a part of the next generation of innovation we like to call “Web 3.0” (or simply “web3”). You could be an artist looking to leverage the decentralized economy via an NFT launch, a builder working to further on-chain protocols with smart contracts, a business looking to leverage blockchain technologies to level up your internal logistics, or even just an innocent bystander looking to learn more about _the next big thing_ - whatever the reason, we are glad you are here!

As the [2022 State of Crypto Report by a16z](https://a16zcrypto.com/state-of-crypto-report-a16z-2022/) summarizes, the adoption of web3 is growing, here to stay, and is empowering the next wave of creators. And while all of that is extremely exciting, the road to web2 scale (i.e. billions of users) is far from paved. For instance, the estimated 7-50 million Ethereum users have all had to learn about concepts like private keys, wallets, gas fees … and that’s just to get started in the ecosystem.

Creators in web3 don’t fair any better. Building Decentralized Applications (dApps) often requires a working knowledge of blockchain data types, smart contract deployment and management strategies (hint: it’s not like traditional software development), gas fees, tokenomics, pseudo-anonymous “users", etc, etc. There is a silver lining for creators and users alike though: the growth of web3 can largely be attributed to trailblazing individuals and companies \*continuing\* to work on solving everything from user identity to transaction throughput of the underlying networks.

![](https://media.giphy.com/media/l0MYGb1LuZ3n7dRnO/giphy.gif)

## Data 3.0

One often overlooked aspect of the entire ecosystem though is the accessibility of data itself. As builders we’ve grown \[relatively\] accustomed to sending data out into the ether (🥁) without knowing how we will get it back in any sort of usable form. This leads to reliance on centralized sources to figure that out on our behalf, and charge us for that service - at least partially defeating the original purpose of decentralizing the data to begin with. To truly enable the future of decentralized data we must rethink our approach to Data 3.0.

#### An Example

Let’s take a look at one of the most common examples in the space today: tracking NFT project owners. NFT ([Non-Fungible Token](https://www.theverge.com/22310188/nft-explainer-what-is-blockchain-crypto-art-faq)) projects have significantly contributed to the rise of adoption in web3 over the last couple of years. [OpenSea](https://opensea.io/) for instance, the largest NFT marketplace, has facilitated up to $4.8 billion USD in sales _in a single month_ at the height of the last crypto cycle ([source](https://dune.com/rchen8/opensea)).

What makes NFT projects particularly interesting for our Data 3.0 example though is their relative ease to develop (relative to web3 in general that is) combined with the repeated centralization these projects utilize. At their base layer, NFTs are smart contracts (permanent, unchangeable software) on a given blockchain (often Ethereum) that enable users to own, and transfer, a fixed number of items. NFT project creators can write and deploy their smart contracts, distribute the initial set of items (whether through giving them away or letting web3 users buy them from the smart contract directly), and then leverage a marketplace like OpenSea to enable trades between web3 users.

An overly simplified lifecycle of an NFT project may go something like this:

1. Creator A launches the highly successful NFT Project X
2. Thousands of web3 users trade NFT Project X items as owners
3. … time passes …
4. Creator A now wants to give each of the _current_ owners of Project X a gift for being such a great community
5. Creator A realizes they can’t readily get a list of current owners from the blockchain directly and is therefore presented with the following choices:
   1. Scrap the gift idea
   2. Write a script to check the current owner of every item against the blockchain. This requires web3 development knowledge _and_ would only generate point in time snapshots making it difficult to keep up with items that may be rapidly switching hands.
   3. Learn how to build an _indexer_ to crawl and subscribe to updates from the blockchain, replaying every trade sequentially, to determine the current owner of each item. This solves the problem, but requires even more web3 development knowhow and the ongoing maintenance of the indexer itself.
   4. Use a readily available API from a centralized source (that has built their own indexer) to provide this data. This is by far the easiest solution, but requires reliance on a 3rd party provider that may or may not be generally reliable (looking at you OpenSea…) and often incurs a service cost.
6. Creator A chooses a 3rd party API provider
7. Owners of NFT Project X get their gifts and everyone is happy

#### What’s the catch?

This all sounds fine and dandy right? And it mostly is. Generally the 3rd party providers can be trusted to provide real time, consistent data. But what happens when that 3rd party isn’t reliable or changes the way it serves that data? Or more importantly, what happens when Creator A has a use case no longer supported by the standard offering (e.g. they want to only give gifts to owners that have held their NFTs more than 90 days)? And all of this is just the tip of the iceberg.

While providers are rapidly appearing to fill the holes in Data 3.0, most of them are doing so in use case specific ways; [OpenSea](https://opensea.io/) for NFT data, [Alchemy](https://www.alchemy.com/supernode) for raw blockchain data, etc. [Ethereum’s developer docs](https://ethereum.org/en/developers/docs/) - which are honestly great - don’t even mention “indexing” except to point at a 3rd party provider, [The Graph](https://thegraph.com/). And The Graph, which describes itself as “an indexing protocol for querying networks like Ethereum and IPFS”, has limited support for customizations and forces participation in something akin to an indexing marketplace.

![](https://images.mirror-media.xyz/publication-images/uUF4ZsAYbivrv3uPml6FC.png?height=1295&width=2128)

There’s a missing link in the Data 3.0 lifecycle and the impacts are only just starting to be felt. Web3 creators should be empowered to own, leverage, and define their data as they see fit. Join us in shaping the future of Data 3.0.


---
title: Serving AI with Data Infrastructure Fit for Web3
url: https://www.indexing.co/articles/serving-ai-with-data-infra
description: Web3 technology is perfectly positioned to ensure AI operates on trustworthy data while making AI accountable, transparent, and interconnected.
author: Dennis Verstappen
date: 2025-08-07
image: /assets/articles/serving-ai-with-data-infra.avif
tags: Post
---

Web3 technology is perfectly positioned to ensure AI operates on trustworthy data while making AI accountable, transparent, and interconnected. Blockchain can verify data through the network, guaranteeing that the inputs to and outputs from AI models are reliable. While the current Web3 landscape largely centers around financial data, blockchain technology has the potential to extend far beyond, encompassing personal information, scientific data, and government records.

Currently, developers of AI, AI agents, bots, and ML models in Web3 are working to determine the necessary data infrastructure and data for training, inference, monitoring, and retraining their models. Before diving into the entire data pipeline required for these processes, let's look at a few examples of model types that can be supported:

- Large Language Models (LLMs): this type of model is at the center of attention regarding AI. In Web3, these models can be used to have users interact with the blockchain and perform actions without those users requiring to understand the complexities of the technology. On its own, LLMs are not the best fit for blockchain data, since they mostly require text data (vs. the transactional data on the blockchain). However, when transactions or wallets are labeled and given context through embeddings and systems using Retrieval Augmented Generation (RAG), blockchain data can be served back to users.

- Document or Vector Search: this type of model utilizes embeddings to find similarities between documents or vectors. In blockchain an embedding could exist for a protocol or for a wallet address and then compared to other embeddings. This type of model can be very useful for search engines, marketing and growth tooling and analytics.

- Prediction models: since most activity in Web3 is related to financial transactions, predicting prices to speculate on these prices is a popular exercise. However, prediction models can be used to predict other useful metrics like transaction activity, gas costs, user retention, sybil users, etc.

A few challenges exist in the current Web3 environment with this data with the main problems being:

- Data is scattered across multiple chains and the number of chains continues to increase. Most data providers only serve a certain number of chains.

- Data on the blockchain is unstructured which requires custom transformations and feature engineering to make it useful for building AI.

- If data served to developers is structured it takes a certain format (because of APIs or query systems). This format or data schema is highly likely not the exact schema needed for the models, which requires developers to build out infrastructure to load and transform data before it can be used in their models.

- Data regarding address labels is scattered across multiple data providers, without standardization or automation to do correct data labeling (like contract labels)

<hr />

We will now take a look at the processes needed to put AI into production and how the unique data infrastructure from The Indexing Company can serve the builders and AI in Web3.

#### Training

To train models, a vast amount of data is needed. The training of these models happens often in a local environment with easy access to the data. The data is fed to these models in batches so these models can learn from those inputs. Historical on-chain data has to be fetched and can come from multiple chains. Ideally this data is transformed into a unified data schema, regardless of chain (EVM or non-EVM), while data is enriched with off-chain data like contract labels. Since the data pipelines built by The Indexing Company are chain agnostic and allow custom transformations, the data can be put into a unified data schema before it hits the training database or data lake. Since the data pipelines are highly configurable, data like contract labels or pricing data can be added to ensure a more complete feature set. The parallel processing network utilized by The Indexing Company ensures that backfilling this historical data is pushed fast to the target data infrastructure.

#### Inference

Inference is a term that covers the process trained AI models use to make predictions and decisions based on new incoming data. Ideally this data reaches the model in the same schema and with the same features as in the training stage. Data needs to be frequently updated to have the AI serve the user or act on its own. Data can be streamed in real time to a database which can trigger the AI based on certain thresholds. If the AI needs to pull data, the AI can query the database or can call an API which is hosted on top of the database. Since the pipelines from The Indexing Company can be configured in a way where it does not matter if the data is historical or real time, the same infrastructure can be used to both train the AI and serve the data for inference purposes. Basically, setting up these pipelines for historical data ensures that the data pipelines for inference are already in place too. These data pipelines can furthermore be optimized for low latency to have the AI act as fast as possible after blocks are confirmed on the blockchain.

#### Monitoring

Once an AI or a swarm of multiple agents begin transacting on the blockchain, they should be monitored to ensure performance. The data resulting from the agent's actions can also be indexed and used for real-time alerts, monitoring and analytics, giving users the ability to disable or reconfigure the agent in real time. We designed our infrastructure to be responsive (vs. a static approach to configurations), automatically indexing new data based on the data coming in and/or the reconfigured logic (either on events emitted on the blockchain or when a trigger is sent to the pipelines). This ensures that every new action by the bot or every new bot added to the swarm gets monitored.

One example of this responsive data infrastructure is Just In Time Indexing (JITI). In a previous article, we described how Just In Time Indexing can work to continuously backfill and index new transactions from new addresses. For example, when a new agent is registered to the network, it would do so from a Factory Contract. JITI would be triggered to now monitor this new address and all transactions related to this address. This process ensures data completeness without manual intervention by developers.

#### Retraining

Models need to be retrained frequently to stay up to date with changes in the environment, to improve performance or to add new chains the bots need to be active on. With new types of data coming in, the chance that this data is in a different schema and requires new transformations is high. This is both true when new data from protocols or chains is added, since the smart contract structure or event structure might be different. Luckily, since we designed our data pipelines to be highly configurable, these transformations can happen before the data hits the target data infrastructure. Even if data comes from different sources or chains (EVM vs. Non-EVM) the resulting data schema can be unified. The unification of the data ensures continuity in the data schemas needed to calculate the features. This reduces the additional data engineering needed to integrate new data.

#### Conclusion

We welcome the opportunity AI brings to Web3. The potential is promising to both improve UX for users or automate tasks with settlement on a blockchain. The data infrastructure The Indexing Company provides is fully ready to help developers in AI and Web3 build a next generation of products. With fast and complete historical data, real time data streaming and responsive data pipelines, any type of model and AI can be (re-)trained, served and monitored.

We are happy to spar with developers and businesses on their data needs. If you want to chat or need support, [reach out to us](/contact).


---
title: How to Build Blockchain Data Pipelines in Minutes with AI Agents
url: https://www.indexing.co/articles/how-to-build-blockchain-data-pipelines-in-minutes-with-ai-agents
description: Indexing Co ships two interfaces for AI coding agents, an MCP server and a Claude skill. Both spin up production-grade pipelines in under 2 minutes from a plain-English prompt.
author: VOICE
date: 2026-04-23
---

>Indexing Co ships two interfaces for AI coding agents: an MCP server and a Claude skill. Both spin up production-grade blockchain data pipelines in under 2 minutes from a plain-English prompt.

[Watch on YouTube](https://youtu.be/PV2LqnczUH4)

## The Problem with Traditional Blockchain Indexing
Your subgraph just desynced during a token launch. Traders are making decisions on data that's 45 seconds old.

This happens constantly. Building blockchain data pipelines means juggling tools: writing subgraph schemas, deploying to hosting platforms, configuring API endpoints, debugging when something breaks. Context-switching kills momentum. A pipeline that should take minutes to test takes hours to deploy.

Indexing Co ships two interfaces that collapse the workflow into one conversation with your AI coding agent: an MCP (Model Context Protocol) server and a Claude skill. Describe the onchain data you need in plain language. The agent handles the rest.

## What MCP Does for Blockchain Data
MCP streams blockchain data directly to your development environment.

Traditional blockchain APIs require you to pull data through fixed endpoints. You configure filters, write transformation logic, deploy to a separate platform, query the results. Each step introduces latency and context-switching.

Indexing Co's MCP server runs as a persistent background process. It connects directly to Claude or any MCP-compatible agent. Tell the agent what data you need, and it:

1. Writes the filter configuration for specific contracts and events
2. Creates JavaScript transformation functions that reshape raw block data
3. Tests the transformation against live blockchain data
4. Deploys the pipeline to production
5. Streams results into a local SQLite database via WebSocket

The entire flow takes under 2 minutes. In a recent demo, Indexing Co set up a pipeline tracking all USDC transfers on Base (including a 624-block backfill) in 1 minute 57 seconds.

## The Live Demo: USDC Transfers in Under Two Minutes
Dennis and Brock demonstrated the full workflow during a workshop. Starting with a blank Claude session, they asked the agent to track USDC transfer volume on Base.

Claude handled the complete pipeline setup:

- Wrote the filter for USDC contract events
- Created a transformation that extracts sender, receiver, and transfer amount
- Tested against live Base blocks
- Deployed the pipeline with automatic backfill
- Streamed results locally while generating volume charts

Within seconds, the local SQLite database contained over 5,000 USDC transfers. The agent identified a spike in the data (a $200M flash loan to Morpho) without any manual analysis.

This workflow removes configuration files, separate deployment platforms, and API polling. The agent operates entirely within your terminal environment. Data flows continuously via WebSocket, so you see results immediately rather than waiting for historical indexing to complete.

## How the Claude Skill Differs from MCP
The Claude skill gives you similar capabilities with a lighter runtime.

MCP runs as a persistent background process. It holds WebSocket connections for streaming and stores up to 10,000 records locally. That opens multi-agent orchestration: multiple Claude sessions can query the same live dataset.

The Claude skill wraps the Indexing Co API into natural-language patterns. It teaches Claude how to create pipelines, define transformations, set filters, and manage deployments. No background process needed, which keeps it lighter for workflows that don't need persistent streaming.

Both approaches use JavaScript for transformations. Transformations stay readable and programmable. The logic you prototype against local SQLite ships to production unchanged. You swap the destination, not the code.

## Real-Time Iteration Without Leaving Your Terminal
The streaming architecture turns debugging into a conversation.

Traditional indexers force a deploy-wait-discover-bug loop. You fix, redeploy, wait again. Each iteration costs minutes.

With the MCP, you describe a problem and the agent validates immediately. Example from the workshop:

"Check the volume chart. There's a spike at block 17,234."

The agent queries the local SQLite store. It flags the $200M transfer, confirms it's a Morpho flash loan from embedded protocol knowledge, and suggests filtering flash loans out of the volume calculation.

The feedback loop is tight because data streams continuously into your local environment. No separate dashboards. No API polling. No context-switching between tools.

## Agent Assistance Through Pattern Recognition
LLMs already understand most blockchain primitives.

ERC-20 transfers, Uniswap swaps, Aave lending events: these concepts are well-represented in training data. The agent knows event signatures, ABI structures, and common transformation patterns.

Agents struggle with custom contracts or niche protocols. The Indexing Co MCP ships helper functions for those cases:

- Upload ABIs or Solidity source code
- Extract event signatures automatically
- Decode logs using contract-specific schemas

The agent needs 1-2 iterations to get custom contract indexing working. Streaming validates each attempt on the spot, so you see results as soon as the transformation compiles.

Next up: Indexing Co is integrating RAG (retrieval-augmented generation) to suggest transformation patterns from similar pipelines. That gives new users a starting point when they're not sure how to shape their data.

## Why This Works Better Than API Wrappers
Most blockchain data APIs constrain what you can query.

You get predefined endpoints for common patterns: token transfers, NFT mints, DEX swaps. Custom queries require manual configuration or aren't supported at all.

Indexing Co's MCP inverts that model. You define transformations in JavaScript, so you can reshape data however your application needs it. The MCP handles:

- Multi-chain deployment from a single definition
- Historical backfills (years of data available)
- Factory pattern discovery (new contracts matching a pattern are auto-indexed)
- Real-time streaming without separate infrastructure

That flexibility compounds during prototyping. In the workshop, Dennis and Brock refined the initial USDC pipeline on the fly:

"Only track USDC transfers on Aave, not all transfers."

"Deploy the same transformation to Ethereum mainnet."

"Run parallel pipelines for USDC, USDT, and DAI."

These are single-line changes in a conversation with Claude. The agent handles redeploying with the updated configuration.

## From Prototype to Production Without Rewriting
The transformation logic you prototype locally is production-ready.

JavaScript transformations written during development behave identically against a production database. You're not translating between a local testing format and a production schema. The schema gets defined once, then reused.

Indexing Co processes 47 billion blockchain events daily across 100+ chains on this architecture. Median block-to-storage latency: 2.54 seconds. The same transformation functions that power production pipelines run in local SQLite during development.

That continuity cuts a major friction point. Teams typically prototype with one toolset (simplified for speed) then rebuild for production (optimized for scale). The gap creates bugs and delays. Indexing Co collapses the gap. You iterate fast without building technical debt.

## Multi-Agent Orchestration Through Shared Data
The MCP lets agents share a live blockchain data source.

Data streams into local SQLite as a background process, so multiple Claude sessions can query the same dataset at the same time. One agent handles pipeline setup while another runs analytics or builds APIs on top of the streamed data.

The pattern fits how specialized agents are starting to collaborate on complex workflows. The MCP acts as infrastructure: a persistent data layer that any agent can hit through natural language.

For teams building multi-agent systems, that removes a major bottleneck. Agents stop polling external APIs or coordinating access to shared resources. Data flows continuously, and any agent with MCP access can query it.

## What You Need to Get Started
For the Claude skill:

1. Sign up for an Indexing Co API key at accounts.indexing.co
2. Install via GitHub: `claude skill add --scope user https://github.com/indexing-co/indexing-co-pipeline-skill`
3. Tell Claude what onchain data you need

For the MCP server:

1. Get an API key (same as above)
2. Clone the MCP repository https://github.com/indexing-co/indexing-co-mcp
3. Follow the instructions in the repo for installation
4. Connect Claude to the running MCP instance

The skill loads pipeline patterns, an event signature database, and debugging workflows into Claude. The MCP adds persistent data streaming and local storage.

Both approaches assume technical fluency with blockchain concepts. If you're working with custom contracts, have the ABI or Solidity source available. The agent will prompt you if it needs additional context.

## The Infrastructure Advantage
A point Dennis made in the workshop: most AI wrappers won't last.

Public blockchain knowledge gets commoditized into LLM training data. Competitors wrapping third-party APIs inherit those APIs' limits. What holds up long-term is owning infrastructure that an API can't replicate.

Indexing Co owns the indexing pipeline from chain nodes to final data delivery. That vertical integration ships features API-based competitors can't match:

- Sub-3-second block-to-storage latency
- Custom transformations in JavaScript
- Multi-chain deployment from one definition
- Historical backfills without manual configuration

The MCP and Claude skill expose this infrastructure through a conversational interface. You get the flexibility of custom indexing without running the infrastructure yourself.

## Next Steps and Community Builds
Indexing Co is seeking feedback on what to build next.

If you need functionality the current MCP doesn't support, email hello@indexing.co or have your agent contact them. The team plans to integrate Perplexity for fast search and enrichment directly into pipeline transformations.

GitHub links for the MCP server and Claude skill live in the Indexing Co docs. The team wants to see what developers build with this tooling. Share your pipelines and use cases.

For multi-agent workflows, treating the MCP as a central data source for onchain information is the recommended pattern. Run the MCP server as infrastructure, then connect multiple agents that query and process the streamed data.

## Key Takeaways
- Indexing Co's MCP streams blockchain data directly to your terminal, removing dashboard and API context-switching.
- A complete pipeline setup (filter, transformation, deployment, backfill, streaming) takes under 2 minutes from a conversation with Claude.
- JavaScript transformations written during prototyping work identically in production, removing the rewrite step.
- The MCP opens multi-agent orchestration by providing a shared, continuously updated blockchain data source.
- LLMs already understand most blockchain primitives (ERC-20, Uniswap, Aave), so agents can generate working transformations with minimal guidance.


---
title: Building the Data Economy Layer for Your Chain
url: https://www.indexing.co/articles/building-the-data-economy-layer-for-your-chain
description: How chains can build a data economy layer using The Neighborhood to turn raw blockchain activity into monetizable data products and validator yield.
author: Dennis Verstappen
date: 2025-10-23
tags: Post
---

#### Why Data Is the Next Competitive Edge

Every blockchain competes for more than just transactions; it competes for data. As chains evolve beyond simple value transfer, the demand for structured, real-time, and AI-ready data is accelerating. Networks like **Story** and **Peaq** are leaning into this reality by aligning infrastructure around data and intelligent agents. In this new era, the value of a chain is not defined by blockspace alone but by its ability to power a thriving data economy on top of it.

#### The Hidden Cost of Ignoring Data Infrastructure

Most chains still treat data as a byproduct, not a resource. Developers struggle to access usable onchain information without building costly indexing stacks. Validators process large volumes of raw data but do not earn from it. AI builders and analytics teams repeatedly leave the chain to find, clean, and reshape data. The result is underutilized compute, fragmented ecosystems, and missed economic potential. Without a native data economy layer, valuable activity remains invisible, and so does the opportunity to generate volume and yield for the network.

#### How The Neighborhood Turns Data Into an Economy

**The Neighborhood** by **The Indexing Company** is a distributed data layer designed for real-time processing and streaming across any blockchain. Builders configure pipelines to filter contracts, decode events, and fuse onchain and offchain data. Lightweight nodes run alongside validators and use idle compute to power these pipelines. Builders pay in the chain’s token for usage. Node operators earn new yield for processing. The network gains transaction volume and native utility.

For **Story**, this model strengthens provenance, licensing, and AI workflows with programmable, verifiable data streams. For **Peaq**, it turns machine and device outputs into monetizable, verifiable data products that agents can consume. Any chain that integrates The Neighborhood can transform raw activity into a self-sustaining loop of usage, revenue, and growth.

#### Lead the Future of Onchain Data

Chains that adopt a data economy layer unlock a new source of onchain volume: data volume. They create durable yield for validators, better tools for developers, and stronger network effects for the ecosystem. If your chain focuses on AI, data, or autonomous infrastructure, now is the time to build your data economy layer. **Contact The Indexing Company** to see how **The Neighborhood** can power it today.


---
title: Claude Skill Indexing Co pipelines
url: https://www.indexing.co/articles/claude-skill-indexing-co-pipelines
description: Claude Code can now set up production onchain data pipelines for you. Just tell it what onchain data you need.
author: Dennis Verstappen
date: 2026-02-24
tags: Guide
---

# Building Onchain Data Pipelines Through Claude Code
Claude Code can now set up production onchain data pipelines for you. Just tell it what onchain data you need. The Indexing Co Pipeline skill shipped this week. Install it once, then ask Claude Code to index Uniswap swaps, track token transfers, or monitor lending events. It handles the entire workflow: writing filters, building transformation functions, generating SQL schemas, and deploying to production.

## What it does
The skill teaches Claude Code the Indexing Co pipeline API. Three components:

**Filter** — which contracts or wallets to watch

**Transformation** — JavaScript that reshapes raw block data into structured output

**Destination** — where to send the results (PostgreSQL, Kafka, webhooks, S3, 16+ other adapters)

Claude walks through each step with you. It writes the transformation logic, tests it against real blocks, generates matching database schemas, and deploys the pipeline. The entire conversation happens in natural language.

Example prompts that trigger the skill:
- "Index all Uniswap V2 swaps on Ethereum and send them to my Postgres database"
- "Set up a pipeline to track ERC-20 transfers for this contract: 0x..."
- "Monitor Aave lending events across Ethereum and Arbitrum"
- "Backfill historical token transfers for the last 6 months"

## How the workflow runs
Start a session in Claude Code. Ask for a data pipeline. The skill activates automatically.

Claude first confirms what you want to track. It asks about contract addresses, event types, and which chains to monitor. From there, it drafts a filter configuration.

Next comes the transformation function. Claude writes JavaScript that extracts specific fields from raw transaction data and reshapes them into your target schema. It shows you the code. You can adjust the logic or ask it to add computed fields.

Before deployment, Claude tests the transformation against a live block. It fetches actual transaction data, runs your function, and shows the output. If something breaks or the schema needs adjustment, you iterate right there in the conversation.

Once the transformation works, Claude generates the SQL schema that matches your output format. It handles data types, indexes, and constraints based on what your transformation returns.

Final step: deployment. Claude Code calls the Indexing Co API to create the pipeline. Within seconds, data starts flowing to your database. You can monitor it, backfill historical data, or set up additional pipelines using the same pattern.

## Coverage and destinations
The skill supports 100+ networks: EVM chains (Ethereum, Base, Arbitrum, Optimism), Solana, Aptos, Bitcoin, Cosmos, and more. You specify the chain when setting up your filter.

For destinations, the skill integrates with:

PostgreSQL, MySQL, SQLite, MongoDB, BigQuery, Firestore, Neo4j, ArangoDB, Webhooks (HTTP), WebSocket, Kafka, Kinesis, Pulsar, GCP PubSub, AWS S3, Google Cloud Storage

Pick the adapter that fits your infrastructure. Claude handles the configuration.

## Prerequisites and installation
You need Claude Code installed and an Indexing Co API key. Sign up at [accounts.indexing.co](https://accounts.indexing.co) to get your key.

Clone the repository and copy the skill folder into your Claude Code skills directory:

```
git clone https://github.com/indexing-co/indexing-co-pipeline-skill.git
cp -r indexing-co-pipeline-skill/skills/indexing-co-pipelines ~/.claude/skills/
```

Claude Code picks up the skill on your next session. No additional configuration required.

## Why this approach works
Most indexing tools force you to context-switch: write configuration files, deploy to a separate platform, debug errors in isolation from your development environment. The skill keeps everything in the conversation. For teams building dApps, analytics dashboards, or AI training datasets, this removes the friction of setting up data infrastructure. Just state your requirement and iterate with Claude until the pipeline works.

The skill turns Claude Code into a direct interface for the Indexing Co API. You describe what you need. Claude writes the code. You see the output before it goes live. The entire pipeline development cycle compresses into a single session.


---
title: The Evolution Of Blockchain Indexing
url: https://www.indexing.co/articles/evolution-of-indexing
description: In a recent livestream, we explored the evolution of blockchain data indexing with three industry experts.
author: Jake Horn
date: 2025-02-20
image: /assets/articles/evolution-of-indexing.avif
tags: Social
---

Fuel Network invited Indexing Co to discuss evolution of blockchain data indexing with industry experts. The discussion delved into how data indexing has evolved from traditional EVM approaches to modern high-throughput AltVM solutions, highlighting the challenges and opportunities in this rapidly evolving space.

View the complete talk [here](https://x.com/i/broadcasts/1djGXVBqDNPxZ).


---
title: Welcome to The Neighborhood: Syndicate $SYND
url: https://www.indexing.co/articles/welcome-to-the-neighborhood-syndicate
description: We are putting our $SYND to work. By staking to Syndicate appchains and powering their data infra with The Neighborhood, we are aligning with builders where it matters: usage, rewards, and growth.
author: Jake Horn
date: 2025-09-22
image: /assets/articles/welcome-to-the-neighborhood-syndicate.avif
tags: Announcement
---

Today marks the launch of $SYND, the native gas token of Syndicate. From the start, SYND is used for all sequencing transactions and to pay gas when deploying or managing appchain sequencers. As the network matures, fees transition to a decentralized model where operators and stakers directly earn from usage. This important feature ties token rewards to real activity. Transactions drive fees, more fees means more rewards for the operators securing the network.

The Indexing Company was chosen as one of the beneficiaries of the $SYND airdrop. Our unique data infrastructure fits well into the design of Syndicate and the related appchains. With our network The Neighborhood we can fetch data from any appchain and serve builders and analytic platforms with that data. We turn raw block data into streams of data to power front-ends, analytics, DeFi Dashboards and cross-chain products. The more activity an appchain has, the more data is processed and the more users benefit from our data infra.

Hence, why we are planning to put our $SYND to good use and will align our stake with builders using The Neighborhood. The unique design from SYND enables us to stake to specific appchains, which causes emissions to flow to the appchain generating activity. By staking SYND and directing our stake to the Syndicate appchains using The Neighborhood, we are aligning with them both in our service and onchain. We support them in becoming a successful appchain, supported by our SYND stake and in return we will share in their growth. Together we create a flywheel where active chains generate more data, stronger economics and a better experience for the end user.

The Neighborhood and Syndicate alignment in practice means: when chains grow, builders thrive, data and chain infra scales, and value flows back to the communities creating it. If you are a team building an appchain on Syndicate or a builder in need of Syndicate or appchain data reach out to us. We both support you with our $SYND stake and our data infra.


---
title: Introducing: The ENS Profile API
url: https://www.indexing.co/articles/introducing-the-ens-profile-api
description: A free, public GraphQL API for accessing ENS profiles, including addresses, text records, and content hashes without signup or tracking.
date: 2022-12-28
image: /assets/articles/introducing-the-ens-profiles-api.png
author: runninyeti.eth
tags: Announcement
---

Here at Indexing Co we’ve been spending the holiday season onboarding our first customers and getting our infrastructure into production 🎉 And as a holiday gift for web3 builders, we’re releasing our ENS Profile API to the public. No sign up required, no tracking, and completely free. Seriously!

This is the same API that powers our ENS Profile search tool, [What’s my name again](https://www.whatsmynameagain.xyz), and is backed by our real-time indexing engine. You can access it via GraphQL at `https://query.indexing.co/graphql` with the following schema:

```
type ENSProfileAddresses {
  address: String
  coinType: Int
}
type ENSProfileAttributes {
  textKey: String
  textValue: String
}
type ENSProfile {
  addresses: [ENSProfileAddresses!]
  attributes: [ENSProfileAttributes!]
  contenthash: String
  name: String
  node: String
  owner: String
  tokenId: String
}
input ENSProfileFilter {
  name: String
  node: String
  owner: String
  textValue: String
  tokenId: String
}
type Query {
  ensProfiles(filters: ENSProfileFilter): [ENSProfile!]!
}
```

For example, to grab the current profile for `vitalik.eth` you could simply do:

```
query {
  ensProfiles(
    filters: {
      name: "vitalik.eth"
    }
  ) {
    addresses {
      address
      coinType
    }
    attributes {
      textKey
      textValue
    }
    contenthash
    name
    owner
  }
}
```

Which would return:

```
{
  "data": {
    "ensProfiles": [
      {
        "addresses": [
          {
            "address": "0xd8da6bf26964af9d7eed9e03e53415d37aa96045",
            "coinType": 60
          }
        ],
        "attributes": [
          {
            "textKey": "avatar",
            "textValue": "eip155:1/erc1155:0xb32979486938aa9694bfc898f35dbed459f44424/10063"
          },
          {
            "textKey": "url",
            "textValue": "https://vitalik.ca"
          }
        ],
        "contenthash": "0xe3010170122081e99109634060bae2c1e3f359cda33b2232152b0e010baf6f592a39ca228850",
        "name": "vitalik.eth",
        "owner": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045"
      }
    ]
  }
}
```

---

Give it a try and let us know how it goes! And if you find yourself needing anything extra / different, don’t hesitate to reach out - we’re always looking for ways to improve our offerings and empower the builders in web3.


---
title: Accessing Data 3.0: Storage Options
url: https://www.indexing.co/articles/accessing-data-3-0-storage-options
description: A guide to decentralized storage solutions in web3, comparing IPFS, Filecoin, Arweave, and Storj for different use cases.
date: 2022-09-29
image: /assets/articles/accessing-data-3-0-storage-options.png
author: runninyeti
tags: Post
---

_This is an entry in our long running series, “Accessing Data 3.0”, where we talk about the “whats” and the “hows” of working with data in web3. Enjoy!_

There’s an often forgotten question in Data 3.0 - where do we actually put all our large data? That image of your favorite cat, videos from the last family trip, the unpublished book you’re working on - what is “home” for all that data? It’s easy to think “well if it’s web3, then it must be on-chain”, but that’s not always true, nor does it need to be! There’s a whole, growing world of decentralized data that has no tie back to a blockchain.

![](https://www.moneyunder30.com/wp-content/uploads/2021/05/nyan-cat.gif)

The simplest explanation is that putting data on-chain is expensive. Blockchains are, well, chains of “blocks”. Each of those blocks has a set of transactions, which in turn can include some amount of data. Each server participating in the network must then store _all_ data for the blocks they help decentralize. For example, in Ethereum the default for many servers is to store the last one year of blocks. Furthermore, all data added to a block gets hashed to secure the given blockchain. The combination of these two requirements leads to limits on the amount of raw data within a block. This in turn creates a competitive effect for “block space”. Resulting in web3 users having to pay fees in correlation to the total number of users (often referred to as “gas”).

Now, it’s important to circle back to that “large” term we used at the beginning. What is does it mean to have a large piece of data? Take for instance the data required to reference moving funds from one account to another. This is often measured in a unit called “bytes” and is plenty small enough to keep on-chain. After all, this is the original use case blockchains! As you move into say a school paper though, you begin measuring data in “kilobytes”, or thousands of bytes. An image often runs into “megabytes” (millions) and videos get well into the “gigabyte” (billions) range. As a web3 user, it’s safe to assume that anything measured in more than bytes is too large. It's either impossible to store on-chain (due to block limits) or it's too expensive to do so.

#### Soo, where do we store all those cat photos then?

Thankfully, the innovation in Data 3.0 hasn’t left us high and dry. Let’s take a look at a few of the popular solutions for storing “large” data today:

#### IPFS

<https://ipfs.io/>

The Interplanetary File System is a free, “peer-to-peer” protocol for decentralizing data. IPFS was one of the earliest adopted solutions for storing data in web3 and continues to be a favorite for many. Getting started is easy (they even have a browser extension!) and the broader network improves the more users it has.

That reliance on adoption has been both a defining factor and a sort of achilles heel for the project. Users are only required to store data that they actually want to use themselves. For instance, there’s likely no \[good\] reason for me wanting to store _your_ family videos, and so I won’t. But! if a meme is going viral and shared via IPFS, then every single viewer of that meme would also be sharing that data. From a practical perspective, this makes IPFS decentralized, but only temporarily so. In short, IPFS provides an easy, decentralized way to share data with others who want it.

Explore the desktop application and other ways to get started [here](https://docs.ipfs.tech/install/ipfs-desktop/). Or try out a hosted “pinning” provider like [Pinata](https://www.pinata.cloud/).

#### Filecoin

<https://filecoin.io/>

Also built by [Protocol Labs](https://protocol.ai/), Filecoin aims to solve the "temporary" nature of IPFS by providing "contract-based" storage. Servers offer their storage capacity to the network and users pay to host their data for a fixed period of time. Fees get determined by the size of the data stored and the length of the “contract”. This storage market is then powered by a dedicated blockchain and currency, [$FIL](https://coinmarketcap.com/currencies/filecoin/).

And behind this marketplace, the servers paid to store your data are all doing so via IPFS. That means that adoption of Filecoin is also adoption of IPFS.

Check out [web3.storage](https://web3.storage/) or [Fleek](https://fleek.co/storage/) to explore early consumer applications for Filecoin.

#### Arweave

<https://www.arweave.org/>

Much like Filecoin, Arweave has a storage market with a dedicated blockchain and token ([$AR](https://coinmarketcap.com/currencies/arweave/)). Rather than doing fixed term contracts though, Arweave promises _permanent_ data storage. One upfront fee, storage forever.

Arweave accomplishes this permanence by gamifying data storage (details in [the yellow paper](https://t.co/LMxwLjtcVN)). Each server of the network can choose to store whatever data they want. For instance, they could avoid storing illegal content by censoring what's stored. But those servers are also incentivized to store data that isn’t sufficiently decentralized. In other words, it's worth more to store data decentralized to only a few servers vs thousands. And over the span of the network, this results in _all_ data always stored.

Check out their [ArDrive](https://app.ardrive.io/) to give it a spin.

(fun fact - this blog is hosted on Arweave via [Mirror.xyz](https://mirror.xyz/))

#### Storj

<https://www.storj.io/>

Storj is another competitor in the web3 storage space, but focuses on developers. It boasts full compatibility with [AWS](https://aws.amazon.com/) S3 so most developers can leverage decentralized storage out of the box. The end result being fast, reliable cloud storage that's also decentralized.

In general, servers in solutions like Filecoin and Arweave are only rewarded if they store the _full_ chunk of data (e.g. an image). Storj is different. It takes a given chunk of data, encrypts it, and then shares smaller pieces with its network of servers. When a user wants to retrieve data, only 29 of those pieces are required to reconstruct the full chunk of data.

In this way, servers are incapable of being aware of the data they’re storing. This in turn allows Storj to control data at a network level; optimizing for speed and privacy along the way.

Storj does have a [hosted interface](https://us1.storj.io/signup) for consumers to leverage their network. And of course there's [documentation for developers](https://docs.storj.io/dcs/) to get started as well.

## What should I use?

![](https://media.giphy.com/media/WsNbxuFkLi3IuGI9NU/giphy.gif)

Here’s the skinny on when to use different Data 3.0 storage solutions today:

1. IPFS - free, easy to use, and temporary file sharing

2. Filecoin - fixed-length storage for a fee

3. Arweave - permanent storage for an upfront cost

4. Storj - developer-centric alternative to AWS S3


---
title: Block by Block Ep. 9 – Why Blockchain Gaming Fails (at Economy Design)
url: https://www.indexing.co/articles/block-by-block-ep-9-why-blockchain-gaming-fails-at-economy-design
description: Block by Block podcast episode with Chase Sommer.
author: Dennis
date: 2026-05-11
image: https://dbffdfcgucdezodnkido.supabase.co/storage/v1/object/public/content-images/bfe89282-7708-4676-b967-6d1613513f0c/7cc6bd06-32c5-4552-b375-a888bd97e7c1.png
tags: Podcast, Block by Block
---

Most blockchain games fail before they even launch, not because of tech limitations, but because they're trying to build functioning economies without understanding game design fundamentals. Chase Sommer, who's building at the intersection of MMO development and blockchain, breaks down why the industry keeps getting it wrong and what it would take to actually get it right.

**What We Cover:**
- Why combining MMOs, blockchain, and economy design is "hard mode" for game development
- The fundamental flaw in pay-to-play tokenomics and why it attracts farmers instead of gamers
- How player-to-player economies differ from pay-to-win models (and why it matters)
- Token sink mechanisms: item destruction, soul-binding, and repair costs as economic design
- Why grassroots teams might succeed where VC-funded studios are failing
- How AI is enabling solo developers to build games that previously required full studios
- The onboarding problem: why embedded wallets and abstracted tech are non-negotiable
- What a breakthrough hit would actually look like (hint: it has to be good without crypto)

Chase brings a rare perspective—web2 game dev experience meets web3 experimentation—cutting through the hype to focus on what actually works. If you're building in gaming, working on virtual economies, or just tired of hearing about the next overfunded game that goes nowhere, this one's for you.

**Guest:** Chase Sommer [(@SommerChase)](https://x.com/SommerChase)

**Host:** Dennis Verstappen [(@ape_rture)](https://x.com/ape_rture)

**Podcast:** Block by Block | The Neighborhood by Indexing Co

### Guest + Links
- [Chase Sommer on X](https://x.com/SommerChase)
- [Chase Sommer on Youtube](https://www.youtube.com/@chasesommer)

### Hosted by The Indexing Company
- [Dennis](https://x.com/ape_rture)
- [Website](https://indexing.co)
- [Docs](https://docs.indexing.co)
- [X](https://x.com/indexingco)

---

## Listen & Watch
- [Watch on YouTube](https://youtu.be/QP4bvdHR9yU)
- [Listen on Spotify](https://open.spotify.com/episode/3ZQcnKfQIIn318rqzVWLdG?si=a87395ccb42447ee)


---
title: Indexing for Interoperability: Modular Chains
url: https://www.indexing.co/articles/indexing-for-interoperability-modular-chains
description: Recently the term modular has gotten a lot more attention in the world of blockchains.
author: Dennis Verstappen
date: 2024-10-18
image: /assets/articles/indexing-for-interoperability-modular-chains.avif
tags: Post
---

In the recent year the term modular has gotten more attention in crypto. Modular chains aim to solve the scalability trilemma. The trilemma claims that a blockchain can only have two of the following three features: decentralization, scalability, security. Modular chains try to solve this trilemma by separating blockchain functions into distinct components. Each component can be picked by developers to optimize for their chain needs, whether that is building a new L1, L2, L3 or dApp-chain. The components are:

- Execution layer: processes the transactions and computes state changes

- The Consensus layer: ensures the agreement on the order and validity of transactions

- The Settlement layer: provides finality and security guarantees

- The Data Availability layer: ensures that transaction data is accessible to network participants

While data availability is crucial for the operations of the network participants, it only addresses the needs of those inside the network. When data needs to be available outside of the network for triggers on user interfaces, activity on other chains or analytics, indexing needs to be done to retrieve that on-chain data and make it available elsewhere. This article explores how The Indexing Company is building a data marketplace to meet the unique challenges and opportunities presented by modular chain architectures. The article should be relevant for various modular and interoperability chains and protocols like Celestia, Avail, Cosmos, the Superchain (the chains building with the OP Stack), etc.

#### Indexing Chains With different Virtual Machines

Since data lives on multiple chains, developers need to connect to multiple RPCs to get that data. These RPC endpoints can be different because every VM can be different. For example the Ethereum Virtual Machine (EVM) chains already can have different types of RPCs, which results in data having varying features or structures. The differences become even more clear when you add other VMs to the mix like the Solana Virtual Machine or the Move Virtual Machine. These differences come in the form of the language, speed, data structures, on-chain storage, etc. This is one of the reasons why most indexers and data providers focus only on the EVM chains, which leaves a (upcoming) part of the market underserved in their data needs. Since the infrastructure from The Indexing Company takes the data in raw form we can cache that data as a chunk (most cases this is a block) and then look for any data in that block without any assumptions on that data or the contents. This architecture design allows fast onboarding of new chains regardless of their VM, but also ensures fast processing of the data from RPC endpoint to database.

#### Modular Data Pipelines

Typically developers working in a modular stack will ingest data from multiple chains, which means that for these developers merging data from multiple chains will be essential for their dApps and protocols to function. Merging this data normally would be a hassle because either this comes from multiple sources or various data models have to be transformed into a desired model. In The Indexing Company products we strive to make this process as easy as possible since even developer tools should have a good UX. When ingesting the raw data from a single chain or multiple chains, there is no model being applied. Since the starting point is always that raw data, the data can be transformed freely into a desired format. The data pipelines The Indexing Company is building and the new Console give developers the freedom to express their wishes regarding the resulting data model without having to worry about the format of the raw data. Transformations and templates can be applied to get the desired data quickly. The data pipelines deployed are not static either, since configurations can be altered on the fly by calling APIs. For example if additional contracts or events have to be indexed (backfill and real time) the API could be called to add this new data.

The configurability does not stop only with adding data from a single chain. For example a developer can create a unified schema across chains or filter out data only relevant for their application. In addition, developers who already have a pipeline running for a chain, can easily deploy that pipeline for additional chains if they want to expand their product. This unique approach reduces tedious data engineering work done by the developer, while also reducing data processing time and processing/storage costs.

Even when raw data is being used as a starting point, the Console and the broader Data Marketplace can provide templates made by The Indexing Company or developers themselves. For example, these templates could be configurations for getting data from DEXs, specific protocols or NFT/ERC20 transfers. Applying these templates makes it easier for developers to quickly configure the data, since they could filter on specific contracts, ERC20s or NFTs (etc.) to get more granular data. Roll-up as a Service (RaaS) providers could also add easy and 1-click indexing to their offering, since data pipelines could be spun up automatically and get specific templates automatically applied.

Eventually the Data Marketplace will unlock various templates and even re-selling of data by developers. The blockchain data itself is neutral, but developers and companies can have an opinion on that data and how that is processed. Their work and expertise will unlock new datasets, metrics and context that comes from and can be merged with blockchain data. The marketplace will enable other companies to provide their data, while others can tap into that expertise and ingest that data.

#### Conclusion

Modular chains are reshaping the blockchain landscape, while they also introduce new challenges in data availability and indexing. The Indexing Company addresses these challenges head-on with our flexible, VM-agnostic data pipelines. Our approach enables developers to easily work with data across multiple chains, reducing complexity and costs.

As the modular ecosystem evolves, robust data infrastructure will be crucial. At The Indexing Company, we're committed to empowering Web3 businesses with next-generation indexing solutions. Ready to optimize your blockchain data strategy? Contact us to explore how we can support your project in this new era of modular chains.


---
title: Block by Block with Rysk Finance
url: https://www.indexing.co/articles/block-by-block-ep-5-rysk-finance
description: DanDeFiEd from Rysk Finance joins us to break down how Rysk achieved real product-market fit in on-chain options.
date: 2025-12-29
tags: Podcast, Block by Block
link: https://x.com/indexingco/status/2005664388045209929
---


---
title: Subgraphs Suck: Crypto Data Infra is Changing
url: https://www.indexing.co/articles/subgraphs-suck
description: It's time to love your data again
author: Dennis Verstappen
date: 2025-12-30
# image: /assets/articles/subgraphs-suck-old.png
tags: Post
---

In the early days of DeFi somewhere after 2017, Ethereum needed an upgrade to query data. Subgraphs were a breakthrough. Nobody wanted to run their own indexing infra and database just to power their frontends. Subgraphs offered the resolution: define a schema, write mappings, deploy and query through GraphQL. The first wave of DeFi and other dApps used Subgraphs to power their data infra and frontends. Crypto has changed and Subgraphs can’t keep up with the needs of builders. Chains are faster, we have more chains (and will get exponentially more), we have different VMs. How did we get here and how do we move to better data infra for crypto builders and companies?

Note that when I say Subgraphs in this article, most of these problems apply to Substreams too. These are just database syncs from Subgraphs and thus inherit the underlying problems.

## Why Subgraphs Made Sense

Ethereum between 2017 and 2020 was smaller, with lower onchain activity, less protocol complexity and real-time analytics were underappreciated. Most applications only needed to have a read-layer to surface contract state. Teams were less bothered with engineering data pipelines, warehousing, streaming, reliability and were mostly on a single chain. Subgraphs made builders avoid data engineering in their own databases and templates were readily available through The Graph. Forking a protocol was very common and thus also the Subgraph was forked to save on developer time. Even if performance from The Graph's Subgraphs was sub-par, other companies (like Goldsky) would take the management out of users hands.

Subgraphs spread widely and became the default for developers. They weren’t adopted because they were the best solution, but they were readily accessible and developers took short cuts in data engineering.

## Crypto Evolves, Subgraphs Do Not

Today crypto is fundamentally different. We have an explosion in the number of chains, dAppchains, subnets. We have various alternative VMs like Solana VM or Move VM (with their dialects). The block times of chains are getting way lower and the volume of data goes up. These are all signals the market is maturing, is specializing and is getting adopted.

The needs change from developers since not only contracts need to be read out from the blockchain, but data from wallets, blocks, individual transactions and networks too. Instead of only powering an interface or a simple dashboard, good indexers and pipelines are now essential in on-chain trading, risk-modeling, compliance, fraud detection, user analytics, business intelligence, etc. Indexing infrastructure and tooling needs to support all use cases.

![](/assets/articles/subgraphs-suck-old.png)

At the core of the problem is Subgraphs design. Subgraphs can’t keep up by being contract-centric, while Subgraphs combine the actual indexing logic, database structure and the storage in one product:

- When data volumes increase, Subgraphs lag behind the chain head and latency increases.
- When mappings or contracts change, developers are forced to re-index. For The Graph this could be painstakingly slow, so various providers would make improvements. A bandaid solution to fix the symptoms, not the underlying problem.
- Subgraphs are single chain and thus developers from multichain projects are forced to maintain multiple databases for similar data.
- Subgraphs are optimized for EVM, leaving other VMs underserved.
- Being a closed off database, only specific data can be collected with limited control over the actual database. If pipelines need to merge in other data (offchain, metadata, user data) first data has to be recollected and re-transformed.
- Lock in with GraphQL. A very specific query language (not at all used for single data sources) is used to query the data. While developers might have a need for other query languages or a query language normal functioning humans like to use like SQL.

I’ll stop there. This list is long enough. Sadly there is more, but I can’t leave you with nightmares. The result is slow dashboards, products stalling, revenue or usage loss and even exploits.

## Why TF are Developers Still using Subgraphs?

First of all, familiarity. Developers are used to these Subgraphs in early development, even if it hurts them later. Forks are still frequent in crypto, which leads to building on outdated assumptions. Furthermore, crypto teams might lack expertise in data engineering or lack time to build out better solutions. Even attempts to modernize the model with Substreams fail because they expose the same flaws. Streams do not solve composability, transformations, unification of data and still works contract based.

Various major businesses are built on top of servicing Subgraphs to builders, which creates an illusion crypto data is supposed to be excessed while most of these businesses are mostly painkillers for the pain of handling Subgraphs, not an improvement of the Subgraph infra. Add to this hackathon sponsoring, which then gives early builders a lock in and early education on deprecated solutions.

Luckily most of these businesses and even The Graph itself are sunsetting Subgraphs, researching new solutions, pivoting to other data infra services (even out of indexing) or deploying more modern products. Read through some of the newer product releases (like The Graph Amp) and read between the lines. You’ll find a change in infra and wording. Alchemy for example [sunsets the Subgraph](https://x.com/whoislewys/status/1988041902240002126?s=19) business as a whole.

## The Next Generation of Crypto Data Infra

The industry has a need for systems that treat blockchains as high-volume, high-throughput and high-resolution. Data streams need tooling that can filter, transform, decode for any business need. Instead of only contract-focussing, the focus has to expand to wallets, transactions, trades, blocks, cross-chain flows, liquidity movements, metadata and network-level statistics.

The feature list for better solutions includes:

- Streaming instead of polling
- Separation of sourcing and computation from storage
- The ability to reprocess and alter pipelines without re-indexing or restarting the infra
- Analytics- and query-ready outputs instead of predefined and raw tables
- Filter, decoding and transformation options to create the desired schemas and unlock unification across chains and even VMs
- Multi-chain pipelines
- Scalability to ensure throughput
- Performance to support real-time use cases

![](/assets/articles/subgraphs-suck-new.png)

Crypto is scaling, which requires the data infra to scale with it. I’m happy to be building towards better solutions with Indexing Co on both our Pipelines, The Neighborhood and dedicated data infra, while also applauding new developments from parties like The Graph (with Amp) and SQD (with Portal). My goal with this article is not to show the market who has the better solution. The better solution will vary based on the actual product being built and needs from a business. With better and a bigger variety of solutions we can see builders finding the data infra for their product and workflows. The future will hold both more specialized and more generalized solutions that help builders deploy faster, save on development time and increase revenue because of the underlying data infrastructure being more performant.

Subgraphs Suck. [It's time to love your data again.](https://www.indexing.co)

<style type='text/css'>
#top-nav, footer {
display: none;
}

body {
padding: 4rem 2rem;
}
</style>


---
title: Indexing Chainlink's Price Oracles
url: https://www.indexing.co/articles/indexing-chainlink-price-oracles
description: A guide to indexing Chainlink price oracles and transforming the data into useful metrics like moving averages and spot prices.
date: 2023-01-30
image: /assets/articles/indexing-chainlink-price-oracles.png
author: Stephen King
tags: Guide
---

## Introduction to Chainlink and Its Significance

![](https://images.mirror-media.xyz/publication-images/5qxPpCYFBzut35aQesuxt.png?height=396&width=1174)

Chainlink is one of the most ambitious projects in web3, providing everything from price oracles to external API adapters. With the ability for anyone to easily connect to any web or off-chain API and use it as an input or output for smart contracts on the blockchain, Chainlink has become a go-to for many organizations in the crypto industry.

At the Indexing Company, we love Chainlink and indexing systems, so we decided to index their price oracles and run them through our transformation engine.

## Understanding Chainlink's Price Oracles

First, let's cover the basics. What are Chainlink's price oracles, and why are they important for the crypto industry?

In the simplest terms, a price oracle is a source that provides up-to-date, real-time pricing data to software running smart contracts on a blockchain network. It can be compared to stock exchange tickers of companies in the past that supplied real-time pricing data to people. Without accurate and reliable sources for crypto prices, smart contract software would not be able to execute correctly.

Chainlink's price oracles offer a reliable alternative to traditional methods of data collection and market assessment. The decentralized, secure protocol provides access to a range of leading sources that can be used to make informed price predictions. Prices are managed via an open-source aggregation algorithm, which minimizes the risk of falsified or inaccurate results.

This is extremely beneficial compared to other price oracle solutions on the market, as it ultimately reduces the need for manual response checks and lowers financial exposure in potential errors. Chainlink's security data privacy and compliance measures also maintain top-level protection against external threats such as hacking and performance issues, giving users confidence in their pricing decisions.

## The Technology Behind Chainlink's Price Oracles

Chainlink's Price Oracles aren't just a manifestation of advanced technology, they also embody a system of record that's been painstakingly curated for its reliability and seamless functionality. By engineering this intricate system, Chainlink ensures that the transaction data it sources maintains a high level of accuracy. The superior infrastructure underpinning Chainlink's Price Oracles plays a pivotal role in their operation, making them an invaluable asset within the broader cryptocurrency ecosystem.

## Chainlink's Decentralized Data Aggregation

Chainlink has harnessed the power of decentralized data aggregation to fortify the reliability of its price oracles. This method dramatically enhances data accuracy and reliability, providing an unimpeachable source of information for users. The decentralized nature of blockchain data aggregation serves as a buffer against data manipulation, further strengthening the credibility of the data Chainlink oracles deliver.

## Chainlink's Oracle Reputation System

To ensure the consistent performance of its network, Chainlink has implemented an Oracle Reputation System. This system objectively evaluates the performance of various oracles, assigning ratings based on reliability and accuracy. These ratings offer valuable insights into the quality of data each oracle provides and directly contribute to the overall performance and credibility of Chainlink's network.

## Data Quality and Chainlink

In the realm of operations of price oracles, data quality is non-negotiable. Chainlink has established stringent protocols to guarantee high-quality data from its price oracles. By placing an unwavering emphasis and focus on data quality, Chainlink sets a high standard for the reliability and usability of the data it provides.

## Understanding Price Oracle Attacks

The cryptosphere is not immune to security concerns and challenges, and price oracle attacks are one such issue that warrants attention. These attacks can have significant implications for the integrity of a blockchain network, reinforcing the importance of Chainlink's commitment to security and robust design. By understanding these attacks, we can better appreciate the safeguards Chainlink has in place to prevent such vulnerabilities.

## Chainlink's Role in the DeFi Ecosystem

Chainlink's price oracles have carved out a pivotal role in the burgeoning DeFi ecosystem. As a key player in the DeFi landscape, Chainlink has made significant strides in enhancing the reliability and accessibility of decentralized financial services. Its influence and importance in shaping the DeFi market are unequivocal, marking it as a game-changer in the world of decentralized finance.

## The Process and Advantages of Indexing Chainlink's Price Oracles

So, why index Chainlink's price oracles?

By indexing Chainlink's price oracles, we can configure the Indexing Company's transformation engine to generate some interesting data points.

![Litecoin](https://images.mirror-media.xyz/publication-images/ZKW7AcG5QeUSyuG6Qr6kb.png?height=376&width=588&size=medium)

First, we indexed the feeds and merged labels (e.g. ETH/USD) to compare and contrast price data. Next, using real time data we ran different transformations to get things like spot, 1-day, 7-day, 15-day, and 30-day moving averages. Lastly, to visualize the above data points, we exposed an API via GraphQL and routed it into ReTool.

<https://indexingco.retool.com/embedded/public/49529312-e961-455a-8e76-a298e730b8c0>

![](https://images.mirror-media.xyz/publication-images/c_TTZOGkdmAcWRE83oO2y.png?height=152&width=1110)

![](https://images.mirror-media.xyz/publication-images/26ELGLKC5X1jzGHNqcyPM.png?height=580&width=1216)

## Testing and Comparing with Traditional Exchange

Test it yourself!

You might ask yourself, "I can already get this data on Coinbase. What's the big deal?"

The difference is in how the data is obtained and disseminated. for example, Exchanges like Coinbase get crypto prices by matching buyers and sellers in transactions on their platform, and the prices on the exchange reflect the supply and demand of the crypto assets being traded on that particular platform. The prices of crypto assets on different exchanges can vary due to differences in trading volume, order book depth, and other factors.

Chainlink price oracles, on the other hand, obtain crypto prices from multiple, decentralized data sources, such as other decentralized exchanges (DEXs), off-chain data aggregators, and oracles. The Chainlink network is decentralized, meaning that it is a distributed ledger not controlled by any single entity or organization, making it resistant to manipulation and tampering. The Chainlink network uses a consensus mechanism to ensure that the data provided by the oracles is accurate, and it uses smart contracts to ensure that the data is tamper-proof.

If the goal of web3 is decentralization, using tools like Chainlink's price oracles is pivotal.

## Upcoming Advancements and Opportunities in Blockchain Data Indexing

We're finishing documentation this week then we'll make the current version of the API publicly available to developers (for free!)

The above exercise, in addition to whatsmynameagain.xyz and mirrormirror.page, are examples of what can be created with The Indexing Company's technology. Our mission is to provide the infrastructure so you can become the data company or surface to your business, partners and end users.

Email us today at [hello@indexing.co](mailto:hello@indexing.co), and we'll get you set up with your own configurable indexers and transformations to create fun tools like this.

Final Thoughts

The indexing Chainlink's price oracles facilitates digital transformation by leveraging advanced technologies like artificial intelligence and multiple blockchains. This process generates valuable data points, enabling informed decision-making and enhancing the reliability of blockchain data. By utilizing decentralized data aggregation, Chainlink's price oracles play a crucial role in the decentralized finance (DeFi) ecosystem, providing reliable and accessible pricing information. This advancement opens new opportunities and drives innovation in the evolving landscape of DeFi and beyond.

At The Indexing Company, we're excited to contribute to this journey by offering our indexing technology to enterprises around the world. As we look forward to what's next, we're not just observers; more than a decade in we're active participants shaping the future of data in a decentralized world. Join us on this journey - the future of data awaits you.


---
title: Control Your Data; a Dicso and Indexing Co Case Study
url: https://www.indexing.co/articles/disco-control-your-data
description: How Disco leveraged Indexing Co's Just-In-Time Indexing to power their identity protocol, enabling users to control their multi-chain data.
date: 2024-10-07
author: Dennis Verstappen
image: /assets/articles/disco-control-your-data.png
tags: Case Study
---

Crypto has the unique characteristic of putting the user back in control of their own data, which enables the opportunity for data to be made available wherever the user goes. This context - in which the subject of data has the most control over its data - is often described as Self-Sovereign Identity.

The user determines their on-chain identity, controlling which data and assets can be provided to other parties, alongside off-chain data created throughout their digital journeys. Managing, and even viewing, all this data from various chains and digital platforms can be a tedious task. Identity protocols like Disco have the vision that users can consolidate their online presence into a logically centralized, physically decentralized data package, controlled with their existing wallet.

Data indexing and methodology is critical to this identity layer. Most businesses in crypto struggle with accessing and organizing complex multi-chain data, spending valuable time and resources on building indexers, data engineering and constructing data pipelines. The Indexing Company is of the opinion that crypto businesses would be able to provide more value to users when focusing on their expertise and not worrying about indexing and its associated challenges. In our collaboration with Disco, they could fully focus on building the future of seamless access, instant rewards and all of the other fun parts of the on-chain world enabled by our unique identities. With Disco, over a million users had a product where they could have control over their data and have privacy when preferred. To expand the utility for users to express their online identity, Disco was acquired by [Privado.ID](https://www.privado.id/). The complementary teams join forces to build an identity network providing next level utility for users, enterprises and governments. The Indexing Company is happy to support this newly formed team in their future ventures.

## The Setup

The process started by understanding which types of data are the most important to users. For example, Disco used specific data from chains like Ethereum, Arbitrum, Optimism, & Base, like significant tokens and NFTs. The dataset scaled to accommodate popular queries over time. The Indexing Company’s unique data pipelines can fetch data from any chain while also making it possible to fit this data into a single unified data schema. Such transformations helped Disco with building a data model from which they easily expanded the number of chains or on-chain assets indexed. The data was directly streamed from the RPCs to Disco’s database reducing latency and ensuring data quality for both Disco and the end user.

The Indexing Company gives projects working with the data pipelines ownership over their data. Since the public RPC data was streamed directly to Disco’s backend all data was fully composable for application in products and redistribution in numerous forms.

## Just In Time Indexing

Disco's user base continuously expanded as more crypto users recognized the value of their own data. This growth presented challenges in data retrieval, as such a system must integrate historical data for new users while simultaneously accommodating incoming data. Historically, projects had to index entire chains, incurring high processing and storage costs, despite only a small fraction of the data being relevant to their users. Drawing from experience, The Indexing Company recognized the impact of this industry-wide problem and developed Just In Time Indexing (JITI). JITI enables getting both historical data and real-time data whenever the data is needed. For Disco, this involved invoking the indexer with a wallet address, which triggered JITI to perform a targeted backfill of all historical transactions. It also ensures data remains current by monitoring new transactions for those wallet addresses in real time. All chain and top token/NFT holdings were served to current and new users whenever they wanted to use Disco. At the peak of our collaboration, Indexing Co. processed data from more than 1.2 million wallets for Disco using JITI.

![](/assets/articles/disco-jiti.jpg)

## Contextual data

Without context, on-chain data is hard to access, interpret and use. On-chain data consists mostly of numbers and contract addresses which do not tell you basic information on the protocol or user. For users, this is a positive feature creating pseudo-anonymity, but for interpreting data around which protocols are being used, it creates a problem for analysts who are trying to create valuable insights for their business and users. For Disco, understanding the platforms and actions users engaged with enriched the context in their Data Backpack. Disco users had the option to carry this valuable information with them to new platforms and to expose which data they wanted. The Indexing Company is continuously grabbing labels from various data sources. First, various data platforms like Etherscan and Dune provide labels. Second, on-chain logic can be used to generate labels. For example token-meta data and factory contracts can be indexed to automatically label Uniswap pools. When this data is matched with on-chain activity we can see if a user is a Uniswap user and which types of tokens they swap. This logic can be applied to a variety of (DeFi) protocols to get a better understanding of transactions. Through an iterative process where analysts and developers from both Disco and The Indexing Company continued to collaborate, more labels and contextual information were gathered over time.

## Control your data

Disco and The Indexing Company found each other in the value that you should control your data. Disco users benefitted from taking control over their data through the Data Backpack, while the raw blockchain data was fully owned for free analysis by Disco themselves. The Indexing Company is happy to support builders like Disco in their journey to bring a better user experience in crypto. Our work enables businesses to focus on what actually matters: their product. We wish the Disco and Privado.ID team good luck in the next iteration of building their vision: a complete multi-chain, multi-device identity protocol for every user.

[Get in touch](mailto:hello@indexing.co) with us to see how we can help build your data infrastructure so you can focus on building user-centric products. Your data, your way.

---

Read the original post [here](https://theindexingcompany.substack.com/p/control-your-data-a-disco-and-the)


---
title: Introducing: What's My Name Again?
url: https://www.indexing.co/articles/introducing-whats-my-name-again
description: A free search engine for ENS profiles that allows users to find ENS names by email, text records, or wildcard patterns.
date: 2022-10-26
image: /assets/articles/introducing-whats-my-name-again.png
author: runninyeti.eth
tags: Announcement
---

We’ve talked previously about Ethereum Name Service and how to get started with your own ENS name ([original post here](/articles/ens-a-practical-guide)). In that post we touched very briefly on the concept of _text records_ and being able to tie information beyond a wallet address to your ENS name. By adding data points like email addresses, avatars, Twitter addresses, etc to an ENS name, we can effectively start crafting what we’ll call an “ENS Profile”.

Because these profiles are stored on-chain, they’re publicly accessible yet fully controlled by **you**, the owner. We could compare this to Facebook or Twitter profiles, but without the ads, centralized control, and authentication requirements that these platforms require in service of their bottom line. In short, the potential power of ENS Profiles is enormous.

One thing that’s been missing though is the ability to _search_ these profiles. Sure, tools like [ens.domains](https://ens.domains/) and [ens.vision](https://www.ens.vision/) exist, but these are focused on managing and purchasing ENS names, respectively. Neither service is intended to help ENS users communicate with one another or use the power of a “profile”.

Meanwhile, we’ve been working hard at The Indexing Company to build out our Indexing as a Service infrastructure. Recognizing the recent adoption of ENS and being long-time supporters ourselves, we decided to tune our indexing service towards ENS. As a result, we’re happy to introduce [What’s My Name Again?](https://www.whatsmynameagain.xyz/) 🎉

This is a freely available service to search both ENS names _and_ entire ENS Profiles. Some examples:

- [Wildcard name matches like nick\*.eth](https://www.whatsmynameagain.xyz/#nick*.eth)

- [ENS name by email](https://www.whatsmynameagain.xyz/#hello@indexing.co)

- [ENS names with Mirror.xyz links](https://www.whatsmynameagain.xyz/#*mirror.xyz*)

- [Who wants to be contacted?](https://www.whatsmynameagain.xyz/#*contact%20us*)

- [Anyone putting "coffee" on-chain](https://www.whatsmynameagain.xyz/#coffee)

(hint: searches _not_ starting with a wildcard, `*`, are much faster!)

![](https://images.mirror-media.xyz/publication-images/KqVcKrxpXTj8Et1QZC_tY.png?height=2334&width=3824)

Give it a whirl and let us know what you think!


---
title: Indexing Mirror.xyz
url: https://www.indexing.co/articles/indexing-mirror-xyz
description: A technical guide on how to index Mirror.xyz content from Arweave, including code examples for fetching and parsing posts.
date: 2022-09-30
image: /assets/articles/indexing-mirror-xyz.png
author: runninyeti
tags: Announcement
---

If you read content online you’ve probably at least heard of publishing services like [Medium](https://medium.com/) and [Substack](https://substack.com/). These are centralized, web2 companies that make money with views; subscriptions, ads, etc. Thankfully, as we transition into the web3 space we are already seeing some promising alternatives. The largest of these web3 publishers is [Mirror](https://mirror.xyz/).

The beauty of protocols like Mirror is that they don’t _own_ any of the data. They still have a login, a clean text editor, and shareable links just like Medium or Substack. But the content that flows through Mirror is entirely decentralized on a network they don’t control, [Arweave](https://www.arweave.org/). We’ve spoken briefly about Arweave [previously](https://mirror.xyz/indexingco.eth/FDyv8i8c15ATs_KIpAtEdeMP20WZ00FfssPYOj3EZRY), but the gist is that any content stored on it is stored _forever_ thanks to unique incentive models built into the network. This has two important ramifications:

1. There are 0 paywalls in Mirror. You can still _choose_ to support individual creators, and Mirror helps facilitate this, but it’s entirely optional.

2. You don’t even have to use Mirror to participate in the broader ecosystem.

That second point is what we’re going to focus on in this post. Specifically, because the data is freely available forever, we can choose to use this data in any way we want. For instance, this very blog post is available on [Mirror](https://mirror.xyz/indexingco.eth/iuT8DiYiDTq5lcx1JxOgQ8g9hn9hsnRJZVynFiHzrPk), but it’s also available on our [company’s website](https://www.indexing.co/articles/iuT8DiYiDTq5lcx1JxOgQ8g9hn9hsnRJZVynFiHzrPk). Any updates to this post are instantly available on both sites because they both use the **exact same data source**, Arweave. Let’s unpack this a bit:

1. Content is written in an editor such as Mirror

2. That content is added to a transaction on Arweave

3. A user visits a related link on _either_ mirror.xyz or indexing.co

4. The site fetches the content from Arweave, formats it, and displays it to the end user

5. Content is shared from creator to reader

![](https://media.giphy.com/media/WoWm8YzFQJg5i/giphy.gif)

## The Nitty Gritty

Now that we have an overview of the steps required to load an individual post, let’s look at the technical details for indexing _all_ of a given user’s posts from Mirror. For this, we’re going to focus on using Typescript alongside the `arweave` [package on npm](https://www.npmjs.com/package/arweave).

Mirror helps structure the content stored on Arweave with what are known as `tags`. These are pretty much what you might expect: key <> value pairs representing arbitrary strings tied to a piece of content. For instance, these are the tags for our post on [web3 storage options](https://mirror.xyz/indexingco.eth/FDyv8i8c15ATs_KIpAtEdeMP20WZ00FfssPYOj3EZRY):

```
{
  'Content-Type': 'application/json',
  'App-Name': 'MirrorXYZ',
  Contributor: '0x0317d91C89396C65De570c6A1A5FF8d5485c58DC',
  'Content-Digest': 'B1ytOURSn75aACoOHmVHrV31bl0tL4ffWHEtl4JeGUE',
  'Original-Content-Digest': 'FDyv8i8c15ATs_KIpAtEdeMP20WZ00FfssPYOj3EZRY'
}
```

For our purposes we’re most interested in the `App-Name` and `Contributor` tags. We’ll use the combination of these two to pull all of the content published on Mirror by our given writer.

Alright, time for some code. We’re first defining our `arweave` instance and pointing it at the publicly hosted `arweave.net` provider. If you want to run your own node, check out their docs [here](https://docs.arweave.org/info/mining/mining-guide).

```
import Arweave from "arweave";

const arweave = Arweave.init({
  host: "arweave.net",
  port: 443,
  protocol: "https",
});
```

Since we’re using Typescript, we can define our `Post` structure. This roughly reflects what we’ll get from Arweave directly with the addition of the `originalDigest` key. That `originalDigest` will be pulled from the `Original-Content-Digest` and is important because that’s what Mirror uses in their URLs (i.e. why you can edit a post without having to share a new link).

```
type Post = {
  authorship: {
    contributor: string;
  };
  content: {
    body: string;
    timestamp: string;
    title: string;
  };
  digest: string;
  originalDigest: string;
};
```

Finally, we get to the meat of this whole shebang. We first query Arweave for the transactions matching our given `Contributor` tag and then fetch the full transaction for each identifier, including its data. Since the current `arweave` package only allows us to search by one tag, we filter by the `App-Name: MirrorXYZ` piece further down after we parse out the `tags`.

Now that we’ve filtered down to only those transactions that match our `Contributor` and `App-Name`, we can pull out the `data` and turn it into a `Post`. Mirror adds all of their content as structured JSON strings, so we can readily parse that out and typecast to our `Post` type. Of course, `null` checks and error handling would be welcomed additions as well.

```
async function getPostsForContributor(address: string): Promise<Post[]> {
  const arweaveTransactionIds = await arweave.transactions.search(
    "Contributor",
    address
  );

  const arweaveTransactions = await Promise.all(
    arweaveTransactionIds.map((txId) => arweave.transactions.get(txId))
  );

  const postsByOriginalDigest: Record<string, Post> = {};

  for (const transaction of arweaveTransactions) {
    const tags: Record<string, string> = {};

    for (const tag of transaction.tags) {
      const name = tag.get("name", { decode: true, string: true });
      const value = tag.get("value", { decode: true, string: true });
      tags[name] = value;
    }

    const appName = tags["App-Name"];
    if (appName !== "MirrorXYZ") {
      continue;
    }

    const originalDigest = tags["Original-Content-Digest"];
    if (postsByOriginalDigest[originalDigest]) {
      continue;
    }

    const rawData = transaction.get("data", { decode: true, string: true });
    postsByOriginalDigest[originalDigest] = {
      ...JSON.parse(rawData),
      originalDigest,
    };
  }

  return Object.values(postsByOriginalDigest);
}
```

And that’s really all there is to it! You can view all of the code above, together in this [gist](https://gist.github.com/brock-haugen/f67e71a8fc3c27cd9ecb5b3f64bbcff9). It’s worth noting that the current `arweave` package does _not_ support subscriptions. Because of this, we have to regularly check for new Arweave transactions in a manual way. This can be done via polling, or in the case of indexing.co, simply at request time.

Lastly, if you want to render a given post, the `Post.content.body` parameter is stored as markdown and can be roughly converted to HTML using a package like [markdown-it](https://www.npmjs.com/package/markdown-it).

```
import md from "markdown-it";

function PostView(post: Post) {
  return (
    <div dangerouslySetInnerHTML={{ __html: md().render(post.content.body) }} />
  );
}
```

Happy indexing!

![](https://media.giphy.com/media/upg0i1m4DLe5q/giphy.gif)


---
title: 404: Rabbit hole not found
url: https://www.indexing.co/404
---

# 404: Rabbit hole not found

This isn't the page you were looking for.

Let's go back [home](/) and wave to Dex on the way.

<div class="dex-bit"></div>

<script>
  // Deck-publishing client-side route: /decks/<slug>/ re-routes to /decks/_shell/?slug=<slug>.
  // Orbiter doesn't honor _redirects rewrites, so we land on 404 and re-enter the shell here.
  (function () {
    var m = window.location.pathname.match(/^\/decks\/([^/]+)\/?$/);
    if (!m || m[1] === "_shell") return;
    var slug = m[1];
    var keyParam = new URLSearchParams(window.location.search).get("key") || "";
    var shellUrl = "/decks/_shell/?slug=" + encodeURIComponent(slug)
      + (keyParam ? "&key=" + encodeURIComponent(keyParam) : "");
    window.location.replace(shellUrl);
  })();
</script>


---
title: DeFi Data Infrastructure
url: https://www.indexing.co/solutions/defi
description: Real-time blockchain data indexing for DeFi protocols, DEX trades, lending positions, yield tracking, and liquidation monitoring across 100+ chains.
tags: Solution, DeFi
---

Decentralized finance moves fast. Protocols process billions in volume daily, positions change every block, and a missed liquidation event can mean millions in losses. Building DeFi applications without reliable, real-time indexed data is building blind.

Indexing Co provides the data backbone for DeFi teams: from DEX aggregators tracking swap events across Uniswap, Curve, and Balancer to lending dashboards monitoring health factors on Aave and Compound in real time.

Whether you're building analytics, risk management, or trading infrastructure, the data pipeline starts here.

## Use Cases

<div class="use-case-cards">
<div class="uc-card">
<span class="uc-title">DEX Trade Indexing</span>
<span class="uc-desc">Track every swap, liquidity addition, and removal across decentralized exchanges. Query historical trades by pair, router, or wallet with sub-second latency. Used by aggregators, analytics platforms, and trading bots processing 1B+ events daily.</span>
</div>
<div class="uc-card">
<span class="uc-title">Lending Protocol Analytics</span>
<span class="uc-desc">Monitor borrow positions, collateral ratios, and liquidation thresholds across Aave, Compound, and Morpho. Get alerts before positions become unhealthy. Critical for risk dashboards and liquidation bots.</span>
</div>
<div class="uc-card">
<span class="uc-title">Yield Tracking</span>
<span class="uc-desc">Aggregate APY data across vaults, farms, and staking protocols. Compare yields across chains and protocols with historical data going back years. Powers yield aggregators and portfolio trackers.</span>
</div>
<div class="uc-card">
<span class="uc-title">Liquidation Monitoring</span>
<span class="uc-desc">Index liquidation events in real time across lending protocols. Track which positions are approaching liquidation thresholds. Used by MEV searchers, risk teams, and protocol governance dashboards.</span>
</div>
</div>

## Why Indexing Co for DeFi

<div class="use-case-cards">
<div class="uc-card">
<span class="uc-title">Multi-chain coverage</span>
<span class="uc-desc">Index DeFi events across Ethereum, Base, Arbitrum, Optimism, Polygon, and 95+ other chains from a single pipeline.</span>
</div>
<div class="uc-card">
<span class="uc-title">Block-level freshness</span>
<span class="uc-desc">sub-500ms (dedicated infra) block-to-storage latency means your data reflects the latest on-chain state.</span>
</div>
<div class="uc-card">
<span class="uc-title">Custom transforms</span>
<span class="uc-desc">Write transformation logic specific to your protocol's event schema, not limited to predefined subgraph mappings.</span>
</div>
<div class="uc-card">
<span class="uc-title">Historical backfill</span>
<span class="uc-desc">Replay years of on-chain history through your pipeline. Backfill a new DEX pair's full trade history in hours, not weeks.</span>
</div>
</div>

## Key Numbers

- **100+ chains** indexed in parallel
- **1B+ events/day** processed across all pipelines
- **sub-500ms** block-to-database on dedicated infrastructure
- **1.6 TB/day** of raw blockchain data ingested
- **99.9% uptime** across production pipelines

## FAQ

### Which DeFi protocols does Indexing Co support?
Any protocol that emits on-chain events. Uniswap, Curve, Balancer, Aave, Compound, Morpho, GMX, and hundreds more. You define the contract addresses and event signatures in your pipeline, so any new protocol is supported immediately.

### Can I index DEX trades across multiple chains at once?
Yes. A single pipeline definition can track swap events across Ethereum, Base, Arbitrum, Optimism, Polygon, and 95+ other chains simultaneously. All data lands in the same destination with chain identifiers.

### How do I handle custom DeFi event schemas?
Write TypeScript transformation functions that decode and reshape events to match your database schema. This is not limited to predefined mappings like subgraphs. You have full control over the output format.

### What's the latency for real-time DeFi monitoring?
Sub-500ms block-to-database on dedicated infrastructure. For liquidation monitoring and MEV applications, this means your data reflects the latest on-chain state within one block.

### Can I backfill historical DeFi data?
Yes. Replay years of on-chain history through your pipeline. A full Uniswap v3 trade history backfill on Ethereum typically completes in hours, not weeks.

## Get Started

Set up a DeFi data pipeline in under 10 minutes. Define your event sources, write your transform logic, and start receiving data.

[Get a Demo](https://www.indexing.co/contact) | [Open the Console](https://console.indexing.co)


---
title: Solutions
url: https://www.indexing.co/solutions/index
description: Blockchain data infrastructure for every use case: from DeFi and payments to enterprise analytics and agentic engineering.
tags: Solution
---

<div class="solution-groups">

<div class="solution-group">
<span class="sg-label">DeFi &amp; Derivatives</span>
<div class="solution-cards-grid">

<a href="/solutions/defi" class="solution-card">
<div class="sc-top"></div>
<div class="solution-card-header">
<span class="sc-dot"></span>
<span class="sc-title">DeFi Data Infrastructure</span>
</div>
<span class="sc-desc">Real-time DEX trades, lending positions, yield tracking, and liquidation monitoring across 100+ chains.</span>
</a>

<a href="/solutions/perpetual-markets" class="solution-card">
<div class="sc-top"></div>
<div class="solution-card-header">
<span class="sc-dot"></span>
<span class="sc-title">Perpetual Markets</span>
</div>
<span class="sc-desc">Perp trades, funding rates, liquidations, and open interest across Hyperliquid, dYdX, GMX, and others.</span>
</a>

<a href="/solutions/prediction-markets" class="solution-card">
<div class="sc-top"></div>
<div class="solution-card-header">
<span class="sc-dot"></span>
<span class="sc-title">Prediction Markets</span>
</div>
<span class="sc-desc">Market creation, trade events, resolution outcomes, and liquidity data across Polymarket, Azuro, and more.</span>
</a>

</div>
</div>

<div class="solution-group">
<span class="sg-label">Payments &amp; Fintech</span>
<div class="solution-cards-grid">

<a href="/solutions/payments" class="solution-card">
<div class="sc-top"></div>
<div class="solution-card-header">
<span class="sc-dot"></span>
<span class="sc-title">Payments</span>
</div>
<span class="sc-desc">Stablecoin transfers, payment settlements, and transaction flows with sub-500ms latency (dedicated infra).</span>
</a>

<a href="/solutions/fintech" class="solution-card">
<div class="sc-top"></div>
<div class="solution-card-header">
<span class="sc-dot"></span>
<span class="sc-title">Fintech</span>
</div>
<span class="sc-desc">Structured on-chain data for compliance tools, risk platforms, and financial analytics products.</span>
</a>

<a href="/solutions/wallet-tracking" class="solution-card">
<div class="sc-top"></div>
<div class="solution-card-header">
<span class="sc-dot"></span>
<span class="sc-title">Wallet Tracking</span>
</div>
<span class="sc-desc">Wallet activity, token balances, and transaction history for portfolio trackers and compliance tools.</span>
</a>

</div>
</div>

<div class="solution-group">
<span class="sg-label">Infrastructure &amp; Enterprise</span>
<div class="solution-cards-grid">

<a href="/solutions/infra-stack" class="solution-card">
<div class="sc-top"></div>
<div class="solution-card-header">
<span class="sc-dot"></span>
<span class="sc-title">Full Infrastructure Stack</span>
</div>
<span class="sc-desc">From RPC ingestion through distributed processing to direct database delivery. Shared and dedicated infrastructure.</span>
</a>

<a href="/solutions/enterprise" class="solution-card">
<div class="sc-top"></div>
<div class="solution-card-header">
<span class="sc-dot"></span>
<span class="sc-title">Enterprise</span>
</div>
<span class="sc-desc">Production-grade pipelines with consultancy, custom implementation, SLAs, and dedicated support.</span>
</a>

<a href="/solutions/depin" class="solution-card">
<div class="sc-top"></div>
<div class="solution-card-header">
<span class="sc-dot"></span>
<span class="sc-title">DePIN</span>
</div>
<span class="sc-desc">Device registration, sensor data streams, and reward distribution events for decentralized physical networks.</span>
</a>

</div>
</div>

<div class="solution-group">
<span class="sg-label">AI &amp; Emerging</span>
<div class="solution-cards-grid">

<a href="/solutions/agentic-engineering" class="solution-card">
<div class="sc-top"></div>
<div class="solution-card-header">
<span class="sc-dot"></span>
<span class="sc-title">Agentic Engineering</span>
</div>
<span class="sc-desc">Give AI agents direct access to indexed blockchain data via MCP and tool-based interfaces.</span>
</a>

<a href="/solutions/ai-data-science" class="solution-card">
<div class="sc-top"></div>
<div class="solution-card-header">
<span class="sc-dot"></span>
<span class="sc-title">AI &amp; Data Science</span>
</div>
<span class="sc-desc">Clean, normalized on-chain data delivered to your ML pipeline, notebook, or feature store.</span>
</a>

<a href="/solutions/gaming" class="solution-card">
<div class="sc-top"></div>
<div class="solution-card-header">
<span class="sc-dot"></span>
<span class="sc-title">Gaming</span>
</div>
<span class="sc-desc">In-game asset transfers, marketplace trades, and player activity across blockchain gaming platforms.</span>
</a>

</div>
</div>

</div>

[Talk to the Team](https://www.indexing.co/contact) | [Open the Console](https://console.indexing.co)


---
title: AI & Data Science Infrastructure
url: https://www.indexing.co/solutions/ai-data-science
description: Structured blockchain data for ML training, real-time inference, and on-chain monitoring: batch and streaming pipelines across 100+ chains.
tags: Solution, AI, Data Science
---

Machine learning models trained on blockchain data need clean inputs. Not raw hex from RPC nodes. Not rate-limited API responses. Structured, typed, queryable data that maps to your feature schema.

Indexing Co delivers blockchain data in the format data science teams actually use. Stream real-time events into your feature store. Backfill years of transaction history for model training. Push structured outputs to BigQuery, PostgreSQL, or S3, wherever your training pipeline reads from.

Whether you're building fraud detection models, wallet clustering algorithms, or on-chain risk scoring, the data layer starts here.

## Use Cases

<div class="use-case-cards">
<div class="uc-card">
<span class="uc-title">ML Training on Historical Transactions</span>
<span class="uc-desc">Backfill millions of labeled transactions across 100+ chains into your training environment. Define the event types, token contracts, and address sets you care about. Get structured rows, not raw logs. Train models on swap patterns, transfer volumes, gas usage, or any on-chain signal your features require.</span>
</div>
<div class="uc-card">
<span class="uc-title">Real-Time Inference Pipelines</span>
<span class="uc-desc">Feed live blockchain events into your inference endpoint. New swap on Uniswap, new transfer to a flagged wallet, new contract deployment: your model scores it within seconds of the on-chain event. sub-500ms (dedicated infra) latency from block to your pipeline.</span>
</div>
<div class="uc-card">
<span class="uc-title">Wallet Behavior Clustering</span>
<span class="uc-desc">Index transaction histories for millions of wallets. Build behavioral profiles based on protocol usage, token holdings, transaction frequency, and interaction patterns. Used by compliance teams, marketing platforms, and identity protocols.</span>
</div>
<div class="uc-card">
<span class="uc-title">Anomaly Detection and Monitoring</span>
<span class="uc-desc">Stream on-chain events through your anomaly detection models in real time. Flag unusual transfer patterns, sudden liquidity removals, or abnormal gas spikes. Deliver alerts via webhooks to your monitoring stack.</span>
</div>
<div class="uc-card">
<span class="uc-title">Vector Search Over Blockchain State</span>
<span class="uc-desc">Index contract state, token metadata, and transaction context into vector-compatible formats. Query semantic similarity across on-chain entities. Power recommendation engines, search interfaces, and agent retrieval systems.</span>
</div>
</div>

## Why Indexing Co for Data Science Teams

<div class="use-case-cards">
<div class="uc-card">
<span class="uc-title">Batch and streaming</span>
<span class="uc-desc">Same pipeline definition supports historical backfills and real-time event streams. Switch modes without rebuilding.</span>
</div>
<div class="uc-card">
<span class="uc-title">Direct database delivery</span>
<span class="uc-desc">Data lands in PostgreSQL, BigQuery, or S3. No intermediate API layer between your pipeline and your data.</span>
</div>
<div class="uc-card">
<span class="uc-title">Custom transforms</span>
<span class="uc-desc">Write TypeScript functions that reshape raw events into your feature schema before storage. Decode, filter, aggregate, enrich.</span>
</div>
<div class="uc-card">
<span class="uc-title">100+ chains, one schema</span>
<span class="uc-desc">Normalize cross-chain data into a unified format. Train models across Ethereum, Base, Arbitrum, Solana, and more without chain-specific adapters.</span>
</div>
<div class="uc-card">
<span class="uc-title">Deterministic replay</span>
<span class="uc-desc">Re-run any historical range through updated transforms. Reproduce training datasets exactly.</span>
</div>
</div>

## Key Numbers

- **100+ chains** indexed in parallel
- **1B+ events/day** processed across all pipelines
- **sub-500ms** block-to-database on dedicated infrastructure
- **1.6 TB/day** of raw blockchain data ingested
- **Years of history** available for backfill on major chains

## Get Started

Set up a data pipeline that feeds structured blockchain events into your ML infrastructure. Define your sources, write your transforms, pick your delivery target.

[Get a Demo](https://www.indexing.co/contact) | [Open the Console](https://console.indexing.co)


---
title: Full Infrastructure Stack
url: https://www.indexing.co/solutions/infra-stack
description: The complete blockchain data platform, from raw chain ingestion to queryable storage. Source, transform, deliver across 100+ chains with sub-500ms latency (dedicated infra).
tags: Solution, Platform
---

Most blockchain data tools solve one piece of the puzzle. An RPC provider gives you raw data. A subgraph service gives you a specific query interface. A data warehouse gives you storage. You're left stitching them together, managing the gaps, and debugging the seams.

Indexing Co is the full stack. One platform that ingests raw blockchain data, transforms it through your custom logic, and delivers it directly to your infrastructure. No middleware. No third-party dependencies between you and your data.

## The Stack

<div class="use-case-cards">
<div class="uc-card">
<span class="uc-title">Source Layer</span>
<span class="uc-desc">Connect to 100+ blockchain networks through a unified ingestion engine. EVM chains, Solana, Cosmos, and more. The source layer handles node connections, block polling, reorg detection, and chain-specific quirks so your pipeline logic doesn't have to. Automatic reorg handling with configurable confirmation depth, factory-pattern contract discovery (new pools, new markets, new vaults), and multi-chain parallel ingestion from a single pipeline definition.</span>
</div>
<div class="uc-card">
<span class="uc-title">Transform Layer</span>
<span class="uc-desc">Write TypeScript transformation logic that decodes raw events into your schema. Your business logic runs in your transformation functions, not in a black-box indexing service. Decode any event signature or transaction type, enrich with cross-contract calls or off-chain data, filter and reshape data before it reaches storage, and version your transforms alongside your application code.</span>
</div>
<div class="uc-card">
<span class="uc-title">Delivery Layer</span>
<span class="uc-desc">Data goes where you need it. No intermediate APIs, no query limits, no vendor lock-in. Supports PostgreSQL (direct table writes), BigQuery (streaming inserts for analytics), webhooks (push events to your backend in real time), GraphQL (query indexed data through a managed API), and custom targets via Kafka, S3, or the plugin system.</span>
</div>
</div>

## How It Fits Together

```
Chain (100+) --> Source --> Transform --> Deliver --> Your Infrastructure
                 |            |             |
              Reorg       TypeScript     PostgreSQL
              handling    functions      BigQuery
              Factory     Filtering      Webhooks
              discovery   Enrichment     GraphQL
```

A single pipeline definition covers the entire flow. Define which contracts to watch, write your transform logic, pick your delivery target. Deploy once, and data flows continuously.

## Why a Full Stack Matters

<div class="use-case-cards">
<div class="uc-card">
<span class="uc-title">No gaps in the pipeline</span>
<span class="uc-desc">When source, transform, and delivery are separate services from separate vendors, failures between them are your problem. With Indexing Co, the entire pipeline is a single managed unit with end-to-end monitoring.</span>
</div>
<div class="uc-card">
<span class="uc-title">One deployment model</span>
<span class="uc-desc">No separate infra for ingestion, transformation, and storage. One pipeline config, one deployment, one monitoring dashboard. Operational complexity scales linearly, not exponentially.</span>
</div>
<div class="uc-card">
<span class="uc-title">Data integrity guarantees</span>
<span class="uc-desc">The platform guarantees exactly-once delivery from chain to storage. Reorgs are handled at the source layer, transforms are idempotent, and delivery is transactional. No missing events, no duplicates.</span>
</div>
</div>

## Key Numbers

- **100+ chains** from a single platform
- **sub-500ms** block-to-database on dedicated infrastructure
- **1B+ events/day** processed across production pipelines
- **1.6 TB/day** of raw blockchain data ingested
- **99.9% uptime** standard, 99.99% on dedicated deployments

## Get Started

See the full stack in action. Set up a pipeline from chain to database in under 10 minutes.

[Get a Demo](https://www.indexing.co/contact) | [Open the Console](https://console.indexing.co)


---
title: Fintech Data Infrastructure
url: https://www.indexing.co/solutions/fintech
description: Blockchain data pipelines for fintech applications, portfolio tracking, risk analytics, and regulatory reporting across 100+ chains.
tags: Solution, Fintech
---

A compliance team requests a transaction report for a customer's wallet. Six months of activity across Ethereum, Polygon, and Arbitrum. The engineer queries raw RPC endpoints, hits rate limits, decodes hex logs manually, and comes back three days later with a spreadsheet. The customer has moved on.

Fintech teams spend engineering cycles on blockchain data plumbing that isn't their product. Indexing Co handles the indexing layer: structured event data delivered to your systems at sub-500ms latency (dedicated infra), so your team builds the product, not the pipeline.

## Use Cases

<div class="use-case-cards">
<div class="uc-card">
<span class="uc-title">Portfolio and Asset Tracking</span>
<span class="uc-desc">Token balances, NFT holdings, staking positions, and DeFi allocations across chains. When a user deposits into a yield protocol or bridges to a new chain, your dashboard reflects it within seconds. No polling. No manual balance reconciliation.</span>
</div>
<div class="uc-card">
<span class="uc-title">Risk and Exposure Analytics</span>
<span class="uc-desc">Counterparty exposure to lending protocols, bridge contracts, and DEX liquidity pools. Your risk models need current positions, not yesterday's snapshot. Indexing Co streams position change events directly to your data warehouse so exposure calculations run against live state.</span>
</div>
<div class="uc-card">
<span class="uc-title">Regulatory Reporting and Compliance</span>
<span class="uc-desc">Transaction monitoring requires complete, auditable records of wallet activity. Indexing Co captures every transfer, swap, approval, and contract interaction with normalized addresses and decoded function calls. Your compliance tooling gets structured inputs, not raw logs to parse.</span>
</div>
<div class="uc-card">
<span class="uc-title">Market Data Aggregation</span>
<span class="uc-desc">DEX pricing, liquidity depth, and volume across Uniswap, Curve, Balancer, and protocol variants. Aggregate price feeds for trading interfaces without building separate connectors for each protocol.</span>
</div>
</div>

## How It Fits

- **sub-500ms (dedicated infra)**: Block-to-storage, measured across production pipelines. Portfolio valuations reflect current state
- **Schema you control**: Define your own data model: map protocol events to your internal types, not a predefined schema
- **Direct delivery**: Data goes to your PostgreSQL, BigQuery, or webhook endpoint. No intermediate API layer
- **Historical depth**: Backfill years of on-chain history through the same pipeline definition used for real-time streams
- **100+ chains**: Multi-chain coverage from a single platform as your product expands

## Key Numbers

- **100+ chains** indexed in parallel
- **sub-500ms** block-to-database on dedicated infrastructure
- **1B+ events/day** processed across all pipelines
- **1.6 TB/day** of raw blockchain data ingested

## Get Started

[Talk to the Team](https://www.indexing.co/contact) | [Open the Console](https://console.indexing.co)


---
title: Gaming Data Infrastructure
url: https://www.indexing.co/solutions/gaming
description: Index in-game asset transfers, marketplace trades, and player activity across blockchain gaming platforms with sub-500ms latency (dedicated infra).
tags: Solution, Gaming
---

A game marketplace shows a sword listed for 50 tokens. A player buys it. The listing stays visible for another 30 seconds because the backend polls a node every minute. Another player tries to buy the same sword. The transaction fails. The player leaves.

This is what happens when game studios treat blockchain data as an afterthought. Indexing Co gives your game backend a live view of on-chain state, delivered as structured events within seconds of confirmation.

## Use Cases

<div class="use-case-cards">
<div class="uc-card">
<span class="uc-title">In-Game Asset Tracking</span>
<span class="uc-desc">Every mint, transfer, and burn for your game's items, characters, and land parcels. Indexing Co watches your contracts and delivers ownership changes as structured events. Your backend receives a webhook with the item ID, previous owner, new owner, and block timestamp. Rarity calculations, inventory updates, and provenance records update in real time.</span>
</div>
<div class="uc-card">
<span class="uc-title">Marketplace Operations</span>
<span class="uc-desc">Listings, sales, bids, cancellations. Your marketplace UI reflects the current state, not the state from 30 seconds ago. Indexing Co streams order book events directly to your database. Floor prices update on every trade. When a high-value item sells, your notification system fires within seconds.</span>
</div>
<div class="uc-card">
<span class="uc-title">Leaderboards and Achievements</span>
<span class="uc-desc">On-chain achievements are verifiable. Players trust leaderboards backed by blockchain data because no one, including the game studio, can fake them. Index quest completions, kill counts, reward claims, and tournament results. Push rankings to your game client through webhooks.</span>
</div>
<div class="uc-card">
<span class="uc-title">Economy Monitoring</span>
<span class="uc-desc">Game economies break when token emissions outpace sinks. Track minting rates, burn volumes, and circulating supply across your game's token contracts. Set up alerts when inflation exceeds target thresholds. Feed economic data into your game design tools so balancing decisions use real numbers, not estimates.</span>
</div>
</div>

## How It Fits

- **sub-500ms (dedicated infra)**: Your game UI reflects on-chain state within seconds of block confirmation
- **Multi-chain from one pipeline**: Games deploy across Ethereum, Polygon, Arbitrum, Base, Immutable, and custom chains. One pipeline covers all of them
- **Custom schemas**: Transform raw contract events into your data model. Player IDs, item types, match results, not raw hex
- **Webhook delivery**: Events push to your backend on confirmation. No polling
- **Full history**: Replay your game's complete on-chain activity when launching analytics or migrating data stores

## Key Numbers

- **100+ chains** including gaming-focused networks like Immutable and Ronin
- **sub-500ms** block-to-delivery on dedicated infrastructure
- **1B+ events/day** processed across all pipelines

## Get Started

[Talk to the Team](https://www.indexing.co/contact) | [Open the Console](https://console.indexing.co)


---
title: Agentic Engineering Data Infrastructure
url: https://www.indexing.co/solutions/agentic-engineering
description: Give AI agents direct access to indexed blockchain data via MCP tools. Real-time on-chain intelligence for autonomous agent workflows across 100+ chains.
tags: Solution, Agentic Engineering
---

AI agents need data to act. When an agent monitors DeFi positions, tracks payment settlements, or analyzes on-chain activity, it needs structured, queryable blockchain data, not raw RPC calls that return hex-encoded noise.

Indexing Co provides the data layer for agentic engineering. Our MCP (Model Context Protocol) server gives agents tool-based access to indexed blockchain data across 100+ chains. No custom API integration, no data pipeline management, no infrastructure overhead. The agent calls a tool, gets structured data, and acts on it.

Whether you're building autonomous trading agents, monitoring bots, or multi-agent systems that coordinate on-chain actions, the data access layer is already built.

## Use Cases

<div class="use-case-cards">
<div class="uc-card">
<span class="uc-title">MCP Blockchain Data Access</span>
<span class="uc-desc">Give any MCP-compatible agent (Claude, Cursor, custom frameworks) direct access to indexed on-chain data. Query events, balances, transactions, and pipeline status through standard MCP tool calls.</span>
</div>
<div class="uc-card">
<span class="uc-title">Autonomous Event Monitoring</span>
<span class="uc-desc">Agents subscribe to on-chain events and react autonomously. Liquidation monitoring, governance vote tracking, large transfer alerts, all driven by indexed event streams delivered via webhooks.</span>
</div>
<div class="uc-card">
<span class="uc-title">Agent-to-Agent Data Sharing</span>
<span class="uc-desc">Multi-agent systems where one agent indexes data and others consume it. Structured APIs enable clean separation of concerns in agent architectures.</span>
</div>
<div class="uc-card">
<span class="uc-title">Real-Time Trading Intelligence</span>
<span class="uc-desc">Agents that need sub-500ms market data (dedicated infra) from DEX swaps, order book changes, and liquidity shifts across multiple chains simultaneously.</span>
</div>
</div>

## Why Indexing Co for Agentic Engineering

<div class="use-case-cards">
<div class="uc-card">
<span class="uc-title">MCP-native</span>
<span class="uc-desc">Production MCP server with tools for querying indexed blockchain data, compatible with Claude, Cursor, and any MCP framework.</span>
</div>
<div class="uc-card">
<span class="uc-title">No infrastructure management</span>
<span class="uc-desc">Agents don't need to run indexers, manage databases, or maintain RPC connections.</span>
</div>
<div class="uc-card">
<span class="uc-title">100+ chains from one interface</span>
<span class="uc-desc">A single MCP tool call can query data across Ethereum, Base, Arbitrum, and 97+ other chains.</span>
</div>
<div class="uc-card">
<span class="uc-title">sub-500ms freshness</span>
<span class="uc-desc">Agents get data that's at most sub-500ms (dedicated infra) behind the chain, not minutes-old cached responses.</span>
</div>
</div>

## Key Numbers

- **100+ chains** accessible via MCP tools
- **sub-500ms** median block-to-query latency
- **1B+ events/day** indexed across all pipelines
- **0 infrastructure** required from the agent developer

## Get Started

Connect your agent to Indexing Co's MCP server and start receiving data from blockchain in minutes.

[Get a Demo](https://www.indexing.co/contact) | [MCP Documentation](https://www.indexing.co/articles/indexing-co-mcp)


---
title: DePIN Data Infrastructure
url: https://www.indexing.co/solutions/depin
description: Index device registrations, reward distributions, and network activity for decentralized physical infrastructure networks across 100+ chains.
tags: Solution, DePIN
---

A node operator disputes their reward payout. They say their device was online and submitting proofs. Your dashboard shows downtime. Neither of you can verify against the on-chain record quickly because the proof submission logs aren't indexed. They're buried in raw transactions that take minutes to query directly.

DePIN networks only work if operators trust the data. Indexing Co indexes proof submissions, reward calculations, and device state so operators and protocol teams can verify network activity against on-chain fact, not dashboard snapshots.

## Use Cases

<div class="use-case-cards">
<div class="uc-card">
<span class="uc-title">Device Registry and Status</span>
<span class="uc-desc">Device registration events, status transitions, and metadata updates indexed as they confirm. Active node counts, geographic distribution by region, and device lifecycle tracking from a single event stream. When a node goes offline or gets slashed, your monitoring system knows within seconds.</span>
</div>
<div class="uc-card">
<span class="uc-title">Reward Distribution Tracking</span>
<span class="uc-desc">Every reward calculation and distribution event from your reward contracts. Operators can verify their payout against the on-chain transaction. Indexing Co captures reward events with block timestamps so APY dashboards and dispute resolution tools work from auditable data, not estimations.</span>
</div>
<div class="uc-card">
<span class="uc-title">Proof Submission Monitoring</span>
<span class="uc-desc">Coverage proofs, uptime attestations, and quality-of-service submissions indexed at block speed. Network health dashboards track submission rates, coverage gaps, and protocol compliance in real time. When proof volumes spike or drop, you see it immediately.</span>
</div>
<div class="uc-card">
<span class="uc-title">Governance and Staking</span>
<span class="uc-desc">Staking deposits, delegation changes, and governance votes. Real-time voting dashboards and historical participation records. Power protocol governance UIs with current on-chain state rather than off-chain tallies.</span>
</div>
</div>

## How It Fits

- **sub-500ms (dedicated infra)**: Proof submissions and reward events reach your systems within seconds of confirmation
- **Multi-chain coverage**: DePIN protocols span Solana, Ethereum, Base, and more. Index all of them from one pipeline
- **Custom transforms**: Map protocol-specific events to your network's metrics: coverage zones, uptime scores, reward tiers
- **Historical backfill**: Replay full network history for audits, analytics, and operator dispute resolution
- **High event volume**: Built for the continuous event streams that active DePIN networks produce

## Key Numbers

- **100+ chains** supported for DePIN data indexing
- **sub-500ms** block-to-database on dedicated infrastructure
- **1B+ events/day** processed across all pipelines
- **1.6 TB/day** of raw blockchain data ingested

## Get Started

[Talk to the Team](https://www.indexing.co/contact) | [Open the Console](https://console.indexing.co)


---
title: DEX Trade Indexing
url: https://www.indexing.co/solutions/defi/dex-indexing
description: Index every swap, liquidity event, and pool state change across Uniswap, Curve, Balancer, and 50+ DEXs with sub-second query latency.
tags: Solution, DeFi
---

A DEX aggregator needs to know the exact state of every pool across every chain -- right now. A trading bot needs the full history of a pair's price action. An analytics dashboard needs to show volume by protocol, by chain, by hour. All of this starts with indexed trade data.

## The Challenge

Decentralized exchanges emit swap events at massive scale. Uniswap V3 alone produces thousands of events per hour on Ethereum mainnet. Multiply that across Curve, Balancer, PancakeSwap, and protocol forks on 20+ EVM chains, and you're looking at millions of events per day that need to be captured, decoded, and stored in a queryable format.

Raw RPC polling can't keep up. Subgraph indexing works for single protocols on single chains but breaks down when you need cross-chain, cross-protocol coverage with custom data shapes. And hosted indexing services introduce dependency on third-party uptime and query limits.

## How It Works

1. **Source**: Define which DEX contracts to monitor across your target chains. Indexing Co supports factory-pattern discovery -- when a new Uniswap V3 pool is deployed, it's automatically added to your pipeline.

2. **Transform**: Write TypeScript handlers that decode swap events into your schema. Extract price, volume, fees, router address, and wallet. Enrich with token metadata from on-chain registries.

3. **Deliver**: Query via GraphQL API, stream to your PostgreSQL database, or push to a webhook. Median latency from block confirmation to queryable data: 2.54 seconds.

## Technical Details

A typical DEX indexing pipeline monitors:
- `Swap(address,address,int256,int256,uint160,uint128,int24)` events on Uniswap V3 pools
- `TokenExchange(address,int128,uint256,int128,uint256)` on Curve pools
- `Swap(bytes32,address,address,uint256,uint256)` on Balancer V2 vaults

Each event is decoded, enriched with pool metadata (token pair, fee tier, TVL), and written to your target. The pipeline handles chain reorgs by maintaining a confirmation depth buffer -- trades are provisional until confirmed.

For cross-chain aggregation, a single pipeline definition can target the same factory contract across Ethereum, Base, Arbitrum, and Optimism. The output schema is unified regardless of source chain.

## Results

Teams using Indexing Co for DEX data typically see:

- **10x faster backfill** compared to subgraph redeployments -- replay a full year of Uniswap V3 history in under 4 hours
- **Sub-3s freshness** from block to queryable trade data
- **Zero maintenance** on new pool discovery -- factory watchers handle it automatically
- **Single API** for cross-chain, cross-protocol trade queries

## Related Content

- [Data Pipelines for Prediction Markets](/articles/data-pipelines-for-prediction-markets)
- [DeFi Data Infrastructure](/solutions/defi)

## Start Building

Index your first DEX trades in under 10 minutes. Pick a chain, define your event sources, and start querying.

[Get a Demo](https://www.indexing.co/contact) | [Open the Console](https://console.indexing.co)


---
title: Enterprise Data Infrastructure
url: https://www.indexing.co/solutions/enterprise
description: Production-grade blockchain data pipelines with consultancy, custom implementation, SLAs, and dedicated support for enterprise teams.
tags: Solution, Enterprise
---

Enterprise blockchain projects fail when the data layer is an afterthought. Consumer-grade indexing services can't meet your compliance requirements. Running your own indexers means hiring a team to maintain them. Neither approach gives you a partner who understands your data architecture and can build alongside you.

Indexing Co provides enterprise-grade blockchain data infrastructure with a consultancy-led engagement model. We don't just hand you a product and walk away. We work with your team to design, implement, and maintain the data pipelines your business depends on.

## How We Work With Enterprise Teams

<div class="use-case-cards">
<div class="uc-card">
<span class="uc-title">Discovery & Architecture Design</span>
<span class="uc-desc">Every engagement starts with understanding your data requirements. We audit your current data stack, map your blockchain data needs across chains and use cases, and design a pipeline architecture that fits your infrastructure. This isn't a sales call. It's a technical consultation where we determine what you need, what you already have, and how Indexing Co fills the gap.</span>
</div>
<div class="uc-card">
<span class="uc-title">Implementation Alongside Your Team</span>
<span class="uc-desc">We build the initial pipelines with your engineering team, not for them. Your team learns the platform during implementation so they can extend it independently. Custom transformation logic, delivery targets, and monitoring are configured together. Typical implementation timeline: 1-3 weeks from kickoff to production data flowing, depending on complexity and number of chains.</span>
</div>
<div class="uc-card">
<span class="uc-title">Roadmap Planning & Ongoing Support</span>
<span class="uc-desc">Enterprise needs evolve. New chains, new protocols, new compliance requirements. We maintain a shared roadmap with enterprise customers, prioritize platform improvements that matter to your use cases, and provide a dedicated support channel for incident response.</span>
</div>
<div class="uc-card">
<span class="uc-title">Compliance & Security</span>
<span class="uc-desc">SOC 2 Type II compliance (in progress). Data residency: deploy in your preferred region or on your infrastructure. Full pipeline execution logs with data lineage, role-based permissions for pipeline management, and data encrypted in transit and at rest.</span>
</div>
</div>

### Procurement-Ready Onboarding

Enterprise procurement can be painful. We provide:
- Standard MSA and DPA templates
- Custom invoicing and payment terms
- Dedicated account management
- Technical onboarding documentation

## Use Cases

<div class="use-case-cards">
<div class="uc-card">
<span class="uc-title">Compliance & Audit Data Pipelines</span>
<span class="uc-desc">Index transaction flows, token movements, and smart contract interactions into your compliance data warehouse. Maintain complete audit trails across chains with guaranteed data completeness. Feed AML/KYC enrichment systems with structured on-chain data.</span>
</div>
<div class="uc-card">
<span class="uc-title">Treasury & Portfolio Tracking</span>
<span class="uc-desc">Track corporate treasury positions across DeFi protocols and custodial wallets. Real-time balance monitoring, historical position tracking, and automated reporting across 100+ chains from a single pipeline.</span>
</div>
<div class="uc-card">
<span class="uc-title">Internal Analytics & Reporting</span>
<span class="uc-desc">Build internal dashboards on indexed blockchain data without managing infrastructure. Product usage metrics, protocol revenue tracking, and operational monitoring, all delivered directly to your BI tools.</span>
</div>
<div class="uc-card">
<span class="uc-title">Multi-Chain Payment Settlement</span>
<span class="uc-desc">Index payment events across chains for settlement reconciliation. Track stablecoin transfers, bridge transactions, and protocol fee distributions with sub-500ms freshness (dedicated infra).</span>
</div>
</div>

## Why Indexing Co for Enterprise

<div class="use-case-cards">
<div class="uc-card">
<span class="uc-title">Not just a product, a partner</span>
<span class="uc-desc">Consultancy-led engagement with hands-on implementation support.</span>
</div>
<div class="uc-card">
<span class="uc-title">Production SLAs</span>
<span class="uc-desc">Up to 99.99% uptime on dedicated deployments with dedicated support channels and incident response.</span>
</div>
<div class="uc-card">
<span class="uc-title">Data completeness</span>
<span class="uc-desc">No missing events, no silent failures. Pipeline health monitoring with alerting built in.</span>
</div>
<div class="uc-card">
<span class="uc-title">Your infrastructure</span>
<span class="uc-desc">Data delivered directly to your PostgreSQL, BigQuery, or data warehouse. No vendor lock-in.</span>
</div>
<div class="uc-card">
<span class="uc-title">Custom transforms</span>
<span class="uc-desc">Business logic runs in your transformation layer, not ours. Full control over data shape and enrichment.</span>
</div>
<div class="uc-card">
<span class="uc-title">100+ chains</span>
<span class="uc-desc">Single integration covers Ethereum, Base, Arbitrum, Optimism, Polygon, Solana, and more.</span>
</div>
</div>

## Key Numbers

- **100+ chains** indexed from a single platform
- **99.99% uptime** on dedicated deployments (99.9% standard)
- **sub-500ms** block-to-database on dedicated infrastructure
- **1-3 weeks** typical implementation timeline

## FAQ

### What SLAs does Indexing Co offer for enterprise?
Up to 99.99% uptime on dedicated deployments with dedicated support channels and defined incident response times. Standard shared infrastructure offers 99.9% uptime.

### How long does enterprise implementation take?
Typical timeline is 1-3 weeks from kickoff to production data flowing, depending on complexity, number of chains, and custom transformation requirements. We work alongside your team during implementation.

### Can I deploy Indexing Co in my own infrastructure?
Yes. Enterprise plans support on-prem deployment, VPC deployment, and data residency in your preferred region. Data never leaves your infrastructure boundary.

### Is Indexing Co SOC 2 compliant?
SOC 2 Type II compliance is in progress. We provide full pipeline execution logs with data lineage, role-based permissions, and data encrypted in transit and at rest.

### What does the enterprise engagement model look like?
We start with a technical discovery session to audit your current data stack and map your blockchain data needs. Implementation is done alongside your engineering team, not for them, so your team can extend pipelines independently after handoff.

## Get Started

Talk to our team about enterprise deployment options, SLAs, and custom pipeline architecture.

[Get a Demo](https://www.indexing.co/contact) | [Open the Console](https://console.indexing.co)


---
title: Wallet Tracking Data Infrastructure
url: https://www.indexing.co/solutions/wallet-tracking
description: Index wallet activity, token balances, and transaction history across 100+ chains for portfolio trackers, compliance tools, and analytics platforms.
tags: Solution, Wallet Tracking
---

Every wallet tells a story: token holdings, DeFi positions, NFT collections, transaction patterns. Portfolio trackers, compliance teams, and analytics platforms need this data indexed across chains, in real time, and in a format they can query.

Indexing Co provides the data layer for wallet tracking applications. Monitor any address across 100+ chains, index its full transaction history, and deliver structured wallet data to your backend.

## Use Cases

<div class="use-case-cards">
<div class="uc-card">
<span class="uc-title">Portfolio Tracking</span>
<span class="uc-desc">Index token balances, DeFi positions, and NFT holdings for any wallet across chains. Track value changes over time with historical balance snapshots. Power portfolio dashboards that show a unified view of on-chain wealth.</span>
</div>
<div class="uc-card">
<span class="uc-title">Whale Watching</span>
<span class="uc-desc">Monitor high-value wallets for large transfers, position changes, and protocol interactions. Get real-time alerts when tracked wallets move significant amounts. Used by trading desks, research teams, and alpha-seeking traders.</span>
</div>
<div class="uc-card">
<span class="uc-title">Compliance & Investigation</span>
<span class="uc-desc">Build audit trails from on-chain transaction data. Track fund flows across wallets, bridges, and mixers. Feed compliance systems with structured transaction graphs for AML/KYC enrichment and suspicious activity detection.</span>
</div>
<div class="uc-card">
<span class="uc-title">Wallet Labeling & Attribution</span>
<span class="uc-desc">Cross-reference wallet activity with known entity labels, contract deployments, and protocol interactions. Enrich raw addresses with behavioral classification: exchange, smart contract, multisig, protocol treasury.</span>
</div>
</div>

## Why Indexing Co for Wallet Tracking

<div class="use-case-cards">
<div class="uc-card">
<span class="uc-title">Multi-chain coverage</span>
<span class="uc-desc">Track wallets across Ethereum, Base, Arbitrum, Optimism, Solana, and 95+ other chains from a single pipeline.</span>
</div>
<div class="uc-card">
<span class="uc-title">Full history</span>
<span class="uc-desc">Backfill complete transaction history for any address. Replay years of on-chain activity in hours, not weeks.</span>
</div>
<div class="uc-card">
<span class="uc-title">Real-time updates</span>
<span class="uc-desc">sub-500ms (dedicated infra) latency means your data reflects the latest wallet state.</span>
</div>
<div class="uc-card">
<span class="uc-title">Custom filtering</span>
<span class="uc-desc">Watch millions of addresses with filter-based pipelines. Add or remove wallets without redeploying.</span>
</div>
<div class="uc-card">
<span class="uc-title">Your infrastructure</span>
<span class="uc-desc">Deliver wallet data directly to your PostgreSQL, BigQuery, or data warehouse.</span>
</div>
</div>

## Key Numbers

- **100+ chains** indexed from a single platform
- **sub-500ms** block-to-database on dedicated infrastructure
- **1B+ events/day** processed across all pipelines
- **99.9% uptime** across production pipelines

## Get Started

Start indexing wallet activity across chains in minutes. Define your target addresses, pick your events, and start receiving data.

[Get a Demo](https://www.indexing.co/contact) | [Open the Console](https://console.indexing.co)


---
title: MCP Blockchain Data Access
url: https://www.indexing.co/solutions/agentic-engineering/mcp-data-access
description: Give AI agents direct, tool-based access to indexed blockchain data via Model Context Protocol. Query events, balances, and pipelines from any MCP-compatible agent.
tags: Solution, Agentic Engineering
---

AI agents are only as useful as the data they can access. When an agent needs to check a wallet balance, query recent swap events, or monitor a smart contract, it shouldn't need custom API integrations or database connections. It should call a tool and get structured data back.

Indexing Co's MCP server gives any MCP-compatible agent -- Claude, Cursor, or custom frameworks -- direct access to indexed blockchain data across 100+ chains through standard tool calls.

## How It Works

1. **Connect**: Add the Indexing Co MCP server to your agent's configuration. One connection, all data.

2. **Query**: Agents call tools like `get_events`, `query`, and `describe_data` to access indexed blockchain data. No SQL, no GraphQL -- just structured tool calls with structured responses.

3. **Act**: Agents use the returned data to make decisions, trigger actions, or feed downstream workflows. Real-time data means real-time agent capabilities.

## What Agents Can Do

### Query Indexed Events

Retrieve decoded blockchain events by chain, contract, event signature, or time range. Get structured data ready for agent reasoning -- not raw hex that needs parsing.

### Monitor Pipeline Status

Check pipeline health, event counts, and processing latency. Agents can self-monitor their data sources and alert on issues.

### Create & Manage Pipelines

Advanced agents can create new indexing pipelines, add filters, and configure transformations -- programmatic infrastructure management through tool calls.

### Describe Data Schemas

Agents can discover what data is available by calling `describe_data` to see field names, types, and sample values. Self-documenting data access.

## Why MCP for Blockchain Data

- **Zero integration overhead**: No API keys to manage, no SDKs to install, no endpoints to memorize -- MCP handles the protocol
- **Agent-native interface**: Tools with typed parameters and structured responses -- the way agents are designed to interact with systems
- **Composable**: Combine blockchain data tools with other MCP servers (databases, APIs, file systems) in the same agent
- **Framework-agnostic**: Works with Claude Desktop, Cursor, custom agent frameworks, and any MCP-compatible client

## Related Content

- [Introducing the Indexing Co MCP Server](/articles/indexing-co-mcp)
- [Agentic Engineering Data Infrastructure](/solutions/agentic-engineering)
- [Claude Skill for Pipeline Management](/articles/claude-skill-indexing-co-pipelines)

## Get Started

Add the Indexing Co MCP server to your agent and start querying blockchain data in minutes.

[Get a Demo](https://www.indexing.co/contact) | [MCP Documentation](https://www.indexing.co/articles/indexing-co-mcp)


---
title: Perpetual Markets Data Infrastructure
url: https://www.indexing.co/solutions/perpetual-markets
description: Index perp trades, funding rates, liquidations, and open interest across Hyperliquid, dYdX, GMX, and other on-chain derivatives protocols.
tags: Solution, Perpetual Markets
---

A position crosses the liquidation threshold. The liquidation bot fires. The transaction confirms. Your risk dashboard updates 12 seconds later because the indexer polled too slowly. The cascade is already underway by the time your system knows it started.

Perpetual markets run at high speed with high stakes. Traders, market makers, and protocol operators need trade data, funding snapshots, and liquidation events indexed within seconds, not buried in transaction logs. Indexing Co indexes every fill, rate update, and forced close across Hyperliquid, dYdX, GMX, Synthetix, and custom perp contracts.

## Use Cases

<div class="use-case-cards">
<div class="uc-card">
<span class="uc-title">Trade and Position Tracking</span>
<span class="uc-desc">Every order, fill, and position change across perpetual DEXs. Open interest by market, trader, and direction. Historical PnL by wallet. Indexing Co streams fill events to your database as blocks confirm, so trading terminals and risk dashboards work with current data.</span>
</div>
<div class="uc-card">
<span class="uc-title">Funding Rate Monitoring</span>
<span class="uc-desc">Funding rate snapshots across venues and markets. Rate divergences between Hyperliquid, GMX, and dYdX create arbitrage opportunities that close in minutes. Indexing Co captures rate update events with block-level timestamps so your systems catch the window, not the close.</span>
</div>
<div class="uc-card">
<span class="uc-title">Liquidation Events</span>
<span class="uc-desc">Liquidation transactions indexed in real time with position size, collateral seized, and liquidation price. Risk dashboards need this data to track cascades as they develop. Liquidation bots need it to find opportunities before competing bots do.</span>
</div>
<div class="uc-card">
<span class="uc-title">Market Maker Infrastructure</span>
<span class="uc-desc">Position changes, fill rates, fee rebates, and hedge ratios across multiple perp venues from a single pipeline. Indexing Co delivers the structured event stream trading desks need to run market-making operations without maintaining separate indexers for each protocol.</span>
</div>
</div>

## How It Fits

- **sub-500ms (dedicated infra)**: Liquidation and funding events reach your system within seconds of confirmation
- **Multi-venue support**: Hyperliquid, dYdX, GMX, Synthetix, and custom perp contracts from one platform
- **Custom schemas**: Map protocol-specific events: order types, margin modes, fee tiers, into your data model
- **Historical backfill**: Replay complete trade histories through the same pipeline definition used for live streams
- **Direct delivery**: Stream events to your PostgreSQL, BigQuery, or webhook endpoint

## Key Numbers

- **100+ chains** supported
- **sub-500ms** block-to-database on dedicated infrastructure
- **1B+ events/day** processed across all pipelines
- **99.9% uptime** across production pipelines

## Related Content

- [DeFi Data Infrastructure](/solutions/defi)
- [Prediction Markets Data Infrastructure](/solutions/prediction-markets)

## Get Started

[Talk to the Team](https://www.indexing.co/contact) | [Open the Console](https://console.indexing.co)


---
title: Prediction Markets Data Infrastructure
url: https://www.indexing.co/solutions/prediction-markets
description: Index market creation, trade events, resolution outcomes, and liquidity data across Polymarket, Azuro, and other prediction market protocols.
tags: Solution, Prediction Markets
---

A major news event breaks. Traders flood into a market. Your platform is showing odds from 8 seconds ago because your indexer can't keep up with the event volume. Trades execute at stale prices. Users complain. You're watching it happen in real time and can't do anything.

Prediction markets compress time into value: the faster your data, the better your product. Indexing Co handles the indexing layer across Polymarket, Azuro, and custom prediction protocols, so your platform reflects current market state rather than a recent approximation of it.

## Use Cases

<div class="use-case-cards">
<div class="uc-card">
<span class="uc-title">Real-Time Odds and Market State</span>
<span class="uc-desc">Odds update on every trade. A 5% position shift can move a 60/40 market to 55/45 in seconds. Indexing Co streams market state events directly to your frontend within sub-500ms (dedicated infra) of block confirmation. Your users see current prices, not cached ones.</span>
</div>
<div class="uc-card">
<span class="uc-title">Order and Trade History</span>
<span class="uc-desc">Every order placement, fill, partial fill, and cancellation across conditional token protocols and orderbook-based markets. Historical trade data feeds backtesting engines, market efficiency analysis, and trader performance tracking. The same pipeline handles both live events and historical backfills.</span>
</div>
<div class="uc-card">
<span class="uc-title">Resolution and Settlement Tracking</span>
<span class="uc-desc">When a market resolves, your platform needs to know immediately. Indexing Co captures oracle resolution events, settlement transactions, and payout distributions. Your UI can show final outcomes and pending claims within seconds of on-chain settlement.</span>
</div>
<div class="uc-card">
<span class="uc-title">Liquidity and Market Depth</span>
<span class="uc-desc">LP deposits, withdrawals, and pool size changes across AMM-based prediction markets. Track liquidity concentration by outcome, fee accrual by position, and depth-adjusted pricing. Critical for platforms with automated market makers managing multiple outcome pools.</span>
</div>
</div>

## How It Fits

- **sub-500ms (dedicated infra)**: From block confirmation to your database. Odds dashboards reflect current state
- **Multi-protocol support**: Polymarket (Polygon), Azuro (multiple chains), and custom contracts from unified pipelines
- **Custom transforms**: Decode conditional token events, CLOB fills, and AMM interactions into your data model
- **Webhook delivery**: Market events push to your backend on confirmation, no polling required
- **Historical backfill**: Replay full market histories through the same pipeline definition

## Key Numbers

- **100+ chains** supported for prediction market indexing
- **sub-500ms** block-to-database on dedicated infrastructure
- **1B+ events/day** processed across all pipelines

## Related Content

- [DeFi Data Infrastructure](/solutions/defi)

## Get Started

[Talk to the Team](https://www.indexing.co/contact) | [Open the Console](https://console.indexing.co)


---
title: Payments Data Infrastructure
url: https://www.indexing.co/solutions/payments
description: Index stablecoin transfers, payment settlements, and transaction flows across 100+ chains with sub-500ms latency for payment platforms and fintech teams.
tags: Solution, Payments
---

Payment platforms processing on-chain transactions need real-time visibility into transfer status, settlement confirmation, and transaction history. Whether you're building a payment gateway, a remittance service, or a stablecoin treasury, the data layer determines how fast you can confirm, reconcile, and report.

Indexing Co powers the data infrastructure behind payment platforms like Mesh, providing indexed data on stablecoin transfers, cross-chain settlements, and payment events across 100+ chains.

## Use Cases

<div class="use-case-cards">

<div class="uc-card">
<span class="uc-title">Stablecoin Transfer Tracking</span>
<span class="uc-desc">Index USDC, USDT, DAI, and other stablecoin transfers across all major chains. Track sender, receiver, amount, and confirmation status in real time.</span>
</div>

<div class="uc-card">
<span class="uc-title">Cross-Chain Settlement Monitoring</span>
<span class="uc-desc">Track payment flows that span multiple chains via bridges and cross-chain protocols. Unified view from initiation to final settlement, regardless of which chains are involved.</span>
</div>

<div class="uc-card">
<span class="uc-title">Payment Gateway Analytics</span>
<span class="uc-desc">Dashboards showing payment volume, success rates, average confirmation times, and fee analysis across chains and tokens. Historical data for trend analysis and capacity planning.</span>
</div>

<div class="uc-card">
<span class="uc-title">Merchant & Wallet Monitoring</span>
<span class="uc-desc">Watch specific wallet addresses or smart contracts for incoming payments. Trigger webhooks on receipt for instant notification and downstream processing. Filter by token, amount, or sender.</span>
</div>

</div>

## Why Indexing Co for Payments

<div class="use-case-cards">

<div class="uc-card">
<span class="uc-title">Sub-500ms confirmation</span>
<span class="uc-desc">Sub-500ms block-to-database latency on dedicated infrastructure means near-instant payment confirmation in your own systems.</span>
</div>

<div class="uc-card">
<span class="uc-title">Multi-chain, multi-token</span>
<span class="uc-desc">Track any ERC-20 transfer across 100+ live chains from a single pipeline definition. Any additional chain available on request.</span>
</div>

<div class="uc-card">
<span class="uc-title">Webhook delivery</span>
<span class="uc-desc">Push payment events directly to your backend. No polling required, no shared API layer between the chain and your infrastructure.</span>
</div>

<div class="uc-card">
<span class="uc-title">Custom filtering</span>
<span class="uc-desc">Watch millions of wallets with filter-based pipelines. Add or remove addresses without redeploying.</span>
</div>

<div class="uc-card">
<span class="uc-title">Battle-tested</span>
<span class="uc-desc">Powering payment data for Mesh and other production payment platforms at scale.</span>
</div>

</div>

## Key Numbers

- **100+ chains** covered for payment tracking
- **sub-500ms** block-to-database latency on dedicated infrastructure
- **1B+ events/day** processed across all pipelines
- **1.6 TB/day** of raw blockchain data ingested

## FAQ

### What stablecoins and tokens can I track?
Any ERC-20 or SPL token on any of our 100+ supported chains. USDC, USDT, DAI, PYUSD, and custom tokens are all supported out of the box. You define the contract addresses and chains in your pipeline configuration.

### How fast do I get payment confirmations?
Sub-500ms block-to-database latency on dedicated infrastructure, sub-3-seconds on shared plans. Events are pushed to your database or webhook endpoint as soon as the block is confirmed on-chain.

### Can I watch millions of wallet addresses?
Yes. Our filter-based pipelines support millions of watched addresses with no performance degradation. You can add or remove addresses without redeploying your pipeline.

### What databases can I deliver payment data to?
PostgreSQL, BigQuery, webhooks, and 13+ other destinations on enterprise plans. Data arrives in your schema, in your infrastructure. No vendor-hosted APIs to query.

### How does Indexing Co handle chain reorgs?
Our pipeline engine tracks chain reorganizations and automatically replays affected blocks. Your database always reflects the canonical chain state without manual intervention.

## Get Started

Set up a payment data pipeline in minutes. Define your token contracts, target wallets, and start receiving structured payment events.

[Get a Demo](https://www.indexing.co/contact) | [Open the Console](https://console.indexing.co)


---
title: Indexing Co Brandbook
url: https://www.indexing.co/assets/brandbook
description: Brand guidelines for colors, typography, voice, and UI components. v2.0 — March 2026
---

<div class="bb">

<script src="https://code.iconify.design/iconify-icon/2.1.0/iconify-icon.min.js"></script>

<div class="bb-header">
  <div class="bb-header-title">
    <div class="bb-green-square"></div>
    <h2>Brandbook</h2>
  </div>
  <p>Indexing Co brand guidelines. Colors, typography, voice, and components.</p>
</div>

<div class="bb-layout">

<nav class="bb-sidebar">
  <button class="bb-nav-toggle" aria-expanded="false">
    <span class="bb-nav-toggle-label">Logo</span>
    <svg class="bb-nav-toggle-icon" width="12" height="12" viewBox="0 0 12 12" fill="none"><path d="M3 4.5L6 7.5L9 4.5" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/></svg>
  </button>
  <div class="bb-nav-items">
  <button class="bb-tab-btn active" data-tab="logos">Logo</button>
  <button class="bb-tab-btn" data-tab="colors">Colors</button>
  <button class="bb-tab-btn" data-tab="typography">Typography</button>
  <button class="bb-tab-btn" data-tab="voice">Voice and Tone</button>
  <button class="bb-tab-btn" data-tab="ui">UI Components</button>
  <button class="bb-tab-btn" data-tab="principles">Principle Cards</button>
  <button class="bb-tab-btn" data-tab="lists">Lists</button>
  <button class="bb-tab-btn" data-tab="codecards">Code Cards</button>
  <button class="bb-tab-btn" data-tab="toggles">Toggles</button>
  <button class="bb-tab-btn" data-tab="navigation">Navigation</button>
  <button class="bb-tab-btn" data-tab="competitive">Competitive Cards</button>
  <button class="bb-tab-btn" data-tab="stats">Stat Cards</button>
  <button class="bb-tab-btn" data-tab="preview">Website Preview</button>
  <button class="bb-tab-btn" data-tab="pixelicons">Pixel Icons</button>
  <button class="bb-tab-btn" data-tab="infogfx">Infographic Elements</button>
  <button class="bb-tab-btn" data-tab="infographic">Infographic</button>
  </div>
  <div class="bb-sidebar-version">v2.0 — March 2026</div>
</nav>

<div class="bb-content">

<!-- ══════════ LOGOS ══════════ -->
<div class="bb-panel active" id="tab-logos">
<h3>Wordmark (New)</h3>
<p class="bb-desc">Primary horizontal mark. Use on solid backgrounds. Maintain clear space equal to the height of the "x" in the wordmark on all sides. Minimum size: 76px (digital), 27mm (print).</p>
<div class="bb-logo-grid">
  <div class="bb-logo-card bb-bg-white"><img src="/assets/wordmark-new.svg" alt="Wordmark light" /><a href="/assets/wordmark-new.svg" class="bb-dl">SVG</a></div>
  <div class="bb-logo-card bb-bg-black"><img src="/assets/wordmark-new.svg" alt="Wordmark dark" style="filter:invert(1)" /><a href="/assets/wordmark-new.svg" class="bb-dl">SVG</a></div>
</div>

<h3>Wordmark Vertical</h3>
<p class="bb-desc">Stacked variant for square or tall layouts. Same clear space rules apply.</p>
<div class="bb-logo-grid">
  <div class="bb-logo-card bb-bg-white"><img src="/assets/wordmark-vertical.svg" alt="Vertical light" style="height:64px" /><a href="/assets/wordmark-vertical.svg" class="bb-dl">SVG</a></div>
  <div class="bb-logo-card bb-bg-black"><img src="/assets/wordmark-vertical.svg" alt="Vertical dark" style="height:64px;filter:invert(1)" /><a href="/assets/wordmark-vertical.svg" class="bb-dl">SVG</a></div>
</div>

<h3>Square Logo</h3>
<p class="bb-desc">Compact mark for square contexts (favicons, app icons, social avatars).</p>
<div class="bb-logo-grid">
  <div class="bb-logo-card bb-bg-white"><img src="/assets/square.svg" alt="Square light" style="height:60px" /><a href="/assets/square.svg" class="bb-dl">SVG</a></div>
  <div class="bb-logo-card bb-bg-black"><img src="/assets/square.svg" alt="Square dark" style="height:60px;filter:invert(1)" /><a href="/assets/square.svg" class="bb-dl">SVG</a></div>
</div>

<h3>Dex Mascot</h3>
<p class="bb-desc">Geometric pixel rabbit. Full 3D version, pixel 2-bit variants, retro hand-drawn, and emoji (128x128 PNG for Slack/Discord).</p>
<div class="bb-logo-grid bb-wrap">
  <div class="bb-logo-card bb-bg-dark bb-logo-sm"><img src="/assets/dex-white.svg" alt="Dex 3D" style="height:60px" /><span class="bb-label">Dex (3D)</span><a href="/assets/dex-white.svg" class="bb-dl">SVG</a></div>
  <div class="bb-logo-card bb-bg-black bb-logo-sm"><img src="/assets/dex-bit.svg" alt="Dex Bit" style="height:60px" /><span class="bb-label">2-Bit (dark)</span><a href="/assets/dex-bit.svg" class="bb-dl">SVG</a></div>
  <div class="bb-logo-card bb-bg-white bb-logo-sm"><img src="/assets/dex-bit-light.svg" alt="Dex Bit light" style="height:60px" /><span class="bb-label">2-Bit (light)</span><a href="/assets/dex-bit-light.svg" class="bb-dl">SVG</a></div>
  <div class="bb-logo-card bb-bg-dark bb-logo-sm"><img src="/assets/dex-retro.svg" alt="Dex Retro" style="height:60px" /><span class="bb-label">Retro</span><a href="/assets/dex-retro.svg" class="bb-dl">SVG</a></div>
  <div class="bb-logo-card bb-bg-black bb-logo-sm"><img src="/assets/dex-emoji.png" alt="Dex Emoji" style="height:50px" /><span class="bb-label">Emoji</span><a href="/assets/dex-emoji.png" class="bb-dl">PNG</a></div>
</div>

<h3>Usage Rules</h3>
<div class="bb-rules-grid">
  <div class="bb-rule-card">
    <div class="bb-rule-header bb-green"><svg xmlns="http://www.w3.org/2000/svg" width="14" height="14" fill="currentColor" viewBox="0 0 256 256"><path d="M229.66,77.66l-128,128a8,8,0,0,1-11.32,0l-56-56a8,8,0,0,1,11.32-11.32L96,188.69,218.34,66.34a8,8,0,0,1,11.32,11.32Z"/></svg> DO</div>
    <ul><li>Use on solid backgrounds (white or black)</li><li>Maintain clear space around the mark</li><li>Use provided SVG files at correct aspect ratio</li><li>Scale proportionally</li></ul>
  </div>
  <div class="bb-rule-card">
    <div class="bb-rule-header bb-muted"><svg xmlns="http://www.w3.org/2000/svg" width="14" height="14" fill="currentColor" viewBox="0 0 256 256"><path d="M205.66,194.34a8,8,0,0,1-11.32,11.32L128,139.31,61.66,205.66a8,8,0,0,1-11.32-11.32L116.69,128,50.34,61.66A8,8,0,0,1,61.66,50.34L128,116.69l66.34-66.35a8,8,0,0,1,11.32,11.32L139.31,128Z"/></svg> DON'T</div>
    <ul class="bb-muted-list"><li>Distort, stretch, or skew the mark</li><li>Place on busy or patterned backgrounds</li><li>Modify letterforms or spacing</li><li>Add effects (shadows, glows, outlines)</li><li>Recreate in a different typeface</li></ul>
  </div>
</div>
</div>

<!-- ══════════ COLORS ══════════ -->
<div class="bb-panel" id="tab-colors">
<h3>Primary Colors</h3>
<div class="bb-swatch-grid">
  <div class="bb-swatch"><div class="bb-swatch-color" style="background:#000"></div><div class="bb-swatch-meta"><span>Black</span><code>#000000</code></div></div>
  <div class="bb-swatch"><div class="bb-swatch-color bb-swatch-border" style="background:#FFF"></div><div class="bb-swatch-meta"><span>White</span><code>#FFFFFF</code></div></div>
  <div class="bb-swatch"><div class="bb-swatch-color" style="background:#4AF120"></div><div class="bb-swatch-meta"><span>Indexing Green</span><code>#4AF120</code></div></div>
  <div class="bb-swatch"><div class="bb-swatch-color" style="background:#DD67AB"></div><div class="bb-swatch-meta"><span>Pink</span><code>#DD67AB</code></div></div>
  <div class="bb-swatch"><div class="bb-swatch-color" style="background:#8E8E93"></div><div class="bb-swatch-meta"><span>Gray</span><code>#8E8E93</code></div></div>
  <div class="bb-swatch"><div class="bb-swatch-color" style="background:#EDEDED"></div><div class="bb-swatch-meta"><span>White Smoke</span><code>#EDEDED</code></div></div>
</div>
<p class="bb-desc">Green: accent on dark backgrounds only. Pink: secondary accent for visualizations. Black and white dominate primary content.</p>
<div class="bb-callout bb-callout-red"><strong>Accessibility:</strong> Brand green fails WCAG AA on white (~1.5:1). Only use on dark/black backgrounds (~13.9:1 on black).</div>

<h3>Gray Scale</h3>
<div class="bb-swatch-grid">
  <div class="bb-swatch"><div class="bb-swatch-color" style="background:#a3a3b2"></div><div class="bb-swatch-meta"><span>Gray 2</span><code>#A3A3B2</code></div></div>
  <div class="bb-swatch"><div class="bb-swatch-color" style="background:#c7c7cc"></div><div class="bb-swatch-meta"><span>Gray 3</span><code>#C7C7CC</code></div></div>
  <div class="bb-swatch"><div class="bb-swatch-color" style="background:#d1d1d6"></div><div class="bb-swatch-meta"><span>Gray 4</span><code>#D1D1D6</code></div></div>
  <div class="bb-swatch"><div class="bb-swatch-color" style="background:#e5e5ea"></div><div class="bb-swatch-meta"><span>Gray 5</span><code>#E5E5EA</code></div></div>
  <div class="bb-swatch"><div class="bb-swatch-color" style="background:#f2f2f7"></div><div class="bb-swatch-meta"><span>Gray 6</span><code>#F2F2F7</code></div></div>
</div>
<p class="bb-desc">Card borders: Gray-5. Dividers: Gray-4. Lightest (Gray-6) to darkest (Gray-2) in light mode, reverses in dark.</p>

<h3>Accessibility</h3>
<table class="bb-table"><thead><tr><th>Foreground</th><th>Background</th><th>Ratio</th><th>WCAG AA</th></tr></thead><tbody>
<tr><td><code>#000000</code></td><td><code>#FFFFFF</code></td><td>21:1</td><td class="bb-green">Pass</td></tr>
<tr><td><code>#FFFFFF</code></td><td><code>#000000</code></td><td>21:1</td><td class="bb-green">Pass</td></tr>
<tr><td><code style="color:#4af120">#4AF120</code></td><td><code>#000000</code></td><td>~13.9:1</td><td class="bb-green">Pass</td></tr>
<tr><td><code style="color:#4af120">#4AF120</code></td><td><code>#FFFFFF</code></td><td>~1.5:1</td><td class="bb-red">Fail</td></tr>
</tbody></table>
</div>

<!-- ══════════ TYPOGRAPHY ══════════ -->
<div class="bb-panel" id="tab-typography">
<h3>Type Stack</h3>
<p class="bb-desc">Primary: Inter. Code: Fira Code 500.</p>
<div class="bb-type-samples">
  <div class="bb-type-sample"><span class="bb-type-label">Jumbo — Inter Light 300 / 60px / 110%</span><span style="font-size:48px;font-weight:300;line-height:110%;letter-spacing:-2px">The quick brown fox</span></div>
  <div class="bb-type-sample"><span class="bb-type-label">Display — Inter Regular 400 / 48px / 110%</span><span style="font-size:38px;font-weight:400;line-height:110%;letter-spacing:-1.8px">The quick brown fox</span></div>
  <div class="bb-type-sample"><span class="bb-type-label">Headline — Inter Medium 500 / 28px / 120%</span><span style="font-size:28px;font-weight:500;line-height:120%;letter-spacing:-1.2px">The quick brown fox jumps over the lazy dog</span></div>
  <div class="bb-type-sample"><span class="bb-type-label">Subhead — Inter Regular 400 / 24px / 130%</span><span style="font-size:24px;font-weight:400;line-height:130%;letter-spacing:-0.8px">The quick brown fox jumps over the lazy dog</span></div>
  <div class="bb-type-sample"><span class="bb-type-label">Body — Inter Regular 400 / 16px / 150%</span><span style="font-size:16px;font-weight:400;line-height:150%">The quick brown fox jumps over the lazy dog</span></div>
  <div class="bb-type-sample"><span class="bb-type-label">Caption — Inter 400 / 14px / 140%</span><span style="font-size:14px;color:rgba(255,255,255,0.4)">The quick brown fox jumps over the lazy dog</span></div>
  <div class="bb-type-sample"><span class="bb-type-label">Code — Fira Code 500 / 16px / 110%</span><span style="font-family:'Fira Code',monospace;font-size:16px;font-weight:500;letter-spacing:-1px">The quick brown fox jumps</span></div>
</div>

<h3>Type Scale</h3>
<table class="bb-table"><thead><tr><th>Style</th><th>Size</th><th>Weight</th><th>Line-height</th><th>Notes</th></tr></thead><tbody>
<tr><td>Jumbo</td><td><code>60/36px</code></td><td>300</td><td>110%</td><td>Hero statements</td></tr>
<tr><td>Display</td><td><code>48/30px</code></td><td>400</td><td>110%</td><td>Section titles</td></tr>
<tr><td>Headline</td><td><code>28/22px</code></td><td>500</td><td>120%</td><td>Page titles, cards</td></tr>
<tr><td>Subhead</td><td><code>24/20px</code></td><td>400</td><td>130%</td><td>Section subtitles</td></tr>
<tr><td>Body Large</td><td><code>18px</code></td><td>400</td><td>140%</td><td></td></tr>
<tr><td>Body Base</td><td><code>16px</code></td><td>400</td><td>150%</td><td></td></tr>
<tr><td>Caption</td><td><code>14px</code></td><td>400</td><td>140%</td><td></td></tr>
<tr><td>Label</td><td><code>16px</code></td><td>500</td><td>100%</td><td></td></tr>
<tr><td>Link</td><td><code>16px</code></td><td>400</td><td>100%</td><td>Always underlined</td></tr>
<tr><td>Code</td><td><code>16px</code></td><td>500</td><td>110%</td><td>Fira Code</td></tr>
</tbody></table>

<h3>Weight Mapping</h3>
<table class="bb-table"><thead><tr><th>Weight</th><th>Name</th><th>Usage</th></tr></thead><tbody>
<tr><td>300</td><td>Light</td><td class="bb-muted">Jumbo headings only</td></tr>
<tr><td>400</td><td>Regular</td><td class="bb-muted">Default: display, subhead, body, caption, link</td></tr>
<tr><td>500</td><td>Medium</td><td class="bb-muted">Headline, bold variants, labels, code</td></tr>
<tr><td>600</td><td>Semi Bold</td><td class="bb-muted">Label Bold only</td></tr>
</tbody></table>
</div>

<!-- ══════════ VOICE AND TONE ══════════ -->
<div class="bb-panel" id="tab-voice">
<p class="bb-intro">Indexing Co writing operates at the intersection of technical explanation and commercial persuasion. Every sentence earns its place by explaining how something works or pushing the reader toward action. The voice carries authority without formality: direct, technically precise, momentum-focused, no hype.</p>

<h3>Core Principles</h3>
<div class="bb-principles-grid">
  <div class="bb-principle"><h4>Lead with capability, not feature.</h4><p>Open with what the reader can now do, not what the product contains.</p></div>
  <div class="bb-principle"><h4>Follow every claim with mechanism or evidence.</h4><p>Assertion, then proof. Never let a claim float unsupported.</p></div>
  <div class="bb-principle"><h4>Compress time as the value metric.</h4><p>"Collapses the time between 'we need this data' and 'data is flowing'" beats "makes it faster."</p></div>
  <div class="bb-principle"><h4>Name friction points directly.</h4><p>Don't euphemize problems. Technical audiences respect honest diagnosis.</p></div>
  <div class="bb-principle"><h4>Position against incomplete solutions.</h4><p>Acknowledge existing approaches, then highlight their blind spots.</p></div>
  <div class="bb-principle"><h4>Embed authority in observation.</h4><p>Report patterns. Authority comes from clarity of analysis, not self-description.</p></div>
</div>

<h3>Vocabulary</h3>
<div class="bb-rules-grid">
  <div class="bb-rule-card">
    <div class="bb-rule-header bb-green"><svg xmlns="http://www.w3.org/2000/svg" width="14" height="14" fill="currentColor" viewBox="0 0 256 256"><path d="M229.66,77.66l-128,128a8,8,0,0,1-11.32,0l-56-56a8,8,0,0,1,11.32-11.32L96,188.69,218.34,66.34a8,8,0,0,1,11.32,11.32Z"/></svg> DO USE</div>
    <ul class="bb-mono-list"><li>writes, deploys, tracks, reshapes, compresses, ships</li><li>production-grade, raw block data, structured output</li><li>technical terms in operational context</li></ul>
    <div class="bb-divider"></div>
    <p class="bb-phrase">"collapses the time between X and Y"</p>
    <p class="bb-phrase">"No config files. No deployment platforms."</p>
  </div>
  <div class="bb-rule-card">
    <div class="bb-rule-header bb-muted"><svg xmlns="http://www.w3.org/2000/svg" width="14" height="14" fill="currentColor" viewBox="0 0 256 256"><path d="M205.66,194.34a8,8,0,0,1-11.32,11.32L128,139.31,61.66,205.66a8,8,0,0,1-11.32-11.32L116.69,128,50.34,61.66A8,8,0,0,1,61.66,50.34L128,116.69l66.34-66.35a8,8,0,0,1,11.32,11.32L139.31,128Z"/></svg> AVOID</div>
    <ul class="bb-mono-list bb-strike"><li>enables, empowers, facilitates</li><li>revolutionary, next-generation, cutting-edge</li><li>game-changer, innovative solution</li><li>jargon without workflow role</li><li>vague intensifiers: really, very, quite, fairly</li></ul>
  </div>
</div>

<h3>Sentence Style</h3>
<p class="bb-desc">Default to short: one idea per sentence. Subject, verb, object. Extend only for enumeration using colons or parallel structure. Fragments are deliberate. Front-load subject and verb so the actor stays visible.</p>

<h3>Platform Guide</h3>
<div class="bb-rules-grid">
  <div class="bb-platform-card"><h4>LinkedIn</h4><dl><dt>Open with</dt><dd>Contrarian hook or counterintuitive claim</dd><dt>Body</dt><dd>Compressed argument, short paragraphs</dd><dt>Close with</dt><dd>Planning question that prompts discussion</dd><dt>Reader</dt><dd>Scanning for insight they don't already have</dd></dl></div>
  <div class="bb-platform-card"><h4>Website</h4><dl><dt>Open with</dt><dd>Capability statement</dd><dt>Body</dt><dd>Procedural walkthrough, step-by-step detail</dd><dt>Close with</dt><dd>Numbered steps and concrete next action</dd><dt>Reader</dt><dd>Arrived with intent, seeking implementation detail</dd></dl></div>
</div>

<h3>Anti-Patterns</h3>
<div class="bb-callout bb-callout-red"><strong>Avoid:</strong><ul><li>Hedging: "can help you write" vs "writes"</li><li>Buried leads: context before the point</li><li>Rhetorical questions that are statements</li><li>Passive voice that hides agency</li><li>Explaining basics to a technical audience</li><li>Ending on hype: "Don't miss out"</li></ul></div>
</div>

<!-- ══════════ UI COMPONENTS ══════════ -->
<div class="bb-panel" id="tab-ui">
<h3>Buttons</h3>
<div class="bb-preview">
  <button class="bb-btn bb-btn-lg">Large</button>
  <button class="bb-btn bb-btn-md">Medium</button>
  <button class="bb-btn bb-btn-sm">Small</button>
  <button class="bb-btn bb-btn-out">Outlined</button>
</div>
<table class="bb-table"><thead><tr><th>Variant</th><th>Padding</th><th>Font-size</th><th>Notes</th></tr></thead><tbody>
<tr><td>Large</td><td><code>16px 32px</code></td><td>16px</td><td>Primary CTA</td></tr>
<tr><td>Medium</td><td><code>12px 20px</code></td><td>16px</td><td></td></tr>
<tr><td>Small</td><td><code>8px 16px</code></td><td>14px</td><td></td></tr>
<tr><td>Outlined</td><td><code>12px 20px</code></td><td>16px</td><td>Border matches text</td></tr>
</tbody></table>
<p class="bb-desc">All buttons: pill shape (border-radius: 100px), opacity 0.8 on hover, 0.2s ease transition.</p>

<h3>Cards</h3>
<div class="bb-preview">
  <div class="bb-demo-cards">
    <div class="bb-pricing-card">
      <h5>Starter</h5>
      <p>For teams getting started with onchain data.</p>
      <p class="bb-price">$0 <span>/month</span></p>
      <ul><li><span class="bb-check">&#10003;</span> 10,000 free credits</li><li><span class="bb-check">&#10003;</span> Shared infrastructure</li><li><span class="bb-check">&#10003;</span> Community support</li></ul>
      <button class="bb-btn bb-btn-md" style="width:100%;margin-top:12px">Get Started</button>
    </div>
    <div class="bb-addon-card"><h5>Add-on: Custom Transforms</h5><p>Write custom JavaScript transformation functions for your pipelines.</p></div>
  </div>
</div>
<table class="bb-table"><thead><tr><th>Type</th><th>Padding</th><th>Border</th><th>Radius</th><th>Background</th></tr></thead><tbody>
<tr><td>Pricing</td><td><code>24px</code></td><td>1px solid Gray-5</td><td>8px</td><td>Primary</td></tr>
<tr><td>Add-on</td><td><code>24px</code></td><td>none</td><td>8px</td><td>Secondary</td></tr>
<tr><td>Case study</td><td><code>24px</code></td><td>1px solid Gray-5</td><td>8px</td><td>Primary</td></tr>
</tbody></table>

<h3>Spacing</h3>
<div class="bb-preview"><div class="bb-spacing-row"><div class="bb-sp" style="width:64px;height:64px">64</div><div class="bb-sp" style="width:40px;height:40px">40</div><div class="bb-sp" style="width:24px;height:24px">24</div><div class="bb-sp" style="width:16px;height:16px">16</div><div class="bb-sp" style="width:10px;height:10px"><span style="font-size:6px">10</span></div></div></div>
<table class="bb-table"><thead><tr><th>Token</th><th>Value</th><th>Usage</th></tr></thead><tbody>
<tr><td>Section gap</td><td><code>64px</code></td><td class="bb-muted">Between section title and content</td></tr>
<tr><td>Card padding</td><td><code>24px</code></td><td class="bb-muted">Pricing, add-on cards</td></tr>
<tr><td>Card gap</td><td><code>16px</code></td><td class="bb-muted">Grid gap between cards</td></tr>
<tr><td>Card radius</td><td><code>8px / 4px</code></td><td class="bb-muted">Default 8px, use-case 4px</td></tr>
</tbody></table>

<h3>Responsive Breakpoints</h3>
<table class="bb-table"><thead><tr><th>Breakpoint</th><th>Rule</th><th>Behavior</th></tr></thead><tbody>
<tr><td>Mobile</td><td><code>&le;768px</code></td><td class="bb-muted">Single-column, reduced font sizes</td></tr>
<tr><td>Tablet</td><td><code>&ge;769px</code></td><td class="bb-muted">2-column pricing grid</td></tr>
<tr><td>Desktop</td><td><code>&ge;1200px</code></td><td class="bb-muted">4-column add-ons, full carousel</td></tr>
</tbody></table>
</div>

<!-- ══════════ PRINCIPLE CARDS ══════════ -->
<div class="bb-panel" id="tab-principles">
<p class="bb-desc">Left-bordered cards with a green hover accent. Used for feature lists, voice principles, value propositions, or any content pairing a title with a short description.</p>
<div class="bb-principles-grid">
  <div class="bb-principle"><h4>Lead with capability</h4><p>State exactly what the system does. Omit marketing wrappers.</p></div>
  <div class="bb-principle"><h4>Follow claims with evidence</h4><p>If we claim speed, we provide the benchmark. Never orphaned assertions.</p></div>
  <div class="bb-principle"><h4>Compress time as value</h4><p>Time is the ultimate metric. Frame benefits around time saved.</p></div>
  <div class="bb-principle"><h4>Name friction directly</h4><p>Identify pain points. Don't use euphemisms for broken systems.</p></div>
  <div class="bb-principle"><h4>Position against incomplete solutions</h4><p>Acknowledge existing approaches, highlight blind spots.</p></div>
  <div class="bb-principle"><h4>Embed authority in observation</h4><p>Report patterns. Show the work.</p></div>
</div>
<h3>Spec</h3>
<table class="bb-table"><thead><tr><th>Property</th><th>Value</th></tr></thead><tbody>
<tr><td>Border left</td><td><code>2px solid rgba(255,255,255,0.1)</code></td></tr>
<tr><td>Hover border</td><td><code>#4AF120</code></td></tr>
<tr><td>Padding left</td><td><code>16px</code></td></tr>
<tr><td>Transition</td><td><code>border-color 0.3s ease</code></td></tr>
</tbody></table>
</div>

<!-- ══════════ LISTS ══════════ -->
<div class="bb-panel" id="tab-lists">
<p class="bb-desc">Panel cards with icon header and monospace list items. <strong>Do</strong> variant highlights in green. <strong>Avoid</strong> uses gray with strikethrough. <strong>Info</strong> for neutral informational lists.</p>
<div class="bb-list-grid">
  <div class="bb-list-card">
    <div class="bb-list-header bb-green"><svg xmlns="http://www.w3.org/2000/svg" width="14" height="14" fill="currentColor" viewBox="0 0 256 256"><path d="M229.66,77.66l-128,128a8,8,0,0,1-11.32,0l-56-56a8,8,0,0,1,11.32-11.32L96,188.69,218.34,66.34a8,8,0,0,1,11.32,11.32Z"/></svg> DO USE</div>
    <ul class="bb-mono-list"><li>writes</li><li>deploys</li><li>tracks</li><li>ships</li></ul>
    <div class="bb-divider"></div>
    <p class="bb-phrase">"collapses the time between X and Y"</p>
  </div>
  <div class="bb-list-card">
    <div class="bb-list-header bb-muted"><svg xmlns="http://www.w3.org/2000/svg" width="14" height="14" fill="currentColor" viewBox="0 0 256 256"><path d="M205.66,194.34a8,8,0,0,1-11.32,11.32L128,139.31,61.66,205.66a8,8,0,0,1-11.32-11.32L116.69,128,50.34,61.66A8,8,0,0,1,61.66,50.34L128,116.69l66.34-66.35a8,8,0,0,1,11.32,11.32L139.31,128Z"/></svg> AVOID</div>
    <ul class="bb-mono-list bb-strike"><li>enables</li><li>empowers</li><li>revolutionary</li><li>game-changer</li><li>really / very / quite</li></ul>
  </div>
  <div class="bb-list-card">
    <div class="bb-list-header"><svg xmlns="http://www.w3.org/2000/svg" width="14" height="14" fill="currentColor" viewBox="0 0 256 256"><path d="M128,24A104,104,0,1,0,232,128,104.11,104.11,0,0,0,128,24Zm0,192a88,88,0,1,1,88-88A88.1,88.1,0,0,1,128,216Zm-8-80V80a8,8,0,0,1,16,0v56a8,8,0,0,1-16,0Zm20,36a12,12,0,1,1-12-12A12,12,0,0,1,140,172Z"/></svg> INFO</div>
    <ul class="bb-info-list"><li>Supported: Ethereum, Polygon, Base, Arbitrum</li><li>Output: Postgres, webhooks, Kafka</li><li>Backfill: full from genesis block</li></ul>
  </div>
</div>
<h3>Spec</h3>
<table class="bb-table"><thead><tr><th>Property</th><th>Value</th></tr></thead><tbody>
<tr><td>Background</td><td><code>rgba(255,255,255,0.03)</code></td></tr>
<tr><td>Border</td><td><code>1px solid rgba(255,255,255,0.1)</code></td></tr>
<tr><td>Radius</td><td><code>12px</code></td></tr>
<tr><td>List font</td><td><code>Fira Code, 14px</code></td></tr>
<tr><td>Avoid variant</td><td><code>line-through, muted color</code></td></tr>
</tbody></table>
</div>

<!-- ══════════ CODE CARDS ══════════ -->
<div class="bb-panel" id="tab-codecards">
<p class="bb-desc">Split-layout card with a top accent bar and a code/content preview panel with window chrome dots.</p>

<div class="bb-code-card">
  <div class="bb-code-accent"></div>
  <div class="bb-code-split">
    <div class="bb-code-meta"><h4>LinkedIn</h4><p>Contrarian hook, compressed argument.</p><span class="bb-tag">Goal: Stop the scroll with a technical truth.</span></div>
    <div class="bb-code-preview"><div class="bb-dots"><span></span><span></span><span></span></div><p class="bb-bold">Stop maintaining custom RPC nodes just to read state.</p><p class="bb-muted">RPCs are for broadcasting transactions, not querying historical data at scale.</p><p class="bb-green">Deploy a dedicated indexer in 45 seconds. Query with GraphQL immediately.</p></div>
  </div>
</div>

<div class="bb-code-card" style="margin-top:16px">
  <div class="bb-code-accent" style="background:#4af120"></div>
  <div class="bb-code-split">
    <div class="bb-code-meta"><h4>Website</h4><p>Capability statement, procedural depth.</p><span class="bb-tag">Goal: Prove competence through detail.</span></div>
    <div class="bb-code-preview"><div class="bb-dots"><span></span><span></span><span></span></div><h5 style="font-size:15px;font-weight:600;margin:0 0 8px">Real-time state synchronization</h5><p class="bb-muted">Indexing Co writes directly to your Postgres. We process raw block data and decode ABI events automatically.</p><div class="bb-mini-stats"><div><span class="bb-muted">Latency:</span> Sub 50ms</div><div><span class="bb-muted">Throughput:</span> 100k+ events/sec</div></div></div>
  </div>
</div>

<h3>Spec</h3>
<table class="bb-table"><thead><tr><th>Property</th><th>Value</th></tr></thead><tbody>
<tr><td>Top accent bar</td><td><code>2px, changes color on hover</code></td></tr>
<tr><td>Layout</td><td><code>1/3 meta + 2/3 preview</code></td></tr>
<tr><td>Preview font</td><td><code>Fira Code (mono), 14px</code></td></tr>
<tr><td>Window dots</td><td><code>3x circles, top-right</code></td></tr>
<tr><td>Highlight colors</td><td><code>white + #4AF120</code></td></tr>
</tbody></table>
</div>

<!-- ══════════ TOGGLES ══════════ -->
<div class="bb-panel" id="tab-toggles">
<p class="bb-desc">Pill-shaped segmented control. Active indicator slides between options. Green variant for primary actions, white for neutral selection.</p>
<div class="bb-preview">
  <div class="bb-toggle-row">
    <div class="bb-toggle-ex">
      <p class="bb-toggle-label">GREEN ACTIVE (MONTHLY)</p>
      <div class="bb-toggle"><button class="bb-tog-green">Monthly</button><button class="bb-tog-off">Annually <span>-20%</span></button></div>
    </div>
    <div class="bb-toggle-ex">
      <p class="bb-toggle-label">FOREGROUND ACTIVE (ANNUALLY)</p>
      <div class="bb-toggle"><button class="bb-tog-off">Monthly</button><button class="bb-tog-white">Annually <span>-20%</span></button></div>
    </div>
  </div>
</div>
<h3>Spec</h3>
<table class="bb-table"><thead><tr><th>Property</th><th>Value</th></tr></thead><tbody>
<tr><td>Container</td><td><code>bg: muted, radius: 100px, padding: 6px</code></td></tr>
<tr><td>Green variant</td><td><code>bg: #4AF120, text: black, weight: 600</code></td></tr>
<tr><td>Neutral variant</td><td><code>bg: white, text: black</code></td></tr>
<tr><td>Transition</td><td><code>transform 0.3s ease</code></td></tr>
</tbody></table>
</div>

<!-- ══════════ NAVIGATION ══════════ -->
<div class="bb-panel" id="tab-navigation">
<p class="bb-desc">Top navigation bar with backdrop blur over dark backgrounds. Logo mark, nav links, green pill CTA. Dropdown uses floating panel with icon + label + description items.</p>
<div class="bb-nav-demo">
  <div class="bb-nav-glow"></div>
  <nav class="bb-nav-bar"><div class="bb-nav-logo"><div class="bb-green-square" style="width:18px;height:18px"></div> <strong>Indexing</strong></div><div class="bb-nav-links"><span>Products</span><span class="active">Developers</span><span>Use Cases</span><span>Pricing</span></div><div class="bb-nav-right"><span>Log in</span><button class="bb-btn-cta">Start Building</button></div></nav>
  <div class="bb-dropdown">
    <div class="bb-dd-item"><div class="bb-dd-icon"></div><div><strong>Documentation</strong><span>Integration guides and API references</span></div></div>
    <div class="bb-dd-item"><div class="bb-dd-icon"></div><div><strong>CLI Tool</strong><span>Local development and deployment</span></div></div>
    <div class="bb-dd-item"><div class="bb-dd-icon"></div><div><strong>Network Status</strong><span>Real-time indexing node health</span></div></div>
    <div class="bb-dd-footer"><span>Current SDK Version</span><code>v2.4.1</code></div>
  </div>
  <div class="bb-nav-annot"><div class="bb-annot"><span class="bb-annot-dot pulse"></span>backdrop-blur-xl on black/60</div><div class="bb-annot"><span class="bb-annot-dot"></span>1px border-white/10 separator</div></div>
</div>
<h3>Spec</h3>
<table class="bb-table"><thead><tr><th>Property</th><th>Value</th></tr></thead><tbody>
<tr><td>Height</td><td><code>64px</code></td></tr>
<tr><td>Background</td><td><code>black/60 + backdrop-blur-xl</code></td></tr>
<tr><td>Dropdown bg</td><td><code>#111, radius 12px, shadow 0 16px 40px</code></td></tr>
<tr><td>CTA button</td><td><code>pill, bg: #4AF120, text: black</code></td></tr>
</tbody></table>
</div>

<!-- ══════════ COMPETITIVE CARDS ══════════ -->
<div class="bb-panel" id="tab-competitive">
<p class="bb-desc">VS cards for compare pages. Dark panel background, monospace pill tags, two-column legacy/direct split. Direct column border transitions to green on hover.</p>
<div class="bb-comp-card">
  <div class="bb-comp-header"><span class="bb-comp-muted">The Graph</span><span class="bb-comp-vs">VS</span><span class="bb-comp-green">Indexing Co.</span></div>
  <div class="bb-comp-tags"><span>Decentralized Network</span><span>AssemblyScript</span></div>
  <div class="bb-comp-split">
    <div class="bb-comp-left"><strong>Legacy Model</strong><p>Requires proprietary languages, complex DevOps for self-hosting, and tolerates significant network sync delays.</p></div>
    <div class="bb-comp-right"><strong>Direct Execution</strong><p>TypeScript pipelines written directly to your database. Zero middleware, instant sync, native developer experience.</p></div>
  </div>
  <span class="bb-comp-cta">Compare them now →</span>
</div>
<h3>Spec</h3>
<table class="bb-table"><thead><tr><th>Property</th><th>Value</th></tr></thead><tbody>
<tr><td>Background</td><td><code>#0A0A0A</code></td></tr>
<tr><td>Border</td><td><code>1px solid #1A1A1A → #8E8E93 hover</code></td></tr>
<tr><td>Tags</td><td><code>Fira Code 12px, pill, #000 bg</code></td></tr>
<tr><td>Direct border-left</td><td><code>→ #4AF120 on hover (0.5s)</code></td></tr>
<tr><td>Card padding</td><td><code>40px</code></td></tr>
</tbody></table>
</div>

<!-- ══════════ STAT CARDS ══════════ -->
<div class="bb-panel" id="tab-stats">
<p class="bb-desc">Stat cards for social proof. Black background, left accent bar (dark → white on hover), monospace headline number, bold label, gray description, code tag.</p>
<div class="bb-stat-grid">
  <div class="bb-stat-card"><div class="bb-stat-bar"></div><span class="bb-stat-num">Sub-second</span><strong>Block to your database</strong><p>Average block-to-storage latency across 100+ chains. No polling intervals, no middleware hops.</p><span class="bb-stat-tag">measured across ETH / BSC / Polygon</span></div>
  <div class="bb-stat-card"><div class="bb-stat-bar"></div><span class="bb-stat-num">Zero</span><strong>Extra API layers</strong><p>Data lands in your own database, your own schema. Query with SQL, your ORM, or any standard tooling.</p><span class="bb-stat-tag">direct database delivery</span></div>
  <div class="bb-stat-card"><div class="bb-stat-bar"></div><span class="bb-stat-num">100+</span><strong>Chains, one pipeline</strong><p>Single integration. No separate subgraph per chain, no chain-specific SDKs.</p><span class="bb-stat-tag">no per-chain contracts</span></div>
</div>
<h3>Spec</h3>
<table class="bb-table"><thead><tr><th>Property</th><th>Value</th></tr></thead><tbody>
<tr><td>Left accent</td><td><code>2px, #1A1A1A → #FFF on hover</code></td></tr>
<tr><td>Number</td><td><code>Fira Code 28px / 400</code></td></tr>
<tr><td>Label</td><td><code>16px / 600</code></td></tr>
<tr><td>Code tag</td><td><code>Fira Code 12px, #0A0A0A bg</code></td></tr>
<tr><td>Grid</td><td><code>3-col desktop, 1-col mobile, gap 40px</code></td></tr>
</tbody></table>
</div>

<!-- ══════════ WEBSITE PREVIEW ══════════ -->
<div class="bb-panel" id="tab-preview">
<p class="bb-desc">Redesigned front page of indexing.co using the brandbook's design system.</p>
<div class="bb-website">
  <nav class="bb-wp-nav"><img src="/assets/wordmark-new.svg" alt="Indexing Co" style="height:14px;filter:invert(1)" /><div class="bb-wp-links"><span>Solutions</span><span>Docs</span><span>Latest</span><span>Pricing</span></div><div class="bb-wp-right"><span>Try It</span><button class="bb-btn-cta">Get A Demo</button></div></nav>
  <section class="bb-wp-hero"><div class="bb-wp-glow"></div><h1>Stop reinventing the wheel.<br/><span>We build enterprise-grade infrastructure so you don't have to.</span></h1><p>Read, transform, and <em>use</em> onchain data. Sub-second latency, tailored configurations, delivered direct to you.</p><div class="bb-wp-btns"><button class="bb-btn-cta">Get A Demo</button><button class="bb-btn-out-w">Get Started</button></div></section>
  <section class="bb-wp-logos"><p>WORKING WITH THE INDUSTRY'S BEST</p><div class="bb-wp-logo-row"><span>MeshPay</span><span>Crystal Intelligence</span><span>Cordial Systems</span><span>Avalanche</span><span>Clanker</span></div></section>
  <section class="bb-wp-props"><div class="bb-wp-prop"><h3>Source Anywhere</h3><p>Access data from any chain in real-time.</p></div><div class="bb-wp-prop"><h3>Transform Everywhere</h3><p>Add your business logic. Infrastructure handles the rest.</p></div><div class="bb-wp-prop"><h3>Deliver Just-In-Time</h3><p>Pipelines integrate directly to your storage. No middlemen.</p></div></section>
  <section class="bb-wp-stats"><div><p>Supported Networks</p><span>100+</span></div><div><p>Processed Daily</p><span>1.6 TB</span></div><div><p>Avg Block-to-Storage</p><span>Sub-second</span></div></section>
  <section class="bb-wp-cta"><h2>Build with Indexing Co</h2><div class="bb-wp-btns"><button class="bb-btn-cta">Get Started</button><button class="bb-btn-out-w">Get A Demo</button></div></section>
  <footer class="bb-wp-footer"><div class="bb-wp-fcols"><div><p>Solutions</p><span>DeFi</span><span>Payments</span><span>Prediction Markets</span></div><div><p>Platform</p><span>Full Stack</span><span>Console</span><span>Pricing</span></div><div><p>Resources</p><span>Latest</span><span>Compare</span><span>Case Studies</span></div><div><p>Company</p><span>Contact</span><span>Twitter</span><span>Terms</span></div></div><div class="bb-wp-fbot"><span>&copy; The Indexing Company</span></div></footer>
</div>
</div>

<!-- ══════════ PIXEL ICONS ══════════ -->
<div class="bb-panel" id="tab-pixelicons">
<h3>Pixel Icon Family · Pixelarticons</h3>
<p class="bb-desc">Adopted icon family: <a href="https://pixelarticons.com/">Pixelarticons</a> (MIT, ~480 free / 4,052 pro, on Iconify as <code>pixelarticons</code>). Pixel-grid / 8-bit aesthetic that matches the Dex pixel mascot and the green-on-black, terminal feel. Monochrome <code>currentColor</code>, so it recolors to Indexing green directly.</p>

<h4>Color modes</h4>
<div class="bb-px-modes">
  <div class="bb-px-card bb-bg-black"><div class="bb-px-mode-lbl">Green on dark · primary</div><div class="bb-px-row bb-px-green">
    <span class="bb-px-tile"><iconify-icon icon="pixelarticons:database" width="26"></iconify-icon></span>
    <span class="bb-px-tile"><iconify-icon icon="pixelarticons:terminal" width="26"></iconify-icon></span>
    <span class="bb-px-tile"><iconify-icon icon="pixelarticons:zap" width="26"></iconify-icon></span>
    <span class="bb-px-tile"><iconify-icon icon="pixelarticons:git-branch" width="26"></iconify-icon></span>
  </div></div>
  <div class="bb-px-card bb-bg-black"><div class="bb-px-mode-lbl">White on dark · UI default</div><div class="bb-px-row bb-px-white">
    <span class="bb-px-tile"><iconify-icon icon="pixelarticons:database" width="26"></iconify-icon></span>
    <span class="bb-px-tile"><iconify-icon icon="pixelarticons:terminal" width="26"></iconify-icon></span>
    <span class="bb-px-tile"><iconify-icon icon="pixelarticons:zap" width="26"></iconify-icon></span>
    <span class="bb-px-tile"><iconify-icon icon="pixelarticons:git-branch" width="26"></iconify-icon></span>
  </div></div>
  <div class="bb-px-card bb-bg-black"><div class="bb-px-mode-lbl">Pink · secondary accent</div><div class="bb-px-row bb-px-pink">
    <span class="bb-px-tile"><iconify-icon icon="pixelarticons:database" width="26"></iconify-icon></span>
    <span class="bb-px-tile"><iconify-icon icon="pixelarticons:terminal" width="26"></iconify-icon></span>
    <span class="bb-px-tile"><iconify-icon icon="pixelarticons:zap" width="26"></iconify-icon></span>
    <span class="bb-px-tile"><iconify-icon icon="pixelarticons:git-branch" width="26"></iconify-icon></span>
  </div></div>
  <div class="bb-px-card bb-bg-green"><div class="bb-px-mode-lbl" style="color:rgba(0,0,0,0.6)">Inverted · dark on green chip</div><div class="bb-px-row bb-px-ink">
    <span class="bb-px-tile bb-px-tile-ink"><iconify-icon icon="pixelarticons:database" width="26"></iconify-icon></span>
    <span class="bb-px-tile bb-px-tile-ink"><iconify-icon icon="pixelarticons:terminal" width="26"></iconify-icon></span>
    <span class="bb-px-tile bb-px-tile-ink"><iconify-icon icon="pixelarticons:zap" width="26"></iconify-icon></span>
    <span class="bb-px-tile bb-px-tile-ink"><iconify-icon icon="pixelarticons:git-branch" width="26"></iconify-icon></span>
  </div></div>
</div>

<h4>Named set · Indexing concepts → Pixelarticons</h4>
<div class="bb-px-named">
  <div class="bb-px-named-cell"><span class="bb-px-tile bb-px-green-i"><iconify-icon icon="pixelarticons:search" width="24"></iconify-icon></span><span class="bb-px-name">Source</span></div>
  <div class="bb-px-named-cell"><span class="bb-px-tile bb-px-green-i"><iconify-icon icon="pixelarticons:download" width="24"></iconify-icon></span><span class="bb-px-name">Ingest</span></div>
  <div class="bb-px-named-cell"><span class="bb-px-tile bb-px-green-i"><iconify-icon icon="pixelarticons:braces" width="24"></iconify-icon></span><span class="bb-px-name">Decode</span></div>
  <div class="bb-px-named-cell"><span class="bb-px-tile bb-px-green-i"><iconify-icon icon="pixelarticons:flatten" width="24"></iconify-icon></span><span class="bb-px-name">Transform</span></div>
  <div class="bb-px-named-cell"><span class="bb-px-tile bb-px-green-i"><iconify-icon icon="pixelarticons:database" width="24"></iconify-icon></span><span class="bb-px-name">Index</span></div>
  <div class="bb-px-named-cell"><span class="bb-px-tile bb-px-green-i"><iconify-icon icon="pixelarticons:terminal" width="24"></iconify-icon></span><span class="bb-px-name">Query</span></div>
  <div class="bb-px-named-cell"><span class="bb-px-tile bb-px-green-i"><iconify-icon icon="pixelarticons:zap" width="24"></iconify-icon></span><span class="bb-px-name">Stream</span></div>
  <div class="bb-px-named-cell"><span class="bb-px-tile bb-px-green-i"><iconify-icon icon="pixelarticons:git-branch" width="24"></iconify-icon></span><span class="bb-px-name">Pipeline</span></div>
  <div class="bb-px-named-cell"><span class="bb-px-tile bb-px-green-i"><iconify-icon icon="pixelarticons:repeat" width="24"></iconify-icon></span><span class="bb-px-name">Webhook</span></div>
  <div class="bb-px-named-cell"><span class="bb-px-tile bb-px-green-i"><iconify-icon icon="pixelarticons:reload" width="24"></iconify-icon></span><span class="bb-px-name">Backfill</span></div>
  <div class="bb-px-named-cell"><span class="bb-px-tile bb-px-green-i"><iconify-icon icon="pixelarticons:analytics" width="24"></iconify-icon></span><span class="bb-px-name">Analytics</span></div>
  <div class="bb-px-named-cell"><span class="bb-px-tile bb-px-green-i"><iconify-icon icon="pixelarticons:server" width="24"></iconify-icon></span><span class="bb-px-name">Node</span></div>
  <div class="bb-px-named-cell"><span class="bb-px-tile bb-px-green-i"><iconify-icon icon="pixelarticons:list-box" width="24"></iconify-icon></span><span class="bb-px-name">Schema</span></div>
  <div class="bb-px-named-cell"><span class="bb-px-tile bb-px-green-i"><iconify-icon icon="pixelarticons:speed-fast" width="24"></iconify-icon></span><span class="bb-px-name">Latency</span></div>
  <div class="bb-px-named-cell"><span class="bb-px-tile bb-px-green-i"><iconify-icon icon="pixelarticons:book-open" width="24"></iconify-icon></span><span class="bb-px-name">Docs</span></div>
  <div class="bb-px-named-cell"><span class="bb-px-tile bb-px-green-i"><iconify-icon icon="pixelarticons:radio" width="24"></iconify-icon></span><span class="bb-px-name">Status</span></div>
</div>

<h4>Adoption</h4>
<p class="bb-desc">Brandbook shown via the Iconify web component (<code>&lt;iconify-icon icon="pixelarticons:database"&gt;</code>) · zero-build, recolor with CSS <code>color</code>. For production, inline the SVGs or vendor <code>@iconify-json/pixelarticons</code> at build time (the same way en:twine uses <code>astro-icon</code> + Lucide). Pixel icons are accent / brand moments; pair with a clean set for dense dashboard UI.</p>
<p class="bb-desc"><strong>Voice-published decks:</strong> the deck viewer sanitizes inline <code>&lt;svg&gt;</code> and web components, so neither <code>&lt;iconify-icon&gt;</code> nor inline SVG survives. Reference icons (and logos) as images via the Iconify SVG API instead: <code>&lt;img src="https://api.iconify.design/pixelarticons/database.svg?color=%2398f120"&gt;</code> for green, <code>?color=%23ffffff</code> for white. Same rule for the Dex mark and wordmark (use <code>/assets/*.svg</code> as <code>&lt;img&gt;</code>, not inline).</p>
</div>

<!-- ══════════ INFOGRAPHIC ELEMENTS ══════════ -->
<div class="bb-panel" id="tab-infogfx">
<p class="bb-desc">The modular blocks an infographic is assembled from: green-on-dark, pixel icons, Fira Code numbers. Mix and match per story.</p>

<h3>Stat callout</h3>
<div class="bb-ig-stats">
  <div class="bb-ig-stat"><iconify-icon class="bb-ig-stat-i" icon="pixelarticons:speed-fast" width="24"></iconify-icon><span class="bb-ig-num">Sub-second</span><span class="bb-ig-lbl">Block → your DB</span></div>
  <div class="bb-ig-stat bb-ig-stat-green"><iconify-icon class="bb-ig-stat-i" icon="pixelarticons:git-branch" width="24"></iconify-icon><span class="bb-ig-num">100+</span><span class="bb-ig-lbl">Chains, one pipeline</span></div>
  <div class="bb-ig-stat"><iconify-icon class="bb-ig-stat-i" icon="pixelarticons:database" width="24"></iconify-icon><span class="bb-ig-num">1.6 TB</span><span class="bb-ig-lbl">Processed daily</span></div>
  <div class="bb-ig-stat"><iconify-icon class="bb-ig-stat-i" icon="pixelarticons:flatten" width="24"></iconify-icon><span class="bb-ig-num">Zero</span><span class="bb-ig-lbl">Extra API layers</span></div>
</div>

<h3>Pipeline (icon story)</h3>
<div class="bb-ig-pipe">
  <div class="bb-ig-node"><span class="bb-px-tile bb-px-green-i"><iconify-icon icon="pixelarticons:search" width="24"></iconify-icon></span><span class="bb-ig-node-lbl">Source</span></div>
  <iconify-icon class="bb-ig-arrow" icon="pixelarticons:chevron-right" width="20"></iconify-icon>
  <div class="bb-ig-node"><span class="bb-px-tile bb-px-green-i"><iconify-icon icon="pixelarticons:download" width="24"></iconify-icon></span><span class="bb-ig-node-lbl">Ingest</span></div>
  <iconify-icon class="bb-ig-arrow" icon="pixelarticons:chevron-right" width="20"></iconify-icon>
  <div class="bb-ig-node"><span class="bb-px-tile bb-px-green-i"><iconify-icon icon="pixelarticons:braces" width="24"></iconify-icon></span><span class="bb-ig-node-lbl">Decode</span></div>
  <iconify-icon class="bb-ig-arrow" icon="pixelarticons:chevron-right" width="20"></iconify-icon>
  <div class="bb-ig-node"><span class="bb-px-tile bb-px-green-i"><iconify-icon icon="pixelarticons:database" width="24"></iconify-icon></span><span class="bb-ig-node-lbl">Index</span></div>
  <iconify-icon class="bb-ig-arrow" icon="pixelarticons:chevron-right" width="20"></iconify-icon>
  <div class="bb-ig-node"><span class="bb-px-tile bb-px-green-i"><iconify-icon icon="pixelarticons:zap" width="24"></iconify-icon></span><span class="bb-ig-node-lbl">Stream</span></div>
</div>

<h3>Comparison</h3>
<div class="bb-ig-cmp">
  <div class="bb-ig-cmp-col"><div class="bb-ig-cmp-h bb-muted"><iconify-icon icon="pixelarticons:minus" width="16"></iconify-icon> Subgraphs + polling</div><ul class="bb-muted-list"><li>One subgraph per chain</li><li>Polling intervals + middleware hops</li><li>Indexer ops on you</li></ul></div>
  <div class="bb-ig-cmp-col bb-ig-cmp-win"><div class="bb-ig-cmp-h bb-green"><iconify-icon icon="pixelarticons:check-double" width="16"></iconify-icon> Indexing Co</div><ul><li>One pipeline, 100+ chains</li><li>Direct to your DB, sub-second</li><li>No infra to run</li></ul></div>
</div>
</div>

<!-- ══════════ INFOGRAPHIC (single image) ══════════ -->
<div class="bb-panel" id="tab-infographic">
<p class="bb-desc">The blocks composed into one self-contained, exportable graphic. Steps connect with pixel <code>&gt;</code> chevrons. Two formats: vertical (poster / LinkedIn) and horizontal (slide / thumbnail). Screenshot the figure to export.</p>

<h3>Vertical</h3>
<figure id="ico-infographic" class="bb-poster">
  <div class="bb-poster-top"></div>
  <div class="bb-poster-head">
    <div class="bb-poster-kicker"><span class="bb-green-square" style="width:12px;height:12px"></span> ONCHAIN DATA PIPELINE</div>
    <h2>From any chain to your database. Sub-second.</h2>
    <p>Read, decode, transform and deliver onchain data straight into your own schema. One pipeline, 100+ chains, no middleware.</p>
  </div>
  <ol class="bb-poster-flow">
    <li class="bb-poster-row"><div class="bb-poster-iconcol"><span class="bb-px-tile bb-px-green-i bb-poster-icon"><iconify-icon icon="pixelarticons:search" width="26"></iconify-icon></span><iconify-icon class="bb-poster-chev" icon="pixelarticons:chevron-down" width="18"></iconify-icon></div><div class="bb-poster-txt"><span class="bb-poster-n">01</span><h4>Source</h4><p>Scan 100+ chains in real time for the contracts and events you care about.</p></div><span class="bb-poster-metric">100+ chains</span></li>
    <li class="bb-poster-row"><div class="bb-poster-iconcol"><span class="bb-px-tile bb-px-green-i bb-poster-icon"><iconify-icon icon="pixelarticons:download" width="26"></iconify-icon></span><iconify-icon class="bb-poster-chev" icon="pixelarticons:chevron-down" width="18"></iconify-icon></div><div class="bb-poster-txt"><span class="bb-poster-n">02</span><h4>Ingest</h4><p>Capture blocks as they finalize, no polling intervals, no middleware hops.</p></div><span class="bb-poster-metric">sub-second</span></li>
    <li class="bb-poster-row"><div class="bb-poster-iconcol"><span class="bb-px-tile bb-px-green-i bb-poster-icon"><iconify-icon icon="pixelarticons:braces" width="26"></iconify-icon></span><iconify-icon class="bb-poster-chev" icon="pixelarticons:chevron-down" width="18"></iconify-icon></div><div class="bb-poster-txt"><span class="bb-poster-n">03</span><h4>Decode</h4><p>Logs and ABIs decoded into clean, typed, query-ready records.</p></div><span class="bb-poster-metric">typed</span></li>
    <li class="bb-poster-row"><div class="bb-poster-iconcol"><span class="bb-px-tile bb-px-green-i bb-poster-icon"><iconify-icon icon="pixelarticons:flatten" width="26"></iconify-icon></span><iconify-icon class="bb-poster-chev" icon="pixelarticons:chevron-down" width="18"></iconify-icon></div><div class="bb-poster-txt"><span class="bb-poster-n">04</span><h4>Transform</h4><p>Add your business logic. Infrastructure handles the rest.</p></div><span class="bb-poster-metric">your logic</span></li>
    <li class="bb-poster-row"><div class="bb-poster-iconcol"><span class="bb-px-tile bb-px-green-i bb-poster-icon"><iconify-icon icon="pixelarticons:database" width="26"></iconify-icon></span><iconify-icon class="bb-poster-chev" icon="pixelarticons:chevron-down" width="18"></iconify-icon></div><div class="bb-poster-txt"><span class="bb-poster-n">05</span><h4>Index</h4><p>Data lands in your own database, your own schema. Query with plain SQL.</p></div><span class="bb-poster-metric">your schema</span></li>
    <li class="bb-poster-row"><div class="bb-poster-iconcol"><span class="bb-px-tile bb-px-green-i bb-poster-icon"><iconify-icon icon="pixelarticons:zap" width="26"></iconify-icon></span></div><div class="bb-poster-txt"><span class="bb-poster-n">06</span><h4>Deliver</h4><p>Direct database writes plus webhooks, just-in-time, no middlemen.</p></div><span class="bb-poster-metric">real-time</span></li>
  </ol>
  <div class="bb-poster-foot">
    <div class="bb-poster-stats">
      <div><span class="bb-poster-stat">100+</span><span class="bb-poster-stat-l">Chains</span></div>
      <div><span class="bb-poster-stat">1.6 TB</span><span class="bb-poster-stat-l">Daily</span></div>
      <div><span class="bb-poster-stat">Zero</span><span class="bb-poster-stat-l">API layers</span></div>
    </div>
    <div class="bb-poster-mark"><img src="/assets/wordmark-new.svg" alt="Indexing Co" style="height:13px;filter:invert(1)"/></div>
  </div>
</figure>

<h3 style="margin-top:32px">Horizontal</h3>
<figure id="ico-infographic-h" class="bb-poster bb-poster-wide">
  <div class="bb-poster-top"></div>
  <div class="bb-poster-head">
    <div class="bb-poster-kicker"><span class="bb-green-square" style="width:12px;height:12px"></span> ONCHAIN DATA PIPELINE</div>
    <h2>From any chain to your database. Sub-second.</h2>
  </div>
  <div class="bb-poster-hflow">
    <div class="bb-hstep"><span class="bb-px-tile bb-px-green-i"><iconify-icon icon="pixelarticons:search" width="24"></iconify-icon></span><span class="bb-poster-n">01</span><h4>Source</h4><p>Scan 100+ chains in real time.</p></div>
    <iconify-icon class="bb-hchev" icon="pixelarticons:chevron-right" width="20"></iconify-icon>
    <div class="bb-hstep"><span class="bb-px-tile bb-px-green-i"><iconify-icon icon="pixelarticons:download" width="24"></iconify-icon></span><span class="bb-poster-n">02</span><h4>Ingest</h4><p>Capture blocks as they finalize.</p></div>
    <iconify-icon class="bb-hchev" icon="pixelarticons:chevron-right" width="20"></iconify-icon>
    <div class="bb-hstep"><span class="bb-px-tile bb-px-green-i"><iconify-icon icon="pixelarticons:braces" width="24"></iconify-icon></span><span class="bb-poster-n">03</span><h4>Decode</h4><p>Logs + ABIs into typed records.</p></div>
    <iconify-icon class="bb-hchev" icon="pixelarticons:chevron-right" width="20"></iconify-icon>
    <div class="bb-hstep"><span class="bb-px-tile bb-px-green-i"><iconify-icon icon="pixelarticons:flatten" width="24"></iconify-icon></span><span class="bb-poster-n">04</span><h4>Transform</h4><p>Add your business logic.</p></div>
    <iconify-icon class="bb-hchev" icon="pixelarticons:chevron-right" width="20"></iconify-icon>
    <div class="bb-hstep"><span class="bb-px-tile bb-px-green-i"><iconify-icon icon="pixelarticons:database" width="24"></iconify-icon></span><span class="bb-poster-n">05</span><h4>Index</h4><p>Lands in your own schema.</p></div>
    <iconify-icon class="bb-hchev" icon="pixelarticons:chevron-right" width="20"></iconify-icon>
    <div class="bb-hstep"><span class="bb-px-tile bb-px-green-i"><iconify-icon icon="pixelarticons:zap" width="24"></iconify-icon></span><span class="bb-poster-n">06</span><h4>Deliver</h4><p>Direct writes plus webhooks.</p></div>
  </div>
  <div class="bb-poster-foot">
    <div class="bb-poster-stats">
      <div><span class="bb-poster-stat">100+</span><span class="bb-poster-stat-l">Chains</span></div>
      <div><span class="bb-poster-stat">1.6 TB</span><span class="bb-poster-stat-l">Daily</span></div>
      <div><span class="bb-poster-stat">Zero</span><span class="bb-poster-stat-l">API layers</span></div>
    </div>
    <div class="bb-poster-mark"><img src="/assets/wordmark-new.svg" alt="Indexing Co" style="height:13px;filter:invert(1)"/></div>
  </div>
</figure>
</div>

</div><!-- .bb-content -->
</div><!-- .bb-layout -->
</div><!-- .bb -->

<script>
(function(){
  var btns = document.querySelectorAll('.bb-tab-btn');
  var panels = document.querySelectorAll('.bb-panel');
  var toggle = document.querySelector('.bb-nav-toggle');
  var toggleLabel = document.querySelector('.bb-nav-toggle-label');
  var navItems = document.querySelector('.bb-nav-items');

  if (toggle && navItems) {
    toggle.addEventListener('click', function() {
      var expanded = this.getAttribute('aria-expanded') === 'true';
      this.setAttribute('aria-expanded', !expanded);
      navItems.classList.toggle('open');
    });
  }

  btns.forEach(function(btn){
    btn.addEventListener('click', function(){
      btns.forEach(function(b){ b.classList.remove('active'); });
      panels.forEach(function(p){ p.classList.remove('active'); });
      btn.classList.add('active');
      var t = btn.getAttribute('data-tab');
      document.getElementById('tab-' + t).classList.add('active');
      if (toggleLabel) toggleLabel.textContent = btn.textContent;
      if (navItems) {
        navItems.classList.remove('open');
        if (toggle) toggle.setAttribute('aria-expanded', 'false');
      }
    });
  });
})();
</script>

<style>
/* ═══════ PAGE OVERRIDE ═══════ */
#page-assets-brandbook #content { width:100%; max-width:100%; gap:0; }
#page-assets-brandbook { padding:0; padding-top:64px; }
#page-assets-brandbook #content > h1:first-of-type,
#page-assets-brandbook #content > h2:first-of-type,
#page-assets-brandbook #content > p:first-of-type,
#page-assets-brandbook #content > hr { display:none; }
#page-assets-brandbook footer { display:none; }

/* ═══════ BASE ═══════ */
.bb { background:#000; color:#fff; font-family:'Inter',system-ui,sans-serif; border-radius:0; overflow:hidden; width:100vw; position:relative; left:50%; right:50%; margin-left:-50vw; margin-right:-50vw; min-height:calc(100vh - 64px); }
.bb *, .bb *::before, .bb *::after { box-sizing:border-box; }
.bb h3 { font-size:18px; font-weight:500; margin:0 0 16px; color:#fff; }
.bb h4 { font-size:14px; font-weight:600; margin:0 0 4px; color:#fff; }
.bb h5 { font-size:18px; font-weight:500; margin:0; color:#fff; }
.bb p { color:rgba(255,255,255,0.6); font-size:14px; line-height:1.6; margin:0 0 8px; }
.bb strong { color:#fff; }
.bb a { color:#4AF120; text-decoration:none; }
.bb code { font-family:'Fira Code',monospace; font-size:12px; }
.bb ul { margin:0; padding:0; list-style:none; }
.bb ul li { font-size:14px; padding:5px 0; color:#fff; }

/* Header */
.bb-header { padding:16px 32px; border-bottom:1px solid rgba(255,255,255,0.1); max-width:1300px; margin:0 auto; }
.bb-header-title { display:flex; align-items:center; gap:12px; }
.bb-header-title h2 { font-size:20px; font-weight:600; margin:0; }
.bb-header p { margin-top:6px; }
.bb-green-square { width:20px; height:20px; background:#4AF120; border-radius:4px; flex-shrink:0; }

/* Layout: sidebar + content */
.bb-layout { display:flex; height:calc(100vh - 140px); min-height:500px; max-width:1300px; margin:0 auto; }
.bb-sidebar { width:200px; flex-shrink:0; border-right:1px solid rgba(255,255,255,0.1); background:#050505; padding:12px; overflow-y:auto; display:flex; flex-direction:column; gap:2px; }
.bb-nav-toggle { display:none; }
.bb-nav-items { display:contents; }
.bb-tab-btn { display:block; width:100%; text-align:left; background:none; border:none; color:rgba(255,255,255,0.6); font-size:13px; font-weight:500; padding:8px 12px; border-radius:6px; cursor:pointer; font-family:inherit; transition:all 0.15s; }
.bb-tab-btn:hover { color:rgba(255,255,255,0.8); background:rgba(255,255,255,0.05); }
.bb-tab-btn.active { color:#fff; background:rgba(255,255,255,0.1); }
.bb-sidebar-version { margin-top:auto; padding:12px; font-family:'Fira Code',monospace; font-size:10px; letter-spacing:1px; text-transform:uppercase; color:rgba(255,255,255,0.2); border-top:1px solid rgba(255,255,255,0.05); }
.bb-content { flex:1; overflow-y:auto; padding:32px 40px; }
.bb-panel { display:none; max-width:900px; margin:0 auto; }
.bb-panel.active { display:block; }

/* Descriptions */
.bb-desc { color:rgba(255,255,255,0.6); font-size:14px; margin-bottom:24px; max-width:600px; }
.bb-intro { font-size:16px; line-height:1.7; color:rgba(255,255,255,0.85); max-width:600px; margin-bottom:28px; }
.bb-muted { color:rgba(255,255,255,0.6) !important; }
.bb-green { color:#4AF120 !important; }
.bb-red { color:#ef4444 !important; }

/* Logo */
.bb-logo-grid { display:flex; gap:16px; margin-bottom:32px; flex-wrap:wrap; justify-content:flex-start; }
.bb-logo-card { display:flex; flex-direction:column; align-items:center; justify-content:center; gap:8px; padding:28px; border-radius:8px; border:1px solid rgba(255,255,255,0.1); flex:1; min-width:160px; max-width:280px; min-height:140px; }
.bb-logo-card img { max-height:80px; max-width:100%; }
.bb-logo-sm { max-width:160px; min-width:130px; padding:24px 16px; flex:0 0 auto; }
.bb-bg-white { background:#fff; }
.bb-bg-black { background:#000; }
.bb-bg-dark { background:#1c1c1e; }
.bb-wrap { flex-wrap:wrap; }
.bb-label { font-size:11px; color:rgba(255,255,255,0.6); }
.bb-dl { font-size:10px; font-family:'Fira Code',monospace; color:rgba(255,255,255,0.5); border:1px solid rgba(255,255,255,0.1); padding:2px 8px; border-radius:4px; text-decoration:none; }
.bb-dl:hover { color:#4AF120; border-color:rgba(74,241,32,0.3); }

/* Rules */
.bb-rules-grid { display:grid; grid-template-columns:1fr 1fr; gap:16px; margin:16px 0 28px; }
.bb-rule-card { border-radius:12px; border:1px solid rgba(255,255,255,0.1); background:#0a0a0a; padding:20px; }
.bb-rule-header { display:flex; align-items:center; gap:8px; font-size:13px; font-weight:600; margin-bottom:12px; }
.bb-muted-list li { color:rgba(255,255,255,0.5); }

/* Swatches */
.bb-swatch-grid { display:grid; grid-template-columns:repeat(auto-fill, minmax(140px,1fr)); gap:12px; margin-bottom:16px; }
.bb-swatch { border-radius:8px; overflow:hidden; border:1px solid rgba(255,255,255,0.1); }
.bb-swatch-color { height:72px; }
.bb-swatch-border { border:1px solid rgba(255,255,255,0.1); }
.bb-swatch-meta { background:rgba(255,255,255,0.03); padding:10px; }
.bb-swatch-meta span { display:block; font-size:13px; font-weight:500; color:#fff; }
.bb-swatch-meta code { display:block; margin-top:2px; color:rgba(255,255,255,0.5); }

/* Callout */
.bb-callout { border-radius:0 8px 8px 0; padding:16px 20px; margin:20px 0; max-width:600px; }
.bb-callout-red { border-left:3px solid #ef4444; background:rgba(239,68,68,0.08); }
.bb-callout ul { margin-top:8px; }
.bb-callout li { color:rgba(255,255,255,0.6); font-size:13px; }

/* Tables */
.bb-table { width:100%; border-collapse:collapse; font-size:13px; margin:12px 0 24px; }
.bb-table th { text-align:left; padding:8px 12px 8px 0; font-weight:500; color:rgba(255,255,255,0.6); border-bottom:2px solid rgba(255,255,255,0.1); }
.bb-table td { padding:7px 12px 7px 0; border-bottom:1px solid rgba(255,255,255,0.05); color:#fff; }

/* Type samples */
.bb-type-samples { display:flex; flex-direction:column; gap:8px; margin:20px 0 28px; }
.bb-type-sample { background:rgba(255,255,255,0.04); border-radius:8px; padding:20px 24px; overflow:hidden; }
.bb-type-label { display:block; font-size:11px; font-weight:500; color:rgba(255,255,255,0.5); margin-bottom:6px; }

/* Principles */
.bb-principles-grid { display:grid; grid-template-columns:1fr 1fr; gap:20px; margin:16px 0 28px; }
.bb-principle { padding-left:14px; border-left:2px solid rgba(255,255,255,0.1); transition:border-color 0.3s; }
.bb-principle:hover { border-left-color:#4AF120; }
.bb-principle h4 { font-size:13px; }
.bb-principle p { font-size:13px; color:rgba(255,255,255,0.6); margin:0; }

/* Mono lists / vocab */
.bb-mono-list { font-family:'Fira Code',monospace; }
.bb-mono-list li { font-size:13px; }
.bb-strike li { text-decoration:line-through; color:rgba(255,255,255,0.4); text-decoration-color:rgba(255,255,255,0.15); }
.bb-divider { border-top:1px solid rgba(255,255,255,0.1); margin:10px 0; }
.bb-phrase { font-family:Inter,sans-serif; font-size:15px; font-weight:500; color:#fff; margin:4px 0; }

/* Platform cards */
.bb-platform-card { background:rgba(255,255,255,0.04); border-radius:8px; padding:16px; }
.bb-platform-card dl { margin:0; }
.bb-platform-card dt { font-size:13px; font-weight:500; color:#fff; margin-top:8px; }
.bb-platform-card dd { font-size:13px; color:rgba(255,255,255,0.6); margin:0; }

/* Preview container */
.bb-preview { background:rgba(255,255,255,0.02); border:1px solid rgba(255,255,255,0.05); border-radius:10px; padding:24px; margin-bottom:20px; display:flex; flex-wrap:wrap; align-items:center; gap:12px; }

/* Buttons */
.bb-btn { display:inline-flex; align-items:center; justify-content:center; border-radius:100px; font-weight:500; border:none; cursor:pointer; transition:opacity 0.2s; font-family:inherit; }
.bb-btn:hover { opacity:0.8; }
.bb-btn-lg { background:#fff; color:#000; padding:16px 32px; font-size:16px; }
.bb-btn-md { background:#fff; color:#000; padding:12px 20px; font-size:16px; }
.bb-btn-sm { background:#fff; color:#000; padding:8px 16px; font-size:14px; }
.bb-btn-out { background:transparent; color:#fff; padding:12px 20px; font-size:16px; border:1px solid #fff; }
.bb-btn-cta { background:#4AF120; color:#000; padding:8px 16px; font-size:13px; border-radius:100px; border:none; font-weight:500; cursor:pointer; font-family:inherit; }
.bb-btn-out-w { background:transparent; color:#fff; padding:10px 20px; font-size:14px; border-radius:100px; border:1px solid rgba(255,255,255,0.2); font-weight:500; cursor:pointer; font-family:inherit; }

/* Demo cards */
.bb-demo-cards { display:grid; grid-template-columns:1fr 1fr; gap:16px; width:100%; }
.bb-pricing-card { border:1px solid rgba(255,255,255,0.1); background:#000; border-radius:8px; padding:20px; }
.bb-pricing-card p { font-size:13px; color:rgba(255,255,255,0.6); }
.bb-price { font-size:28px; font-weight:300; color:#fff; margin:12px 0; }
.bb-price span { font-size:13px; color:rgba(255,255,255,0.5); }
.bb-pricing-card ul li { display:flex; align-items:center; gap:8px; font-size:13px; color:rgba(255,255,255,0.6); padding:3px 0; }
.bb-check { color:#4AF120; font-weight:600; }
.bb-addon-card { background:rgba(255,255,255,0.05); border-radius:8px; padding:20px; }
.bb-addon-card p { font-size:13px; }

/* Spacing */
.bb-spacing-row { display:flex; align-items:flex-end; gap:10px; }
.bb-sp { border:1px solid rgba(255,255,255,0.1); background:rgba(255,255,255,0.05); border-radius:3px; display:flex; align-items:center; justify-content:center; font-size:10px; font-weight:500; color:rgba(255,255,255,0.6); }

/* List cards */
.bb-list-grid { display:grid; grid-template-columns:repeat(auto-fit, minmax(200px, 1fr)); gap:12px; margin-bottom:24px; }
.bb-list-card { background:rgba(255,255,255,0.03); border:1px solid rgba(255,255,255,0.1); border-radius:12px; padding:20px; }
.bb-list-header { display:flex; align-items:center; gap:8px; font-size:13px; font-weight:600; margin-bottom:12px; color:#fff; }
.bb-info-list li { color:rgba(255,255,255,0.6); font-size:13px; }

/* Code cards */
.bb-code-card { position:relative; overflow:hidden; border-radius:12px; border:1px solid rgba(255,255,255,0.1); margin-bottom:0; }
.bb-code-accent { position:absolute; top:0; left:0; right:0; height:2px; background:rgba(255,255,255,0.1); transition:background 0.4s; }
.bb-code-card:hover .bb-code-accent { background:#4AF120; }
.bb-code-split { display:flex; gap:20px; padding:20px; }
.bb-code-meta { width:35%; min-width:140px; }
.bb-code-meta h4 { font-size:14px; margin-bottom:4px; }
.bb-code-meta p { font-size:13px; }
.bb-tag { display:inline-block; margin-top:8px; font-size:11px; color:rgba(255,255,255,0.6); background:rgba(255,255,255,0.05); border:1px solid rgba(255,255,255,0.1); border-radius:4px; padding:2px 8px; }
.bb-code-preview { flex:1; position:relative; background:rgba(255,255,255,0.03); border:1px solid rgba(255,255,255,0.1); border-radius:8px; padding:16px; font-family:'Fira Code',monospace; font-size:13px; }
.bb-dots { position:absolute; top:10px; right:10px; display:flex; gap:4px; }
.bb-dots span { width:6px; height:6px; border-radius:50%; background:rgba(255,255,255,0.1); }
.bb-bold { font-weight:500; color:#fff; margin-bottom:10px; }
.bb-code-preview .bb-muted { color:rgba(255,255,255,0.6); margin-bottom:10px; }
.bb-code-preview .bb-green { color:#4AF120; margin:0; }
.bb-mini-stats { background:#000; border:1px solid rgba(255,255,255,0.1); border-radius:4px; padding:8px; margin-top:10px; font-size:12px; }
.bb-mini-stats div { padding:2px 0; color:#fff; }

/* Toggles */
.bb-toggle-row { display:flex; gap:24px; width:100%; }
.bb-toggle-ex { background:rgba(255,255,255,0.03); border:1px solid rgba(255,255,255,0.1); border-radius:12px; padding:24px; flex:1; }
.bb-toggle-label { font-size:10px; font-weight:500; letter-spacing:1.5px; color:rgba(255,255,255,0.5); margin-bottom:12px; }
.bb-toggle { display:inline-flex; align-items:center; background:rgba(255,255,255,0.1); border-radius:100px; padding:5px; }
.bb-tog-green { background:#4AF120; color:#000; font-size:13px; font-weight:600; padding:8px 18px; border-radius:100px; border:none; cursor:pointer; font-family:inherit; }
.bb-tog-white { background:#fff; color:#000; font-size:13px; font-weight:600; padding:8px 18px; border-radius:100px; border:none; cursor:pointer; font-family:inherit; }
.bb-tog-off { background:none; border:none; color:rgba(255,255,255,0.6); font-size:13px; padding:8px 18px; cursor:pointer; font-family:inherit; }
.bb-tog-off span { font-size:11px; opacity:0.7; }

/* Navigation demo */
.bb-nav-demo { position:relative; height:340px; overflow:hidden; border-radius:12px; border:1px solid rgba(255,255,255,0.1); background:#000; margin-bottom:24px; }
.bb-nav-glow { position:absolute; top:-20%; right:-10%; width:60%; height:80%; border-radius:50%; background:#4AF120; opacity:0.05; filter:blur(100px); }
.bb-nav-bar { position:absolute; top:0; left:0; right:0; height:56px; display:flex; align-items:center; justify-content:space-between; padding:0 24px; border-bottom:1px solid rgba(255,255,255,0.1); background:rgba(0,0,0,0.6); backdrop-filter:blur(24px); z-index:10; }
.bb-nav-logo { display:flex; align-items:center; gap:8px; font-size:13px; color:#fff; }
.bb-nav-links { display:flex; gap:24px; font-size:13px; font-weight:500; color:rgba(255,255,255,0.5); }
.bb-nav-links .active { color:#fff; }
.bb-nav-right { display:flex; align-items:center; gap:16px; font-size:13px; color:#fff; }
.bb-dropdown { position:absolute; top:64px; left:50%; transform:translateX(-50%); width:260px; background:#111; border:1px solid rgba(255,255,255,0.1); border-radius:12px; padding:8px; box-shadow:0 16px 40px rgba(0,0,0,0.5); z-index:20; }
.bb-dd-item { display:flex; align-items:flex-start; gap:12px; padding:10px; border-radius:8px; }
.bb-dd-item:hover { background:rgba(255,255,255,0.05); }
.bb-dd-icon { width:28px; height:28px; border-radius:6px; border:1px solid rgba(255,255,255,0.05); background:rgba(255,255,255,0.05); flex-shrink:0; position:relative; }
.bb-dd-icon::after { content:''; position:absolute; inset:6px; background:rgba(74,241,32,0.6); border-radius:3px; }
.bb-dd-item strong { display:block; font-size:13px; color:#fff; font-weight:500; }
.bb-dd-item span { font-size:11px; color:rgba(255,255,255,0.5); }
.bb-dd-footer { display:flex; align-items:center; justify-content:space-between; padding:8px 10px; border-top:1px solid rgba(255,255,255,0.05); margin-top:4px; font-size:11px; }
.bb-dd-footer span { color:rgba(255,255,255,0.5); }
.bb-dd-footer code { background:rgba(255,255,255,0.1); padding:2px 6px; border-radius:4px; color:#fff; }
.bb-nav-annot { position:absolute; bottom:12px; left:12px; display:flex; flex-direction:column; gap:6px; z-index:10; }
.bb-annot { display:flex; align-items:center; gap:6px; font-family:'Fira Code',monospace; font-size:11px; color:#fff; background:rgba(0,0,0,0.8); border:1px solid rgba(255,255,255,0.1); padding:4px 10px; border-radius:4px; }
.bb-annot-dot { width:7px; height:7px; border-radius:50%; background:#4AF120; }
.pulse { animation:pulse 2s infinite; }
@keyframes pulse { 0%,100%{opacity:1} 50%{opacity:0.3} }

/* Competitive card */
.bb-comp-card { background:#0A0A0A; border:1px solid #1A1A1A; border-radius:6px; padding:32px; display:flex; flex-direction:column; gap:24px; margin-bottom:24px; transition:border-color 0.3s; }
.bb-comp-card:hover { border-color:#8E8E93; }
.bb-comp-card:hover .bb-comp-right { border-left-color:#4AF120; }
.bb-comp-header { display:flex; align-items:center; justify-content:space-between; }
.bb-comp-muted { font-size:16px; font-weight:600; color:#C7C7CC; }
.bb-comp-vs { font-family:'Fira Code',monospace; font-size:12px; color:#1A1A1A; }
.bb-comp-green { font-size:16px; font-weight:600; color:#4AF120; }
.bb-comp-tags { display:flex; gap:8px; }
.bb-comp-tags span { font-family:'Fira Code',monospace; font-size:12px; color:#D1D1D6; background:#000; border:1px solid #1A1A1A; border-radius:100px; padding:4px 12px; }
.bb-comp-split { display:grid; grid-template-columns:1fr 1fr; gap:24px; }
.bb-comp-left { padding-left:12px; border-left:2px solid #1A1A1A; }
.bb-comp-left strong { font-size:14px; color:#D1D1D6; }
.bb-comp-left p { font-size:13px; color:#8E8E93; margin-top:6px; }
.bb-comp-right { padding-left:12px; border-left:2px solid rgba(142,142,147,0.2); transition:border-color 0.5s; }
.bb-comp-right strong { font-size:14px; color:#fff; }
.bb-comp-right p { font-size:13px; color:#8E8E93; margin-top:6px; }
.bb-comp-cta { font-size:12px; font-weight:500; color:#4AF120; }

/* Stat cards */
.bb-stat-grid { display:grid; grid-template-columns:repeat(auto-fit, minmax(220px, 1fr)); gap:24px; margin-bottom:24px; }
.bb-stat-card { position:relative; background:#000; border:1px solid #1A1A1A; border-radius:6px; padding:32px; overflow:hidden; }
.bb-stat-bar { position:absolute; left:0; top:0; bottom:0; width:2px; background:#1A1A1A; transition:background 0.3s; }
.bb-stat-card:hover .bb-stat-bar { background:#fff; }
.bb-stat-num { display:block; font-family:'Fira Code',monospace; font-size:26px; color:#fff; letter-spacing:-0.04em; margin-bottom:10px; }
.bb-stat-card strong { display:block; font-size:15px; margin-bottom:6px; }
.bb-stat-card p { font-size:13px; color:#8E8E93; margin-bottom:12px; }
.bb-stat-tag { font-family:'Fira Code',monospace; font-size:11px; color:#D1D1D6; background:#0A0A0A; border:1px solid #1A1A1A; border-radius:4px; padding:3px 8px; }

/* Website preview */
.bb-website { overflow:hidden; border-radius:12px; border:1px solid rgba(255,255,255,0.1); background:#000; }
.bb-wp-nav { display:flex; align-items:center; justify-content:space-between; height:56px; padding:0 24px; border-bottom:1px solid rgba(255,255,255,0.1); background:rgba(0,0,0,0.6); backdrop-filter:blur(24px); }
.bb-wp-links { display:flex; gap:24px; font-size:13px; color:rgba(255,255,255,0.5); }
.bb-wp-right { display:flex; align-items:center; gap:16px; font-size:13px; color:rgba(255,255,255,0.7); }
.bb-wp-hero { position:relative; padding:64px 48px 56px; overflow:hidden; }
.bb-wp-glow { position:absolute; top:10%; right:-15%; width:50%; height:70%; border-radius:50%; background:#4AF120; opacity:0.04; filter:blur(100px); pointer-events:none; }
.bb-wp-hero h1 { font-size:36px; font-weight:500; line-height:1.15; letter-spacing:-0.03em; margin:0 0 16px; position:relative; z-index:1; }
.bb-wp-hero h1 span { color:rgba(255,255,255,0.5); }
.bb-wp-hero p { font-size:16px; color:rgba(255,255,255,0.5); max-width:480px; margin-bottom:24px; position:relative; z-index:1; }
.bb-wp-hero em { font-style:normal; color:#fff; }
.bb-wp-btns { display:flex; gap:12px; }
.bb-wp-logos { border-top:1px solid rgba(255,255,255,0.05); padding:28px 48px; }
.bb-wp-logos > p { font-size:10px; letter-spacing:2px; font-weight:500; color:rgba(255,255,255,0.3); margin-bottom:16px; }
.bb-wp-logo-row { display:flex; gap:24px; flex-wrap:wrap; }
.bb-wp-logo-row span { background:rgba(255,255,255,0.05); padding:6px 12px; border-radius:4px; font-size:11px; color:rgba(255,255,255,0.3); }
.bb-wp-props { border-top:1px solid rgba(255,255,255,0.05); padding:48px; display:grid; grid-template-columns:repeat(3,1fr); gap:32px; }
.bb-wp-prop { padding-left:14px; border-left:2px solid rgba(255,255,255,0.1); transition:border-color 0.3s; }
.bb-wp-prop:hover { border-left-color:#4AF120; }
.bb-wp-prop h3 { font-size:15px; margin-bottom:6px; }
.bb-wp-prop p { font-size:13px; color:rgba(255,255,255,0.5); margin:0; }
.bb-wp-stats { border-top:1px solid rgba(255,255,255,0.05); padding:48px; display:grid; grid-template-columns:repeat(3,1fr); gap:24px; }
.bb-wp-stats > div { border:1px solid rgba(255,255,255,0.05); background:rgba(255,255,255,0.02); border-radius:10px; padding:20px; }
.bb-wp-stats p { font-size:13px; color:rgba(255,255,255,0.6); margin:0 0 4px; }
.bb-wp-stats span { font-size:32px; font-weight:300; letter-spacing:-1px; }
.bb-wp-cta { border-top:1px solid rgba(255,255,255,0.05); padding:56px 48px; text-align:center; }
.bb-wp-cta h2 { font-size:36px; font-weight:300; letter-spacing:-0.03em; margin:0 0 20px; color:#fff; }
.bb-wp-cta .bb-wp-btns { justify-content:center; }
.bb-wp-footer { border-top:1px solid rgba(255,255,255,0.1); padding:32px 48px; }
.bb-wp-fcols { display:grid; grid-template-columns:repeat(4,1fr); gap:24px; margin-bottom:24px; }
.bb-wp-fcols > div > p { font-size:10px; font-weight:600; letter-spacing:2px; color:rgba(255,255,255,0.6); margin:0 0 10px; text-transform:uppercase; }
.bb-wp-fcols > div > span { display:block; font-size:13px; color:rgba(255,255,255,0.3); padding:3px 0; }
.bb-wp-fbot { border-top:1px solid rgba(255,255,255,0.05); padding-top:16px; font-size:12px; color:rgba(255,255,255,0.3); }

/* Responsive */
@media (max-width:900px) {
  .bb-layout { flex-direction:column; height:auto; }
  .bb-sidebar { width:100%; flex-direction:column; flex-wrap:nowrap; border-right:none; border-bottom:1px solid rgba(255,255,255,0.1); padding:12px; gap:0; }
  .bb-sidebar-version { display:none; }
  .bb-nav-toggle { display:flex; align-items:center; justify-content:space-between; width:100%; padding:10px 14px; background:rgba(255,255,255,0.08); border:1px solid rgba(255,255,255,0.15); border-radius:8px; color:#fff; font-size:14px; font-weight:500; font-family:inherit; cursor:pointer; transition:border-color 0.15s; }
  .bb-nav-toggle:hover { border-color:#4AF120; }
  .bb-nav-toggle[aria-expanded="true"] .bb-nav-toggle-icon { transform:rotate(180deg); }
  .bb-nav-toggle-icon { transition:transform 0.2s; opacity:0.5; }
  .bb-nav-items { display:none; flex-direction:column; background:rgba(255,255,255,0.05); border:1px solid rgba(255,255,255,0.12); border-top:none; border-radius:0 0 8px 8px; margin-top:-4px; padding:4px 0; overflow:hidden; }
  .bb-nav-items.open { display:flex; }
  .bb-tab-btn { border-radius:0; padding:10px 14px; }
  .bb-tab-btn:hover { background:rgba(255,255,255,0.08); }
  .bb-tab-btn.active { background:rgba(255,255,255,0.1); color:#4AF120; }
  .bb-content { padding:24px 20px; }
  .bb-rules-grid, .bb-principles-grid, .bb-list-grid, .bb-toggle-row, .bb-demo-cards, .bb-comp-split, .bb-stat-grid { grid-template-columns:1fr; }
  .bb-code-split { flex-direction:column; }
  .bb-code-meta { width:100%; }
  .bb-wp-props, .bb-wp-stats { grid-template-columns:1fr; }
  .bb-wp-fcols { grid-template-columns:1fr 1fr; }
}
@media (max-width:768px) {
  .bb-principles-grid { grid-template-columns:1fr; }
  .bb-toggle-row { flex-direction:column; }
  .bb-demo-cards { grid-template-columns:1fr; }
  .bb-comp-split { grid-template-columns:1fr; }
  .bb-wp-props, .bb-wp-stats { grid-template-columns:1fr; }
}
/* ═══════ PIXEL ICONS (Pixelarticons) ═══════ */
.bb-bg-green { background:#4AF120; }
.bb-px-modes { display:grid; grid-template-columns:1fr 1fr; gap:16px; margin:8px 0 32px; }
.bb-px-card { border:1px solid rgba(255,255,255,0.1); border-radius:8px; padding:20px; }
.bb-px-mode-lbl { font-family:'Fira Code',monospace; font-size:10px; letter-spacing:1px; text-transform:uppercase; color:rgba(255,255,255,0.4); margin-bottom:14px; }
.bb-px-row { display:flex; gap:10px; flex-wrap:wrap; }
.bb-px-tile { display:inline-flex; align-items:center; justify-content:center; width:44px; height:44px; border:1px solid rgba(255,255,255,0.12); border-radius:4px; background:rgba(255,255,255,0.03); }
.bb-px-green { color:#4AF120; }
.bb-px-white { color:#fff; }
.bb-px-pink { color:#DD67AB; }
.bb-px-ink { color:#000; }
.bb-px-tile-ink { border-color:rgba(0,0,0,0.25); background:rgba(0,0,0,0.08); }
.bb-px-green-i { color:#4AF120; background:rgba(74,241,32,0.08); border-color:rgba(74,241,32,0.2); }
.bb-px-named { display:grid; grid-template-columns:repeat(8,1fr); gap:14px; margin:8px 0 32px; }
.bb-px-named-cell { display:flex; flex-direction:column; align-items:center; gap:8px; }
.bb-px-name { font-family:'Fira Code',monospace; font-size:10px; color:rgba(255,255,255,0.5); text-transform:uppercase; letter-spacing:0.5px; }

/* ═══════ INFOGRAPHIC ELEMENTS ═══════ */
.bb-ig-stats { display:grid; grid-template-columns:repeat(4,1fr); gap:12px; margin:8px 0 32px; }
.bb-ig-stat { display:flex; flex-direction:column; gap:4px; border:1px solid rgba(255,255,255,0.1); border-radius:8px; padding:18px; background:#0a0a0a; }
.bb-ig-stat-green { border-color:rgba(74,241,32,0.3); background:rgba(74,241,32,0.05); }
.bb-ig-stat-i { color:#4AF120; }
.bb-ig-num { font-family:'Fira Code',monospace; font-size:28px; font-weight:400; color:#fff; line-height:1; margin-top:8px; }
.bb-ig-lbl { font-size:11px; text-transform:uppercase; letter-spacing:0.5px; color:rgba(255,255,255,0.5); }
.bb-ig-pipe { display:flex; align-items:center; gap:8px; flex-wrap:wrap; border:1px solid rgba(255,255,255,0.1); border-radius:8px; padding:24px; margin:8px 0 32px; background:#0a0a0a; }
.bb-ig-node { display:flex; flex-direction:column; align-items:center; gap:8px; flex:1; min-width:80px; }
.bb-ig-node-lbl { font-family:'Fira Code',monospace; font-size:11px; color:#fff; }
.bb-ig-arrow { color:rgba(74,241,32,0.5); flex-shrink:0; }
.bb-ig-cmp { display:grid; grid-template-columns:1fr 1fr; gap:16px; margin:8px 0 16px; }
.bb-ig-cmp-col { border:1px solid rgba(255,255,255,0.1); border-radius:8px; padding:20px; background:#0a0a0a; }
.bb-ig-cmp-win { border-color:rgba(74,241,32,0.3); }
.bb-ig-cmp-h { display:flex; align-items:center; gap:8px; font-size:13px; font-weight:600; margin-bottom:12px; }

/* ═══════ COMPOSED INFOGRAPHIC (single image) ═══════ */
.bb-poster { width:640px; max-width:100%; background:#0a0a0a; border:1px solid rgba(255,255,255,0.12); border-radius:8px; overflow:hidden; margin:8px 0; }
.bb-poster-top { height:4px; background:#4AF120; }
.bb-poster-head { padding:32px 32px 20px; }
.bb-poster-kicker { display:flex; align-items:center; gap:8px; font-family:'Fira Code',monospace; font-size:11px; letter-spacing:1px; text-transform:uppercase; color:rgba(255,255,255,0.5); margin-bottom:16px; }
.bb-poster-head h2 { font-size:30px; font-weight:500; line-height:1.1; margin:0 0 12px; color:#fff; letter-spacing:-0.02em; }
.bb-poster-head p { font-size:14px; color:rgba(255,255,255,0.6); max-width:48ch; margin:0; }
.bb-poster-flow { padding:8px 32px; position:relative; margin:0; list-style:none; }
.bb-poster-row { display:flex; align-items:flex-start; gap:16px; padding:6px 0; position:relative; }
.bb-poster-iconcol { display:flex; flex-direction:column; align-items:center; gap:5px; flex-shrink:0; }
.bb-poster-chev { color:rgba(74,241,32,0.5); }
.bb-poster-icon { position:relative; z-index:1; flex-shrink:0; }
.bb-poster-txt { flex:1; min-width:0; }
.bb-poster-n { font-family:'Fira Code',monospace; font-size:11px; color:#4AF120; }
.bb-poster-txt h4 { font-size:15px; font-weight:600; margin:2px 0 4px; color:#fff; }
.bb-poster-txt p { font-size:12.5px; color:rgba(255,255,255,0.55); margin:0; line-height:1.5; }
.bb-poster-metric { font-family:'Fira Code',monospace; font-size:10px; text-transform:uppercase; letter-spacing:0.5px; color:#4AF120; flex-shrink:0; text-align:right; padding-top:2px; white-space:nowrap; }
.bb-poster-foot { display:flex; align-items:center; justify-content:space-between; gap:16px; background:#000; border-top:1px solid rgba(255,255,255,0.1); padding:20px 32px; margin-top:12px; }
.bb-poster-stats { display:flex; gap:28px; }
.bb-poster-stat { font-family:'Fira Code',monospace; font-size:22px; color:#fff; display:block; line-height:1; }
.bb-poster-stat-l { font-size:9px; text-transform:uppercase; letter-spacing:1px; color:rgba(255,255,255,0.4); }
/* Horizontal poster */
.bb-poster-wide { width:100%; max-width:1100px; }
.bb-poster-hflow { display:flex; align-items:flex-start; gap:6px; padding:28px 28px 12px; }
.bb-hstep { flex:1 1 0; min-width:0; display:flex; flex-direction:column; align-items:flex-start; gap:7px; }
.bb-hstep .bb-poster-n { display:block; }
.bb-hstep h4 { font-size:14px; font-weight:600; margin:1px 0 1px; color:#fff; }
.bb-hstep p { font-size:11.5px; color:rgba(255,255,255,0.55); margin:0; line-height:1.45; }
.bb-hchev { color:rgba(74,241,32,0.5); flex-shrink:0; margin-top:11px; }
@media (max-width:720px) { .bb-poster-hflow { flex-direction:column; } .bb-hchev { transform:rotate(90deg); } }

@media (max-width:720px) {
  .bb-px-modes, .bb-ig-stats, .bb-ig-cmp { grid-template-columns:1fr; }
  .bb-px-named { grid-template-columns:repeat(4,1fr); }
}
</style>