Decentralization in CoChilli vs Other Binary Options Platforms: A Deep Dive into Smart Contracts and Keeper Bots

Binary options trading is not new to the financial markets, but it has gained significant traction within the crypto ecosystem. However, like all crypto trading platforms, it’s essential to examine how decentralized these services truly are. In this article, we will dissect the architecture behind CoChilli and other network smart contracts to understand their decentralization features (or lack thereof). In this case, we will use Buffer Network but it’s just a mere example as other protocols work the same way.

The Buffer Network Approach

Buffer’s smart contract operates in a somewhat centralized manner. Here’s the flow:

• Making a Bet: Users make a bet on the platform.
• Timeframe Passes: The selected timeframe elapses.
• Withdrawal: Only whitelisted Buffer addresses (basically, a Buffer-controlled bot) can execute withdrawals.

The Oracles & Data Integrity

Buffer uses its service to pull asset prices and insert them into the contract. The contract takes these values for granted, assuming them to be correct. The primary issue here is that these prices aren’t verified. Buffer Network controls these ‘custom oracles’, meaning they are the sole entity influencing the prices added to the contract, introducing centralized risk.

The CoChilli Way

CoChilli’s contract introduces some ground-breaking features for a more decentralized approach:

• Making and Executing Bets: Not only can anyone make a bet, but anyone can also execute the function to finalize the bet.

Oracles & Data Verification

Unlike Buffer, CoChilli uses Pyth Network for asset prices, providing a more transparent and tamper-resistant price feed. Furthermore, CoChilli is the first dApp of its kind that cryptographically verifies the authenticity of the data.

If you are interested here comes the logic behind the no permission modifier and anyone being able to call the function — check out the end of the article where we will go through the function code step by step.

The Keeper Bot (a.k.a. the Keeper)

Buffer has a permissioned keeper. If Buffer decides to shut down its keeper, all payouts can be halted. CoChilli’s Keeper, on the other hand, is permissionless. Anyone can create their own keeper bot to interact with the CoChilli platform. This makes CoChilli robust against single points of failure.

User Empowerment

While many users might opt for the convenience of using CoChilli’s keeper due to time or technical limitations, the permissionless nature of the keeper ensures that anyone can create their own keeper bot if CoChilli’s happens to be down for some reason. Users are not just passive participants; they can actively interact with the platform’s smart contract and become part of its operational infrastructure.

Conclusion

The goal of blockchain technology is to provide trustless, secure, and decentralized ecosystems. CoChilli’s approach brings the platform closer to this ideal by enabling a more open, transparent, and inclusive operation. In contrast, our competitors model, while functional, leaves much to be desired in terms of decentralization and transparency.

— — — — — — — — — — — — — — — — — — — — — — -

Going deeper into the Smart Contract Magic

For the more advanced users we have decided to break down the executeBet function in the CoChilli contract to understand its workflow:

function executeBet(
    uint256 betId,
    bytes calldata openPriceVaa,
    bytes calldata closePriceVaa
) external payable whenNotPaused { ... }

• The function is external and payable, allowing it to be called from outside the contract and accept Ether.
• whenNotPaused is a modifier that only allows the function to be executed when the contract is not paused.
• Parameters:
• betId: Unique identifier for the bet.
• openPriceVaa: Bytes for the opening price from Pyth Network.
• closePriceVaa: Bytes for the closing price from Pyth Network.

Function Steps

1. Validate the Bet Status

BetDetails memory closeBetDetails = betIds[betId];
if (closeBetDetails.endTime >= block.timestamp) revert InvalidTimestamp(); 
if (!closeBetDetails.active) revert InactiveBet();

• It first fetches the bet details using betId and checks whether the bet is still active and if its end time has passed.

2. Get the Prices

bytes32 pairId = pairIds[closeBetDetails.pair];
(int64 openPrice, uint256 openFee) = getPrice(pairId, openPriceVaa, closeBetDetails.startTime);
(int64 closePrice, uint256 closeFee) = getPrice(pairId, closePriceVaa, closeBetDetails.endTime);

• Obtains the asset prices (opening and closing) from Pyth Network using the getPrice function.

3. Validate the Fee

if (openFee + closeFee != msg.value) revert InvalidFee();

• Checks if the sum of openFee and closeFee equals the Ether sent (msg.value).

4. Update the Bet Status

betIds[betId].active = false;
betIds[betId].openPrice = openPrice;
betIds[betId].closePrice = closePrice;

• Marks the bet as inactive and updates the opening and closing prices.

5. Calculate and Send Payout

uint256 payout = closeBetDetails.payout;
lockedLiquidity -= payout;
if ((closeBetDetails.isLong && closePrice >= openPrice) || 
   (!closeBetDetails.isLong && closePrice <= openPrice)) 

{bool success = token.transfer(closeBetDetails.user, payout);
    if (!success) revert PayoutFailed();
    
    emit BetExecuted(betId, closeBetDetails.user, true, payout);
    return;
}

• Determines if the user has won the bet based on their position (long or short) and price movement.
• Transfers the payout to the user if they won.

6. Fallback Case

betIds[betId].payout = 0;
emit BetExecuted(betId, closeBetDetails.user, false, 0);

• If the bet is lost, sets the payout to 0.

Event Emission

• Emits a BetExecuted event regardless of whether the bet was won or lost.

By making this function open to anyone, CoChilli ensures a permissionless ecosystem where anyone can validate the bet, adding an extra layer of decentralization to the platform.