# 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** ```solidity 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** ```solidity /* 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 . 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** ```solidity 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** ```solidity 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.