Paymahn Moghadasian

Today, Goldsky completed its first SOC 2 Type II audit. The report covers our security, availability, and confidentiality controls over a full observation period and is available on request.

First, a thank you to the team who put up with my tickets and reminders for over a year 🙂

Our engineering team built our security program into into the systems we operate every day. Most codified how we already worked, with the audit as the forcing function to write them down, close edge cases, and automate where useful.

We wanted to clear SOC 2 on hard mode and do more than the framework required, because every policy had to meaningfully improve our security. Where the framework prescribed processes we wouldn't otherwise run, we did the extra work of showing the auditor that our production already covered the underlying risk. Where it set a minimum, we set ours higher.

Audits happen once a year but production runs continuously. Controls strong enough for production are easily strong enough for audits.

The report establishes a floor of security practice. Treating it as engineering work rather than a checklist to pass is what makes that floor sit high enough to reliably protect the data running through us.

, your workloads sit on infrastructure with independently attested controls for security, availability, and confidentiality. The attestation is something you can use downstream for your own customers, regulators, or anyone asking how your vendors handle security.

For teams shipping stablecoin infrastructure, payment rails, prediction markets, or anywhere customer data and money moves through the application, our SOC 2 attestation puts third-party rigor behind the foundation you're building on.

SOC 2 is often referred to as a certification, but the formal outcome is an independent attestation. There's no certificate. An accredited CPA firm evaluates the design and operation of a company’s controls over a defined observation period and issues a report documenting the results.

A Type II report goes beyond reviewing whether controls exist on paper. It evaluates whether those controls operated effectively throughout the audit period. The result is a detailed report that customers, partners, and auditors can use as part of their own security and vendor risk reviews.

For our SOC 2 Type II report or any other security questions, reach out to our team at 

Goldsky is now SOC 2 Type II attested

Subgraphs provide an unprecedented developer experience for blockchain indexing by offering direct and granular controls to full-stack developers. With subgraphs, you can easily create a Typescript-based indexer that is incredibly easy to grok as a full-stack developer. However, subgraph indexing can be slower compared to 

, since it relies on purely sequential event-by-event crawling through the chain. This can lead to long development cycles (up to a month for bigger subgraphs!)

At Goldsky we’re committed to making it easier and faster to get the data developers need so they can focus on building. We employ various methods such as intelligent pre-caching, and tiered RPC node balancing with both dedicated nodes and shared APIs.

In this blog post, we’ll dive into how Firehose, a files-based approach to blockchain data streaming combined with other proprietary enhancements, enabled 

Firehose is an open-source, files-based streaming layer built by 

, and uses object storage instead of RPC<sup id="note-source-1">

</sup> (Remote Procedure Call) providers. RPC providers can vary widely in reliability and can also be expensive, so reducing the reliance on RPC providers to do data indexing is a significant improvement to the developer experience. Object storage is battle-tested and far more reliable in high throughput applications.

Firehose is a distributed system with the following components:

With Firehose, blockchain data is represented in flat files in an object store. When Firehose needs to increase scale, there’s no need to increase data duplication or worry about differences in sync state across instances of Firehose nodes. The Firehose node is simply a 

 that fetches data from the object store (we’re oversimplifying a bit here but we’ll save the details for a future post).

This files-based approach allows Firehose to improve subgraph indexing performance in the following ways:

Finally, Firehose gracefully handles reorgs which is a critical capability when working with blockchain data.

We’re very happy with how Firehose allowed us to deliver a 3x indexing speed performance improvement for ZORA, and now all of our customers can reap the benefits of our Firehose implementation.

Real-time Data

RPC Infrastructure

Automation

Open Source

Follow

Paymahn Moghadasian

Paymahn's articles