Blockchain Development Outsourcing vs In‑House: How to Keep API Quality High

When it comes to making decisions, a lot of folks in charge often feel torn between two main paths: should they outsource their blockchain development or should they build a team in-house?
This guide is packed with some great tips to help you keep your API quality on point, no matter which path you choose to follow. If you really want to nail it, start with a contract-first design. It’s all about laying down the groundwork first. Don’t forget to set some measurable SLOs too! These will help keep things on track. Next, throw in some chain-specific guardrails--they’re like your safety net, keeping everything running smoothly. And, of course, you want to make sure you’ve got provable data integrity. With all these steps, you’ll be ready to roll out your project quickly and with a lot less chance of running into surprises along the way.

APIs really make or break blockchain projects. They're absolutely crucial! Take a look at this super useful playbook from 7Block Labs! It’s got all the tips you need to set your quality standards, keep them on track, and avoid those common pitfalls that often trip people up with chains and providers. You won’t want to miss it!

Why API quality is your bottleneck in blockchain projects

So, it looks like your users are really getting into blockchains using different APIs like JSON-RPC, REST, WebSockets, and gRPC, right? Let's be honest here--if your system is dealing with latency problems, giving you mixed responses, or if there are unexpected changes in the RPC, it can really mess things up. We’re talking failed transactions, balances that just hang around unnecessarily, or a UI that leaves you scratching your head. Not exactly the smooth experience we all want, right?

Ethereum is always changing, and that means there are new trends and practices popping up all the time that you’ve got to stay on top of. For instance, blob transactions are making waves thanks to EIP-4844. Hey there! Just a quick reminder to ensure your APIs are set up to properly manage things like max_fee_per_blob_gas, blob_versioned_hashes, and the fresh receipt fields related to blob gas usage. It's super important for everything to work smoothly!
If you miss these details, you might end up messing up the way you read L2 fee data once Dencun goes live. That's set to hit the mainnet on March 13, 2024, so it’s definitely something to keep an eye on! Take a look at this: (eips.ethereum.org). You'll find some really interesting stuff there!

Just remember that the way finality and consistency work can differ quite a bit from one chain to another. For example, when it comes to Ethereum, it usually wraps up transactions after about two epochs, which is around 12 minutes or so. 8 minutes. On another note, Solana provides different levels of “commitment” - think of terms like processed, confirmed, and finalized - and each comes with its own set of safety guarantees. It's really crucial for your API to convey these details clearly. If you want to dive deeper into the details, check this out: ethereum.github.io. It’s got a ton of info waiting for you!

Outsourcing vs in‑house: what actually changes for API quality

Whether you’re partnering with a vendor or building something from scratch, there are a few key things you really shouldn’t skip over. First up, having a contract-first API is crucial. Then, make sure you’ve got clear service level objectives (SLOs) along with error budgets to keep everything in check. It’s also super important to understand how all the pieces fit together. Lastly, don’t forget about solid observability--it can make a world of difference! This is where things really start to shift.

Outsourcing advantages
Setting up a multi-chain RPC can be super easy if you decide to outsource it. You'll get managed SLAs and scalability right off the bat, plus some of the best node providers out there are hitting 99% uptime. 9% to 99. 99% availability. Take a look at infura.io when you get a chance!
And the great thing is, the vendor ecosystem has your back when it comes to protocol upgrades (like Dencun/4844). This way, you can kick back and concentrate on other important stuff! More info here: blog.ethereum.org.
Outsourcing risks Hey, just a quick heads up about those provider limits! A lot of platforms put a cap on methods like eth_getLogs, usually restricting it to a 10,000-block range. This can really mess with your analytics and backfills if your API doesn't manage pagination well. So, make sure you're set up to handle that! Dive deeper at quicknode.com.
And hey, keep an eye out for those sneaky hidden limits on archive data! Just a heads up, some methods might need archive nodes if you want to dig into historical states--like anything older than about 128 blocks. But keep in mind, not every plan includes that by default. Learn more at alchemy.com.
In-house advantages When you keep everything in-house, you really get to take the reins on versioning, define your service level agreements, and manage the unique quirks of your chain. It’s all about having that tight control that can make a big difference! You can also try out custom clients, like Erigon and Geth, and really dig into the differences between archive and full node setups. It's a great way to see how they each work!
In-house risks Hey, just a heads up--if you decide to go in-house, you’re going to be in charge of handling upgrades! So, when Ethereum drops new transaction types or if Starknet moves on from certain RPC versions, that's all on you to monitor. You’ll want to stay sharp on finality and those consensus edges! Hey, if you're interested, you can dive into all the details over at eips.ethereum.org.

So, here's the deal: pick the model that fits your level of operational maturity the best. The quality standards mentioned below are relevant for both choices.

Set a non‑negotiable quality bar: SLOs, SLIs, and error budgets

Define Service-Level Indicators for Your Blockchain APIs and Automate Their Enforcement

When you think about blockchain APIs, having clear service-level indicators (SLIs) is really key. These indicators are great for keeping tabs on how your APIs are doing and making sure they're living up to your expectations. Let me break it down for you--here's an easy way to define and automate SLIs (Service Level Indicators) for your blockchain APIs.

Step 1: Identify Key Performance Metrics

Consider what really matters to your users when it comes to your APIs. What features or functionalities do they find most valuable? Here are a few common SLIs you might come across:

Latency: This is all about how quickly your API gets back to you after it receives a request.
Throughput: This basically refers to how many requests your API can manage within a specific time period.
Error Rate: This is basically the percentage of requests that didn’t go through compared to the total number of requests made.
Uptime: This refers to how long your API is up and running smoothly, ready for action!

Step 2: Set Clear Targets

Every metric needs to have clear targets set. For example:.

Latency: Aim for a response time of less than 200 milliseconds.
Throughput: Try to hit at least 100 requests every second.
Error Rate: Aim to keep it under 1%.
Uptime: Aim for that solid 99%. 9% availability.

Step 3: Collect Data

To stay on top of these metrics, you’ll want to consistently gather data. You can check out tools like:

Prometheus: It's a super handy monitoring system and time series database.
Grafana: It's awesome for turning your metrics into easy-to-read visuals that anyone can understand. If you're looking for great tools to keep an eye on your APIs, you might want to check out DataDog or New Relic. Both of them are solid choices!

Step 4: Automate Monitoring and Reporting

Make sure to set up alerts that will let your team know whenever any SLI dips below the target. It’s a great way to keep everyone in the loop and stay on top of things! You can totally automate this using:

# Example of a basic alert setup using Prometheus Alertmanager
groups:
- name: api-alerts
  rules:
  - alert: APILatencyHigh
    expr: api_latency_seconds > 0.2
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "High latency detected for API"
      description: "Latency is above 200ms for the last 5 minutes."

Step 5: Review and Adjust Regularly

Make sure to carve out some time to check in on your SLIs every now and then. It’s a good idea to keep tabs on them regularly! If you spot any ongoing problems or shifts in how users are behaving, go ahead and tweak your goals or strategies to match.

Conclusion

When you set up and automate your SLIs for blockchain APIs, you'll get a much better sense of how they're actually doing. This not only helps provide top-notch service for users but also keeps your API working like a charm.

Surface Availability SLOs:
Public read endpoints: Our goal is to achieve at least 99. We've got a monthly availability goal of 9%, which means we're really tight on our error budget--it's basically at 0 or less. 1%.
Write/transaction endpoints: Our goal is to hit a range of 99. 5% to 99. We’ve got this covered with a straightforward system for “pending,” “confirmed,” and “finalized” statuses to make everything crystal clear. Just 9% and you’re good to go!
Latency SLOs: So, for our reads, we’re aiming for the 95th percentile to be under 300 milliseconds. And for writes, we’re looking at a goal of under 1 second for the 95th percentile as well. Just a quick heads up, though--this doesn’t factor in the time it takes for chain confirmations.
Error budget policy: So, if we reach our error budget limit, it’s time to take a step back from any risky changes. Instead, we should shift our focus to making everything more reliable. If you want to dive deeper into it, just check it out here. It's got all the info you need!

Instrument these with OpenTelemetry: Make sure to log rpc.client.duration, rpc.server.duration, and set rpc.system to "jsonrpc". Don’t forget to include the method names, any error types, and the sizes of the requests too! This will help you connect any spikes you notice to particular JSON-RPC calls. Take a look at this: (opentelemetry.io). You'll find some useful info there!

Contract‑first API design that survives provider churn

Use OpenAPI 3. First off, let’s get a clear picture of your REST surfaces, such as pre/post-processing, authentication, and webhooks. It’s super important to make sure we define those error shapes, too. Since 3. 1 works perfectly with JSON Schema 2020-12, so you can really put your payloads to the test with some reliable validation! (openapis.org).
Take a moment to check out your specs with Spectral. Seriously, it’s a total game-changer for CI! Don’t forget to include the OWASP ruleset while you’re at it. You won’t regret it! And hey, don’t forget to give auto-mocking with Prism a shot! It’s a great way for your front-end team and partners to team up and start working together, even before your backend is up and running. (github.com). Hey there! Just a quick reminder about JSON-RPC: make sure you're all set up for batch requests as the specs suggest. Oh, and don’t skip out on highlighting method-level versioning in your documentation - it's super important for keeping track of those chain differences! (json-rpc.org). Get on board with consumer-driven contract tests for your main processes. You know, like when you submit a transaction, check the receipt, and then fetch the proof. It’s a great way to keep everything running smoothly! Check out Pact for handling HTTP requests and events, and don’t forget to bring in Dredd! It’s a great tool to keep your implementation aligned with the contract. (docs.pact.io).

Chain‑specific pitfalls and how to guardrail them

Ethereum and EVM L2s

Dencun/4844 Compatibility Hey, just a quick reminder to make sure you’re handling those blob-transaction fields like max_fee_per_blob_gas and blob_versioned_hashes correctly--both accepting and returning them as needed. Thanks! Hey, just a quick reminder--make sure to add those blob gas metrics into your telemetry! And while you’re at it, don't forget to validate those fields in your OpenAPI/JSON schemas. It’ll save you some headaches down the line! If you want to dive deeper into it, just take a look here. It’s got all the details you’ll need!
Finality Awareness
It's smart to show the "head/safe/finalized" block tags downstream. That way, callers get to pick what works best for them--whether they care more about safety or the latest updates. So, if someone is all about making smart, risk-aware payments, they’d definitely want to go with finalized. EIP-1898 introduces blockHash and block number objects to help make things less confusing during reorganizations. If you're looking for more details, you can check it out here. It's all laid out for you!
Logs Backfills Many providers set limits on the eth_getLogs ranges, usually capping them at around 10,000 blocks. If you’re using a free tier, you might find the limits are even tighter. To tackle this, you should set up segmented queries and include some retry logic. It would be really handy if you could include a clear pagination system in your API. If you're looking to figure this out, you can check it out here. It'll give you all the info you need!
Archive Data
If you want to check out historical blocks, you'll need access to the archive state. This is important for things like looking up balances, storage details, code, or even using eth_call with older block numbers. Your API should intelligently direct requests to backends that have archiving enabled. If that's not an option, it should simply respond with a clear 4xx error that says, "Upgrade required." If you want to dive deeper into it, check it out here.
Verifiable Responses When it comes to those high-trust scenarios, it's super important to provide merkle proofs (eth_getProof) right alongside the values you're looking up. This lets clients check the state root right from the block header. If you want to dive deeper into this topic, you can check it out here.

// Request: read a balance at "finalized" state using EIP-1898 format
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "eth_getBalance",
  "params": ["0xabc...123",
    {"blockNumber":"finalized"} // or {"blockHash":"0x..."}
  ]
}

Solana

**Commitment levels matter. Hey there! So, when you're working with this, it's really key to include a commitment parameter and be transparent about what each option means. You've got three choices: processed is the fastest, confirmed is a middle ground, and then there's finalized, which is the safest bet. Just make sure you understand the trade-offs!
Hey there! Just a quick reminder to make sure your API defaults are in sync with the recommended levels for whatever use case you're working on. It's super important to keep things aligned! So, when you’re looking at wallet balances, make sure you check for confirmed. On the other hand, if you're diving into settlement screens, you'll want to look for finalized. For more info, feel free to take a closer look here.
There are specific rate limits for each method. Just a heads up, certain RPC methods, such as getProgramAccounts and getTokenLargestAccounts, have their own rate limits to keep things running smoothly. For example, you might see limits around 3 requests per second (RPS) or even up to 50 RPS if you’re using some of the more popular providers. So, it's good to keep those in mind! It's a smart move to add throttling and backpressure to your system. Trust me, it's worth it! Oh, and make sure to include some backoff tips in your API docs! It’s super helpful for users to know how to handle things when requests go haywire. Want all the details? Check it out here!

Starknet

Hey there! Just a heads up, RPC versions actually have a deprecation schedule set up. So, if you're keeping track of these things, you might want to take a look at it. It’s all about making sure everything stays up to date and runs smoothly! 6 and 0. Looks like 7 are heading out, while 0 are sticking around. 8 to 0. The current versions will stick around until 2025. Hey, you know what? It's really smart to chat with your clients about which version they're using. And while you're at it, consider setting up some smoke tests. These are super handy because they'll catch any builds that break if an endpoint decides to stop supporting an older version. Just a little extra layer of protection! Take a look here for all the details: (community.starknet.io).

Security patterns specific to Web3 APIs

Go ahead and use Sign-In With Ethereum (EIP-4361) to log in your users and manage their sessions. It's a smooth way to keep everything secure and simple! Hey there! Just a quick reminder to double-check your domain binding. It's super important to keep things secure, so don't forget to mix it up with some nonces too. And, of course, make sure to keep an eye on those expiry dates! Also, be sure to hang onto that signed message and signature for your audit trail. It'll make your life a lot easier down the road! If you're looking to explore more, you can check it out here. Enjoy!

Hey, don't overlook the OWASP API Security Top 10 for 2023! It's super important to pay attention to authorization at both the object and property levels. Make sure you’re keeping an eye on resource consumption too. And don't forget to set up those SSRF protections for your webhooks! Lastly, keep your inventory and versioning in check--it's all part of staying secure! A great tip is to weave Spectral’s OWASP ruleset into your CI process. This way, you can catch any spec-level issues early on! Check out more here.

Hey there! So, when you're diving into service-to-service calls, you've really got to check out mTLS or HMAC. They're super reliable! And don't forget, it's super important to secure any sensitive RPC methods, like debug or trace. Make sure they're only accessible to trusted networks. Safety first, right?

Resilience engineering: retries, timeouts, rate limits, idempotency

Retries with a twist: Try using a truncated exponential backoff, but throw in a bit of randomness to keep things interesting! Oh, and just a heads up--try to avoid redoing any actions that aren't idempotent unless you've got those idempotency keys ready to go. If you want to dive deeper into this, feel free to check it out here!
Deadlines/Timeouts: Always remember to set those RPC deadlines! It’s a smart move to keep everything on track. Hey, make sure you pass that info along to keep those pesky hang-ups and cascading failures at bay! More info available here.
gRPC/JSON-RPC telemetry: Don’t forget to keep an eye on the method, status, duration, and payload size. Tracking these can really help you identify any calls that might be causing issues. Check out all the details right over here.
Idempotency for writes: Don’t forget to include the Idempotency-Key in your POST and DELETE requests. If you need to retry, just send back the original successful response. It keeps things nice and smooth! It's a smart idea to jot down how to deal with conflicts if a reused key doesn’t align with the payload. That way, everyone knows what to do when things don’t match up! If you want to dive deeper into this topic, go ahead and take a look here. You’ll find some really useful insights!
Rate limiting: Consider putting token or sliding-window policies in place directly at your API gateway. It’s a smart way to manage traffic and keep everything running smoothly! Just a quick reminder to make sure you include those standard headers (RateLimit-*) when you send your stuff back. It’s also super helpful to give your clients a bit of guidance on that. They'll appreciate it! If you're using Kong, you'll definitely want to check out their advanced plugin. It works wonders for setting up sliding windows and syncing with Redis. Learn more here.

Testing that catches chain/provider drift before users see it

Contract tests: Let’s make sure we’re getting those Pact contracts from the consumers. It’s super important for providers to verify them with every build, so we stay on top of things. Make sure to use Dredd with your OpenAPI! It’ll help keep your implementation and your spec totally in sync. Trust me, it's a game changer. Hey, if you want to dive into the details, just click here. You'll find all the info you need!
Testing with local mainnet forks: You can use tools like Hardhat or Foundry Anvil to create a shadow fork of Ethereum. It's a great way to get hands-on experience! This is an awesome way to replicate those tricky on-chain states and test out upgrades or reorganizations in your CI. Hey, just a quick reminder to pin your blocks for reproducibility! If you need more details, you can check it out here. Happy coding!
Synthetic monitors: Make sure to set up ongoing checks that target those “canary” RPCs that tend to cause issues during upgrades. They've got a track record of breaking, so keeping an eye on them is super important! This can involve stuff like using eth_getLogs with tight timeframes, calling eth_getProof on contracts you already know about, or checking out Solana's getProgramAccounts with some targeted filters. Don't forget to set up alerts for when the p95 or error rate jumps past your service-level objectives (SLOs). It’s super important to catch those spikes early!
Load testing: Let’s put those “heavy” RPCs to the test with some real-world data! A great approach would be to break down eth_getLogs into chunks of 2,000 blocks and set a limit on the response size. This will give us a clearer picture of how they perform under pressure! It's super important to check those provider-specific limits in your CI pipeline. If you're interested in learning more, feel free to check this out here. There's a lot of cool info waiting for you!

Example rollout: making your API EIP‑4844‑aware without downtime

1. Alright, it's time to refresh the schemas and the clients a bit. We need to make sure they can handle transaction type 3 along with those new fields: max_fee_per_blob_gas and blob_versioned_hashes. Let's get to it! Let’s throw in some unknown-field tolerance to make sure we can handle future changes more smoothly. Hey, if you're interested, you can get all the details right here.

2. We should get some canary monitors in place for blob transactions. Just a heads up, you’ll need to check out those receipts and make sure everything’s validated properly. And hey, don’t forget to keep an eye on that blob gas usage too!

3. We’ll direct a small portion of our traffic to the new code by using a feature flag. Let's take a look at the p95 latency and error rates and see how they stack up against our baseline. It'll give us a good idea of how things are doing!

4. Just a heads up, it's super important to double-check everything on a mainnet fork, whether you're using Hardhat or Anvil. Don't forget to look at those recorded blob transactions, too! It’ll save you from any headaches down the line. Hey, don’t forget to run the Pact/Dredd suites as well! If you need more details, just check out this link here. It’s got you covered!

5. Let’s gradually increase the traffic. If we notice that the error budget is getting used up way too quickly, we can just pause the rollout for now. Hey! If you're looking for the error budget policy, you can find it right here.

Vendor due diligence checklist (RPC and dev partners)

Hey everyone! Could you do me a favor and ask the providers or vendors to put together some documentation? And if they can, it would be awesome to have links included wherever it makes sense. Thanks a bunch! Thanks!.

Take a look at their status page to see their availability commitments and check out their history. You can also find out if they're hitting that 99% mark! The 9% uptime is backed by solid finances. (aws.amazon.com). Let's explore eth_getLogs together! We’ll look at the block range, how many logs you can grab, and the size limits for payloads on various chains and plans. There's a lot to cover, so let's break it down! (quicknode.com). Hey there! If you're wondering about archive coverage, it’s definitely worth checking out the pricing and limits. Plus, see if they automatically route those old calls for you. It could save you a lot of time! (alchemy.com).

Let's dive into the details about Dencun/4844! We'll cover the upcoming protocol support timelines, the testnets that are currently in action, and how to navigate the cutover playbooks. (blog.ethereum.org). Take a closer look at the commitment defaults in Solana, and make sure to check out the RPS limits for specific methods, like getProgramAccounts and getTokenLargestAccounts. (quicknode.com).
Make sure you keep an eye on Starknet's RPC version support and their plans for phasing out older versions. It’s good to know what’s going on! (community.starknet.io). When it comes to security, make sure to check out their SOC 2 and ISO 27001 certifications. It's also a good idea to look into whether they offer mTLS options, IP allowlisting, and protections against webhook SSRF. Plus, don't forget to take a peek at their documented OWASP controls. It's all about keeping your data safe, right? (owasp.org).

Brief, chain‑aware API design patterns you can copy

Finality-aware reads
Ethereum: We're excited to introduce some new blockTag options, like safe and finalized. For balance checks, we’ll be using safe, while latest will be our go-to for those minor UI tweaks. (eips.ethereum.org).
Solana: Great news! You can now use the commitment option, which is set to confirmed by default. But hey, if you need to switch it up, go for it! (docs.solanalabs.com).
Deterministic backfills Sure! When you're using eth_getLogs, just split it up into chunks of 2,000 blocks each. And make sure the responses stay under 150 MB, okay? This way, you’ll keep everything manageable and avoid any hiccups! We'll add some retry logic with a sprinkle of randomness and keep track of our progress externally, kind of like maintaining a durable state. (alchemy.com).
Verifiable state When you use eth_getProof, you'll have the option to get those handy proof objects that are tied to the specific block you're looking into. (eips.ethereum.org).
Idempotent writes Hey there! Just a quick tip: when you’re sending transactions using POST, don’t forget to include an Idempotency-Key. It’s super important! If you send us a duplicate key, no worries! We'll just give you back the same result as the original. (stripe.com).

Implementation snippet: resilient JSON‑RPC client defaults

// Pseudo-TypeScript: JSON-RPC client defaults for EVM
const DEFAULTS = {
  timeoutMs: 5000,                // set per call; never "infinite"
  deadlineMs: 10000,              // overall
  maxAttempts: 5,                 // with jittered backoff
  initialBackoffMs: 100,
  maxBackoffMs: 2000,
  jitter: true,                   // full or decorrelated
  idempotencyKeyHeader: 'Idempotency-Key',
  batchSize: 20,                  // respect provider constraints
  blockRangeChunk: 2000,          // for eth_getLogs
  acceptBlockTags: ['latest','safe','finalized'],
};

You know, it would be a good idea for Backoff to go with truncated exponential backoff with some jitter thrown in. This could really help avoid those pesky thundering herd issues! Just a quick reminder: when you come across those pesky 5xx errors, the 429 status codes, or if you run into any network timeouts, don’t sweat it--those are all good candidates for a retry! For more info, just click here! You'll find all the details you need.

The 7Block Labs API quality checklist

So, we’ve got our Service Level Objectives (SLOs) and error budgets totally sorted out. We’re keeping an eye on them regularly, and we’re sticking to the rules--burn freeze is definitely in effect! (sre.google).

The OpenAPI version 3. We've gone ahead and cleaned up the 1 and JSON-RPC contracts using Spectral and some OWASP rules for linting. Plus, we’ve mocked everything up with Prism, so we're all set! (openapis.org). We're using consumer-driven contract tests with Pact and conformance tests with Dredd in our CI pipeline. (docs.pact.io).
We've got OpenTelemetry up and running, tracking traces and metrics for rpc.system=jsonrpc. Plus, we're keeping an eye on p95 latency and the different types of errors that pop up. (opentelemetry.io). So, we’re seeing finality-aware reads being implemented now, similar to how Ethereum handles things with its safe/finalized status and Solana's commitments. Plus, the default settings are all laid out really well in the documentation! (eips.ethereum.org). Hey there! Just a quick update: our log backfill pagination is now working smoothly with the provider caps, and we’ve also got the archive routing all set up and ready to go. (quicknode.com). Hey there! Just wanted to give you a quick update: we’ve confirmed that EIP-4844 is all set in our schemas and tests. Plus, we’ve rolled out our canary monitors, so everything’s up and running! (eips.ethereum.org). Hey there! So, we're using SIWE auth to manage our user sessions, and we're totally nailing it with the OWASP API Top 10 controls.
(eips.ethereum.org). So, we've got a bunch of cool features in place. We've set up retry and deadline policies that come with a bit of randomness to keep things interesting. Plus, we’re using idempotency keys for our writes, which helps avoid duplicate actions. And let’s not forget about gateway rate limiting - we’re handling that with sliding windows to keep things running smoothly. (grpc.io). We've got the mainnet-fork tests up and running with Hardhat and Anvil. These are designed to look at how upgrades play out and see how well they can handle reorgs. (hardhat.org).
I've completed the vendor questionnaire! It covers everything from SLA to range limits, archiving, and versioning timelines. (aws.amazon.com).

Final thoughts

Whether you choose to outsource or handle things in-house, getting that top-notch API quality really comes down to having some solid discipline. So, we're diving into contract-first design, which is all about setting clear rules from the get-go. We want to make sure our finality semantics are easy to understand. Plus, we’re looking at verifiable data and establishing measurable SLOs (that’s service level objectives, just to keep it clear!). And don’t forget the ongoing conformance testing to ensure everything stays on track. It's a solid approach to building reliable systems! Once you’ve got these key elements down, making the switch to a new provider, upgrading protocols, and handling the complexities of multiple chains can go from feeling overwhelming to becoming just another part of your day-to-day. It’s all about making it feel like second nature!

Hey there! If you're thinking about having 7Block Labs review your current API setup and create a quality plan that’s aware of the chain, we’re totally here for you! This covers everything from Dencun/4844 audits to Solana commitment defaults and even benchmarking those provider caps. Let’s get started! Our team is all set to help you breeze through that checklist in no time! We’ve got your back and can get it done efficiently.

Sources

Hey, make sure to take a look at the EIP-4844 spec and its fields. Also, just a heads-up, the Dencun activation date is locked in for March 13, 2024! (eips.ethereum.org). Check out the Ethereum JSON-RPC spec and familiarize yourself with the EIP-1898 block selectors. It’s definitely worth your time! (eips.ethereum.org).

Get to know how Ethereum finality works, especially when it comes to epochs and slots. (ethereum.github.io).
Let’s dive into what Solana's commitment levels are all about, plus I’ll share some useful notes on RPS by method that you might find handy. (docs.solanalabs.com).
Check out the provider limits for eth_getLogs. (quicknode.com).
Check out what it takes to meet archive data requirements for keeping historical records. (alchemy.com). Hey, you should definitely take a look at the OWASP API Top 10 for 2023! It's got some really useful insights. (owasp.org). Check out SIWE (EIP‑4361) for some awesome updates! (eips.ethereum.org).
Start getting to know OpenAPI 3. 1, Spectral, and Prism**. (openapis.org).
Get familiar with the OpenTelemetry JSON‑RPC/RPC metrics conventions. (opentelemetry.io). Hey! Make sure to check out some info on retry backoff with jitter and get a good grasp on gRPC deadlines. It’s super helpful stuff to know! (cloud.google.com).
Discover how Kong’s advanced sliding windows for rate limiting work. (developer.konghq.com). Check out Pact and Dredd for contract testing! (docs.pact.io). Hey there! If you're interested in mainnet forking, definitely take a look at how to use Hardhat/Anvil. It's a pretty cool way to test your smart contracts without needing to mess around with real funds. Happy coding! (hardhat.org).
Keep an eye on any updates regarding Starknet RPC version changes and deprecations. (community.starknet.io).