12.28. DD 28: Deposit Policy Extensions¶
This is Work-In-Progress.
We will propose here a plugable mechanism in the exchange to support deposits with associated policy. An exchange can enable support for such policies via configuration.
The inital set of policy extensions that an exchange might provide consists of
- Merchant refunds
Merchant can grant customers refundable payments. In this case, the amount of the deposit is put into escrow by the exchange for a certain period until which the customer can claim a refund.
- Escrowed payments
A trustor puts coins into escrow with the exchange. It can be claimed by a beneficiary until a certain deadline, when the claim is signed by both, the beneficiary’s and the trustor’s keys.
- Brandt-Vickrey auctions
A bidder puts coins into escrow with the exhange in order to participate in an Brandt-Vickrey auction. The deposit confirmation is proof to the seller for the escrow and contains a hash of the auction meta-data and a deadline. After successfull execution of the auction, the seller provides a valid transcript to the exchange from which the exchange learns which bidder(s) won the auction for which prices. It then transfers the amounts from the winners’ coins to the seller. In case of a timeout and for all losing bidders, the coins can be refreshed.
The policies shall be implemented as extensions to the exchange (see DD 06: Extensions for GNU Taler).
12.28.3. Background and Requirements¶
12.28.4. Proposed Solution¶
C-structs for policy extensions (esp. the handlers)
Naming conventions for policy extensions
Deadlines and -handling
Typical choreography of a deposit with policy and its fulfillment
policy_hash_codes in table
policy_fulfillments is a binary
blob that consists of the concatenation of the sorted
policy_details.policy_hash_code entries from all policies that are fulfilled by
22.214.171.124. Policy Fulfillment States¶
The fulfillment of a policy can be in one of the following five states:
The policy is funded and ready. The exchange is waiting for a proof of fulfillment to arrive before the deadline.
The policy lacks funding, that is
commitment, but has otherwise been accepted. Funding can be continued by calling
/batch-depositwith more coins and the same policy details.
The policy is provably fulfilled. The amounts for payout, fees and refresh are transfered/can be claimed. Note that a policy fulfillment handler can change the values for the amounts for payout, fees and refresh.
The policy has timed out. The amounts for payout and refresh are transfered/can be claimed.
The policy is in an failure state. Payouts and refreshes are blocked, timeouts are ignored.
The following invariants need to be fulfilled and be checked by the auditor:
The fulfillment state of a policy is Insufficient IF AND ONLY IF the amount in
policy_details.commitmentis equal or larger than the amount in
The sum of amounts in
policy_details.transferableMUST be equal or less than the amount in
The amount in
policy_details.accumulated_totalMUST be equal to the total sum of contributions of the individual coins of the deposits that reference this policy.
Each hash code encoded in
policy_fulfillments.policy_hash_codesMUST refer to an existing
.fulfillment_idMUST point to the same
Conversely: If a
policy_details.fulfillment_idpoints to an entry in
policy_details.policy_hash_codeMUST be present in that entry’s
126.96.36.199. Discussion / Q&A¶
(This should be filled in with results from discussions on mailing lists / personal communication.)