Credible Commitment Device

Overview

The Credible Commitment Device (CCD) is the core contract of the Fabriq protocol. One instance of the CCD is deployed on every supported network. Filling a typical order will involve interacting with the CCD on both the origin and the destination chain. The CCD is responsible for:

• validating that orders have been signed correctly

• locking input funds until order finalization

• ensuring orders are filled correctly (coming soon)

• releasing input funds in accordance to the oracle

CCD

Functions

function initiateOrder(SwapIntent calldata _intent, bytes memory signature) public
function fillOrder(SwapIntent calldata _intent, uint256 _output) public
function finalizeOrder(SwapIntent calldata _intent) public
function disputeOrder(SwapIntent calldata _intent) public

initiateOrder will initialize a swap order. When a filler commits to fulfilling an order during a dutch auction, initiateOrder registers the filler as the winner on-chain. If the filler fails to win the auction, the registration will revert. The swap order will be validated and the swapper’s funds locked in the CCD. From here, the filler is expected to complete the swap order by the deadline.

fillOrder is called by a filler on the destination chain to claim a swap order has been fulfilled. The oracle expect the fulfillment execution to happen in the same transaction as this call, or as a multicall.

finalizeOrder will be called by the oracle once the state of the destination chain can be attested to. Once finalizeOrder has been called, the funds and profit due to a filler are unlocked.

disputeOrder can be called in two cases. The first is when the filler fails to fulfill and the swapper’s funds are locked up after deadline. By calling this the swapper can retrieve their funds. The second case is when there is a legitimate oracle dispute and the swap needs to be reversed.

Events

/* emitted when an order is registered on chain in the CCD */    
event OrderInitiated(address indexed solver, bytes32 indexed hash, address swapper);
event OrderFillClaimed(address indexed solver, bytes32 indexed hash, address swapper);
event OrderFinalized(address indexed solver, bytes32 indexed hash);
event OrderCancelled(bytes32 indexed hash);

OrderInitiated is emitted by initiateOrder to let listers, such as users, fillers, applications and intentpools update their state. It includes data to identify who will fill which has for whom.

OrderFillClaimed is emitted by fillOrder upon call by the filler. This alerts oracles to then attest to the state of the destination chain to the origin chain. This also alerts users and applications to the state of the intent.

OrderFinalized is emitted by finalizeOrder to indicate that an oracle has attested tot he correct state and funds may be unlocked. This provides users and applications applications to track completion, as well as fillers an indicator that funds are unlocked.

OrderCancelled is emitted by disputeOrder to indicate cancellation.

Order Signatures

The Fabriq protocol uses Permit2 for gasless order execution. To enable users to approve both the token transfer and the order itself with a single signature, it leverages Permit2's witness functions.

Instead of signing the Order struct directly, users should sign the EIP-712 hash of the following structure:

PermitWitnessTransferFrom(TokenPermissions permitted, address spender, uint256 nonce, uint256 deadline, SwapIntent witness)

PermitWitnessTransferFrom is provided by Permit2 https://github.com/Uniswap/permit2/blob/cc56ad0f3439c502c246fc5cfcc3db92bb8b7219/src/interfaces/ISignatureTransfer.sol#L90.

Where:

• TokenPermissions, nonce, and deadline match the values specified in the SwapOrder

• spender is set to the CCD contract address on the origin chain.

This approach enables gasless execution from the user's perspective and allows for order validation using just one signature.

Bond

The Bond is a related contract that provides the bonding primitive by composing with the CCD. It allows fillers to fill orders with third party liquidity. Liquidity providers will be rewarded with a share of the input tokens. The exact terms of the split are specified in the Bond.

Functions

function initiateOrder(SwapIntent calldata intent, bytes memory signature) public
function mint(BondInfo memory info, bytes memory signature) public
function fillOrder(SwapIntent calldata intent, uint256 outputIndex, address callback, bytes calldata payload) public

initiateOrder is called by fillers. Fillers must initiate orders through the Bond contract, so that on-chain commitments can be provided to the bond purchaser.

mint is called by a bond purchaser who has received the signed BondInfo from the bond-issuer/filler. This locks up the required liquidity from the bond purchase and in return the LP receives the bond as an ERC721.

fillOrder is called by the filler, similar to the fillOrder function provided by the CCD. However, by using this function the filler can use the LPs liquidity to fulfill as well as insert intervening transactions to be processed through the callback address and payload to be sent to the callback contract.

Events

event BondInitiated(address indexed solver, bytes32 indexed hash, address swapper);
event BondFillClaimed(address indexed solver, bytes32 indexed hash, address swapper);
event BondFinalized(address indexed solver, bytes32 indexed hash);

BondInitiated is emitted after the filler calls initiateOrder to alert counterparties to the new bond.

BondFillClaimed is emitted when the bond purchaser acquires the bond and provides the needed capital. This alerts the filler to make use of the bond.

BondFinalized is called when whatever actions the bond was issued for have been completed by the filler.