Fee Mechanisms¶

Every fee, who pays it, when it is charged, and how LINK flows through the Verdikta Dispatcher system end to end.

Token Overview¶

The Verdikta system uses two tokens:

Fee Flows by Contract¶

ReputationAggregator¶

The ReputationAggregator has the most complex fee structure due to its multi-oracle commit-reveal design.

Who Pays¶

The requester (the msg.sender of requestAIEvaluationWithApproval) pays all fees. LINK is pulled from the requester's wallet via transferFrom.

Fee Breakdown¶

Maximum Total Fee Calculation¶

function maxTotalFee(uint256 requestedMaxOracleFee) public view returns (uint256) {
    uint256 eff = min(requestedMaxOracleFee, maxOracleFee);
    return eff * (commitOraclesToPoll + bonusMultiplier * clusterSize);
    //     eff * (        K           +       B       *      P      )
}

With defaults (K=6, B=3, P=2):

maxTotalFee = eff × (6 + 3 × 2) = eff × 12

Example: If maxOracleFee = 0.05 LINK, maximum possible cost is 0.05 × 12 = 0.6 LINK.

Important: The actual cost is typically lower because: - Individual oracle fees may be less than maxOracleFee - Only P oracles (those in the best cluster) receive bonuses - Bonuses use each oracle's actual registered fee, not maxOracleFee

LINK Flow Diagram¶

Requester Wallet
    │
    ├─── transferFrom(fee₁) ──→ Aggregator ──→ sendOperatorRequestTo ──→ Oracle 1 (via ArbiterOperator)
    ├─── transferFrom(fee₂) ──→ Aggregator ──→ sendOperatorRequestTo ──→ Oracle 2
    ├─── ...                                                           ──→ Oracle K
    │
    │   (After finalization, for each of the P clustered oracles:)
    ├─── transferFrom(fee × B) ──→ Clustered Oracle 1 (direct transfer)
    └─── transferFrom(fee × B) ──→ Clustered Oracle 2

LINK Approval Requirement¶

The requester must approve the aggregator contract to spend at least maxTotalFee(maxOracleFee) LINK tokens before calling requestAIEvaluationWithApproval. Critically, the approval must remain valid through finalization — bonuses are pulled from the requester's wallet when the evaluation completes, which may be minutes after the initial request.

If the requester's allowance is insufficient at bonus-payment time, the bonus transfer fails with BonusTransferFailed(). The evaluation itself still completes (results are stored), but the affected clustered oracle does not receive its bonus.

ReputationSingleton¶

The ReputationSingleton uses a simpler 2× fee model.

Fee Breakdown¶

Maximum Total Fee Calculation¶

function maxTotalFee(uint256 requested) public view returns (uint256) {
    uint256 eff = min(requested, maxOracleFee);
    return eff * 2;  // base + bonus
}

Estimated Base Cost¶

The ReputationSingleton provides a helper for computing the estimatedBaseCost parameter used in oracle selection:

function getEstimatedBaseCost() public view returns (uint256) {
    return (maxOracleFee * baseFeePct) / 100;   // baseFeePct default: 1%
}

LINK Flow¶

Requester Wallet
    │
    └─── transferFrom(oracleFee × 2) ──→ Singleton Contract
                                              │
                                              ├─── sendChainlinkRequestTo(oracleFee) ──→ Oracle
                                              │
                                              └─── transfer(oracleFee) ──→ Oracle (bonus, on fulfillment)

Key difference from Aggregator: The ReputationSingleton pulls 2 × oracleFee upfront into the contract, then pays the bonus from its own balance at fulfillment. The requester's LINK allowance is fully consumed at request time. If the evaluation times out, the bonus LINK remains in the contract (recoverable by owner via withdrawLink).

SimpleContract¶

The SimpleContract has the simplest fee model with a fixed oracle.

Fee Breakdown¶

Maximum Total Fee¶

function maxTotalFee(uint256) external view returns (uint256) {
    return fee * 2;  // parameter is ignored; uses the fixed configured fee
}

LINK Flow¶

Requester Wallet
    │
    ├─── transferFrom(fee) ──→ SimpleContract ──→ sendChainlinkRequest ──→ Oracle
    │
    │   (At fulfillment, contract pulls bonus directly from requester:)
    └─── transferFrom(fee) ──→ Oracle (bonus, pulled during fulfill callback)

Key difference: The bonus in SimpleContract is pulled directly from the requester by the contract during the fulfill callback via link.transferFrom(requester, msg.sender, fee) — the requester's allowance for the SimpleContract must persist through fulfillment.

VDKA Staking¶

Oracle operators must stake VDKA tokens to register with the ReputationKeeper.

Staking Flow¶

Oracle Owner Wallet
    │
    └─── approve(keeper, 100 VDKA)
    └─── registerOracle(oracle, jobId, fee, classes)
              └──→ transferFrom(caller, keeper, 100 VDKA)

The staker must be either the oracle contract owner (IOracleOwner(oracle).owner()) or the ReputationKeeper contract owner.

Unstaking Flow¶

deregisterOracle(oracle, jobId)
    │
    └──→ transfer(oracleOwner, remainingStake)

Stake is returned to IOracleOwner(_oracle).owner(), not necessarily to the original staker. The oracle must not be locked (block.timestamp >= lockedUntil).

Slashing¶

When an oracle crosses a penalty threshold (see Reputation System): - stakeAmount -= slashAmountConfig - If stakeAmount < slashAmountConfig, stake is set to 0 - Slashed tokens remain in the ReputationKeeper contract (not burned) - The owner can recover slashed tokens via standard ERC-20 transfers from the keeper

Fee Configuration¶

ReputationAggregator Settings¶

ReputationSingleton Settings¶

SimpleContract Settings¶

The SimpleContract's fee is set at deployment and is not dynamically configurable (no onlyOwner setter pattern).

Oracle Fee Registration¶

Each oracle registers with a specific LINK fee via registerOracle(..., fee, ...). This fee is what the oracle charges per request. Oracles with fees above a request's maxFee parameter are excluded from selection. The fee must be greater than 0.

Emergency LINK Withdrawal¶

All aggregation contracts provide a withdrawLink(address payable to, uint256 amount) function for recovering LINK tokens that may be stuck in the contract (e.g., from failed evaluations, unused bonus pools, or unclaimed funds).

Practical Fee Guidance¶

For Requesters¶

1. Calculate max cost before submitting: call maxTotalFee(yourMaxFee) on the contract
2. Approve sufficient LINK: link.approve(contractAddress, maxTotalFee) — for ReputationAggregator, the approval must persist through finalization (minutes after request)
3. Set maxFee conservatively: Lower values filter out expensive oracles but may reduce oracle availability. Check that oracles are registered with fees below your limit.

For Oracle Operators¶

1. Set competitive fees: Lower fees increase selection probability via fee weighting
2. Fee earnings per request:
3. ReputationAggregator: fee per commit request + fee × bonusMultiplier if clustered
4. ReputationSingleton: fee as base + fee as bonus on fulfillment
5. SimpleContract: fee as base + fee as bonus on fulfillment

Cost Comparison¶