# Proposal bond in pallet-treasury

``````/// Fraction of a proposal's value that should be bonded in order to place the proposal.
/// An accepted proposal gets these back. A rejected proposal does not.
#[pallet::constant]
type ProposalBond: Get<Permill>;

/// Minimum amount of funds that should be placed in a deposit for making a proposal.
#[pallet::constant]
type ProposalBondMinimum: Get<BalanceOf<Self, I>>;
``````

In treasury configuration, If I am creating a proposal what should be the bond amount? Should it be the `min(ProposalBond, ProposalBondMinimum)` where `ProposalBond` is defined as some percentage of the requested amount?

## 1 Answer

The bond amount should be at least some minimum value, or a percentage of the value requested to be spent. This will be reimbursed if spending proposal succeeds, and burnt otherwise.

This is calculated in the `calculate_bond` function like this:

``````    /// The needed bond for a proposal whose spend is `value`.
fn calculate_bond(value: BalanceOf<T, I>) -> BalanceOf<T, I> {
let mut r = T::ProposalBondMinimum::get().max(T::ProposalBond::get() * value);
if let Some(m) = T::ProposalBondMaximum::get() {
r = r.min(m);
}
r
}
``````

See the above code snippet in context here.

The Treasury pallet is designed to ensure that at least the minimum bond is deposited in the case where `value`*`ProposalBond` is less than that. Optionally, you can also define a maximum bond value using the `ProposalBondMaximum` constant which sets an upper bound for the deposit of large spending proposals. AFAIK this upper bound was introduced because the Polkadot community wanted to see more long term proposals with higher amounts. With no upper bound to the proposal bond, high spending proposers would need to bond proportionally high deposits for extended periods of time which isn't very practical.

Look at the different values set in Kusama and Polkadot:

In Kusama (v0.9.40):

In Polkadot (v0.9.36):

Of course the units of value in the real world don't hold the same economic worth, however readers can draw their own conclusions about the real world implications of these values (e.g. more or less capital needed as minimum bond; the ratio between the max and min values; the percentage of the value to calculate the default bond).

When making decisions about what values to have here, it's useful to look at what other production chains have set for these constants, to base your decisions on production tested runtimes but also to think of your end-users such as what protective measures are in place, bearing in mind that the entire reason for these values is to discourage bad actors using economics while also keeping an eye to user experience.