Fees and Incentives
Amish uses two fee categories: execution fees that compensate transaction submitters, and protocol fees that accrue to the protocol from interest. For capital efficiency, see Capital Efficiency. For competitive positioning, see Market Position.
Execution fees
Users create intents by signing messages off-chain - no gas required. When execution occurs on-chain, the transaction submitter pays gas and receives an execution fee. The TransferExecutionIntent struct includes executionFeeToken and executionFeeAmount fields. The fee transfers to whoever submits the transaction.
Execution fees compensate submitters for gas costs and execution service. They are not protocol revenue - they flow to third-party executors who compete to process transactions.
How execution fees work
When a user creates an intent, they specify an execution fee as part of the signed message:
interface TransferExecutionIntent {
// ... other fields
executionFeeToken: string // Token address for fee payment
executionFeeAmount: string // Fee amount in token units
}Any address can submit the transaction that executes the intent. The submitter pays gas costs and receives the specified execution fee. This creates a market for execution services - submitters compete on reliability and speed.
Fee economics
Execution fees typically exceed gas costs, providing margin for submitters. Users set fees high enough to attract execution but not higher than necessary. In practice, competitive execution markets converge toward gas cost plus a small margin.
The protocol does not capture execution fees. All execution fees flow to whoever submits the transaction.
Protocol fees
Protocol fee collection is not currently implemented. The design intent is described below for completeness.
Intended design
The protocol fee is expressed as a percentage of interest accrued on each loan. Collection occurs during repayment or redemption - not upfront.
Repayment waterfall:
Borrower repays principal plus interest
Interest accrued is calculated
Protocol fee is computed as a percentage of interest
Protocol fee is deducted from interest
Remaining interest plus principal flows to debt token holders
Example with a 10% protocol fee on a $10,000 loan at 8% APR for 30 days:
Interest accrued: $65.75
Protocol fee (10% of interest): $6.58
Interest to lender: $59.17
Principal to lender: $10,000
Where fees are not taken
Not from collateral. Protocol fees are taken from interest, not from collateral. If a loan defaults or liquidates, the protocol does not skim from collateral proceeds before lenders receive their share.
Not from principal. Principal flows through the protocol without fee deduction. Fees apply only to the interest component.
Not at origination. There is no upfront origination fee. Fees accrue only when interest is realized.
Alternative fee approaches (not implemented)
Other fee mechanisms are possible but not currently planned:
Origination fees taken at loan creation
Liquidation fees taken from collateral during liquidations
Spread fees on cross-chain proof verification
These approaches are neither implemented nor decided. The current design focuses on interest-based protocol fees.
Match-time terms and selections
Loan parameters are specified at the intent layer and resolved when a match forms.
Terms agreed at match time (deal-level):
LTV (loan-to-value ratio)
APR (interest rate)
Duration
Liquidation parameters
Selections and constraints resolved at match time (intent-defined, match must satisfy):
Collateral asset
Principal asset
Collateral chain and principal chain (for cross-chain settlement)
Price source selection (oracle-based or HDP-derived computation)
Interest rate strategy selection (fixed default, variable optional)
For matching mechanics, see Intent-Based Lending.
Last updated