Dialed in with Switchboard is a weekly newsletter about the various updates with Switchboard.

And we’re back with another edition of Dialed in with Switchboard. Thank you to everyone we met at the Solana hacker house. The speed at which this developer ecosystem is growing can only be witnessed in person.

And also thank you to all of the Riptide hackathon submissions that were built with Switchboard. It was an impressive lineup and we’re excited to see how they grow within the Solana ecosystem.

Anchor Fetch​

Project Serum’s Anchor framework provides a common Interface Design Language (IDL) which specifies how programs written in Anchor store data on-chain and serialize instructions. The IDL gives developers a quick way to hook into programs without needing to integrate the program’s specific API. In fact, you can view any Anchor program account using the Solana explorer and visually view the on-chain data.

Note: Switchboard V2 is written in Anchor and you can view its IDL at docs.switchboard.xyz/idl.

With that said, Switchboard has now added support to fetch any Anchor account with its newly added AnchorFetchTask. The publisher specifies the program ID and account address, and the Switchboard oracle will return the JSON representation of the parsed account data. This can then be chained with a JsonParseTask to return a single value from any Anchor account. This new feature allows developers to build complex oracles based on any Anchor account field.

Defi Kingdoms​

Switchboard has also added the DefiKingdomsTask to allow publishers to build data feeds that return the swap price of a token on DeFi Kingdoms. DeFi Kingdoms is a DeFi game built on ETH with in-game tokens and NFTs that players can trade.

Conclusion​

Oracles will need to update to dev-v2–4–12–22h to leverage these new tasks.

Building on Solana? Please find us on telegram so we can connect and build together. We’re always looking for new teams that can leverage Switchboard and are happy to build new task types to support your needs.

Dialed in with Switchboard is a weekly newsletter about the various on-going updates with Switchboard.

Jupiter Swap Task​

Switchboard is in the final stages of testing its newly created JupiterSwapTask, which will be rolled out to the oracles in the coming days.

Jupiter Swap is a liquidity aggregator on Solana and provides users with the optimal route for a swap, ensuring they get the best price each time.

Switchboard currently allows publishers to build data feeds from a number of supported liquidity protocols, such as Serum, Raydium, Orca, Saber, and Mercurial. Switchboard’s integration of JupiterSwap’s SDK streamlines this process, allowing publishers to specify an input and output token and be confident they are being returned the best price for a given swap.

Check out Switchboard’s Job Directory for an example on how to use this new task.

Raydium Swap Integration​

Switchboard oracles will now resolve the swap price for a given Raydium pool using the lpExchangeRateTask. You can find a full list of supported Raydium AMM pools in their SDK: https://sdk.raydium.io/liquidity/mainnet.json.

In Case You Missed It…​

Gas Prices On-Chain

Last week we walked you through how to resolve the current price of gas on-chain.

https://twitter.com/switchboardxyz/status/1502331039414325251

Riptide Hackathon Submissions

Switchboard is offering up to $30k in prizes for the teams that best integrate Switchboard V2 in their hackathon submission. Make sure to fill out our form for added visibility on your project.

https://forms.gle/qdt1qWtje18d5VMB7

Dialed in with Switchboard will be a weekly newsletter about the various on-going updates with Switchboard.

Lending Rate Task​

Last week Switchboard implemented the lendingRateTask thanks to the work of JetLabs with their @jet-lab/defi-yield-ts library. Developers can now source lending and borrowing rates for the top Solana lending protocols on-chain, opening the doors to new automated yield lending strategies.

Check out Switchboard’s Job Directory for some examples on how to use this new task. Also view the protobuf schema for lendingRateTask.

Mango Perps Task​

Switchboard also added the mangoPerpMarketTask to resolve the current price of perpetual markets on mango. This can be combined with the twapTask to track the time weighted average price of a mango perp market and build automated strategies around it.

Check out Switchboard’s Job Directory for some examples. You can find Mango Market’s addresses in their @blockworks-foundation/mango-client-v3 repo.

Variance Threshold added to Publisher​

The Publisher was updated to allow a configurable variance threshold field. The varianceThreshold dictates the change percentage required before an oracle reports a result on-chain. A Switchboard data feed includes a pre-funded escrow to reward oracles for each successful update. The varianceThreshold is a cost saving parameter to reduce excessive on-chain updates and extend the life of a feed. If an oracle resolves a value that is too similar to the last reported value, the oracle skips reporting a result and conserves the feed’s escrow. Note, some feeds may require the most up-to-date data so it is left up to the publisher based on their use case.

Switchboard Lease Configuration

Query Aggregator History On-Chain​

The switchboard-v2 crate was updated to 0.1.8, which updates the anchor dependency to 0.22 and added the ability to query an aggregator’s history buffer on-chain. An aggregator can be configured to store the last N results on-chain in a history buffer account. The rust crate now lets you query a history buffer and return the previous results value and timestamp. You can add a history buffer to your data feed using the Publisher on the Explorer App.

VRF CPI Example​

The @switchboard-xyz/vrf-cpi-example was updated to show how a Program Derived Address (PDA) can be used as a VRF Account’s authority and sign requestRandomness instructions on its behalf. This allows VRF Accounts to be controlled by a program and have predefined update logic.

Switchboard V2 CLI​

The @switchboard-xyz/switchboardv2-cli was updated to support account deserialization on devnet and mainnet for convenient debugging. Once installed, run the command sbv2 print PUBLICKEY where PUBLICKEY is any switchboard account, and the CLI will output the deserialized account.

Switchboard is sponsoring the Solana Riptide hackathon with $30k in prizes for the top 3 teams that best integrate Switchboard. Less than a year ago Switchboard was founded after a hackathon submission and we are grateful for the opportunity to pay it back to the developer community.

Switchboard v2 allows for permission-less feeds — bring any public data point on-chain using a network of independent oracle operators. Switchboard recently released V2 of its Verifiable Randomness Function (VRF), which allows developers to request a verifiable random value, with proof verification entirely on-chain. Verifiable randomness brings new use cases to Solana and allows developers to provide open, verifiable lotteries in their on-chain programs.

Prizes​

Switchboard will be offering the following prizes:

First Prize ($15k): Best integration of Switchboard v2

Second Prize ($10k): Best use of Switchboard VRF

Third Prize ($5k): Most interesting integration of Switchboard

Switchboard is a permission-less Oracle network allowing anyone to spin up their own data feeds and publish on-chain. To accomplish this, data feeds can be configured from a collection of tasks in order to fetch data, parse a response, then determine a final result. You can find a list of available tasks in our documentation. Today’s article will walk you through spinning up your own data feed to fetch the current weather in Miami, FL using Switchboard’s publisher site. This could be used by an on-chain program to calculate and settle insurance contracts relating to weather events.

| TWAP! TWAP! TWAP! Switchboard V2 now supports aggregator history

What is TWAP?​

A time weighted average price (TWAP) is the average price of an asset over a specified time frame. Let’s say you’re a large trader and you want to enter a large SOL/USD position. If you execute a sudden market order, you could drain the order book and end up paying substantially more for the trade, plus bots will immediately start to arbitrage and your position will be underwater immediately. If you execute the same position using a TWAP, your orders will be spread throughout the given timeframe, allowing the market to absorb your liquidity, and giving you a more optimal price of the true market value.

TWAP use cases extend beyond just trading. Here are just a few examples of how a TWAP could be used in DeFi to reduce oracle price manipulations:

• Funding Premiums: Using a TWAP over a random sample to avoid a single sample skewing the results

• Futures Expiry: Futures expiration are correlated with higher volatility. Using a TWAP reduces the risk of manipulation or banging the close.

• Lending Liquidations: A TWAP reduces scam wicks causing erroneous lending position liquidations.

• On-Chain Trading Algos: An on-chain program could use a Switchboard TWAP oracle to execute positions on Serum based on a given criteria.

Switchboard V2 is the first permissionless oracle protocol live on Solana mainnet!

When we set out to build Switchboard the goal was clear: provide permissionless data on Solana such that anyone can contribute and grow the network. Existing oracle solutions rely on whitelisting oracle operators and building custom solutions for new data feeds. We decided to take a much more scalable approach; anyone is free to publish any data feed they wish on-chain and, provided they meet the proper stake requirements, are free to run an oracle as well. Oracles are awarded each time they complete an update request and slashed when they provide incorrect results. This fits in line with the broader web3 vision and …

Today we are happy to announce the launch of Switchboard V2!

Switchboard V2 was rebuilt from the ground up using Project Serum’s Anchor framework and is the first oracle network on Solana that allows permissionless data feeds. To achieve this, we designed a publisher site that streamlines the on-chain workflow and lets developers build and deploy a data feed in under 60 seconds. The publisher site is the culmination of months of working with some of the top Solana projects, anticipating their needs, in order to provide the best experience to support the thriving developer ecosystem. We can’t wait to see what products come out of the next hackathon now that the data developers rely on when building smart contracts is right at their fingertips.

The publisher site is now live: app.switchboard.xyz

Onchain data in under 60 seconds!

Switchboard now offers fair LP token pricing oracles based on the work of Alpha Finance Lab!

The Concern​

A liquidity pool is a collection of funds locked in a smart contract, used to facilitate decentralized trading, lending, and many more functions [1]. With DeFi we are able to deposit assets into an LP pool, receive yield bearing LP tokens, and then borrow against our LP tokens. The price of these LP tokens is typically calculated by summing the total liquidity in the pool and dividing by the number of LP tokens issued. This basic calculation works well when the total liquidity in the pool is balanced between each asset but starts to fall apart when the pool liquidity is imbalanced.

Consider the WarpFinance incident where an attacker was able to use a flash loan to manipulate the price of an LP token by taking advantage of the imbalance, for which they used as collateral to borrow a greater amount of capital than was sufficiently allowed [2]. This type of hack takes advantage of the LP token price oracle in order to over-borrow from a lending provider.

When designing a decentralized protocol, it’s not enough to ensure your code is well tested — you must also align the various parties so no single entity can game the system. Today’s article will walk through the design of Switchboard V2 and how incentives are aligned to minimize trust in the protocol. Check out some of our past articles for more background on Switchboard, and how it works.

Incentives are mechanisms to influence an individual or group to behave in a certain manner. For example, tax cuts are a government incentive that reduces an entity’s operating cost to promote spending. Similarly, many food delivery companies subsidize delivery fees to capture future market share. These are all extrinsic incentives because you expect some kind of reward for your actions. Extrinsic incentives can only get you so far; eventually the food delivery companies will need to turn a profit. Decentralized projects cannot operate in the same manner as traditional companies where a single group can make the decision to sacrifice profit for future market share. Instead the incentives must be baked into the protocol and be known to all parties up front.

Switchboard was created to level the playing field and provide equal access to on-chain data which allows anyone to suggest, approve, and update feeds. We hope the community will be intrinsically motivated to support this vision and actively participate to bring this to fruition. Switchboard will never whitelist participants and will rely on the community to make improvements as the network matures. The following paragraphs detail how Switchboard is designed and how the community is able to tweak the protocol to align everyone’s incentives.

In a previous article we looked at the different stakeholders and how they operate within Switchboard V2. Today’s article will focus on the technical components and how they interact with each other. So let’s jump right in.

Overview​

What is a Data Feed?

A data feed is the centerpiece of Switchboard and is what on-chain developers will use when building smart contracts. A data feed is a collection of jobs that get aggregated to produce some deterministic result. Each job is associated with an endpoint and has a number of tasks that get executed in sequential order in order to produce a single value. Typically the first task in a job will fetch external data with subsequent tasks responsible for parsing the response and transforming the value into a single data type, like an integer or decimal. When an oracle is assigned to process a data feed update, the oracle executes the defined jobs and publishes the median result on-chain. The data feed then computes the final value as the median response among the assigned oracles. In summary, the data feed is the blueprint for how data gets fetched from off-chain sources.

Along with the jobs, a data feed also includes a configuration dictating how often a feed should be updated and the minimum number of jobs or oracles that must respond before accepting a result. The publisher is ultimately responsible for building a data feed and making the necessary trade-offs as it’s a careful balance between cost and update interval. The publisher is usually the on-chain consumer of the data and will have the most familiarity with how the data may be used to make these considerations.