I have a couple of questions regarding daml-finance lifecycling/elections.
-
When performing elections on a generic instrument, what’s stopping the elector from
picking whatever time they want and cheat? For example exercising an option too early.
e.g. in daml-finance/EuropeanOption.daml at e198cb715285132fb133d5462a9116532d23b1c1 · digital-asset/daml-finance · GitHub we can just pick whatever electionTime we want.
-
Who would typically provide the time events for lifecycling? The lifecycler/issuer themselves?
There seems to be no verification of who actually provides the event.
1 Like
Hi @drdo.intellecteu,
Thanks for your question and welcome to the forum.
- As you correctly point out, in the European Option example we let the investor pick the
electionTime they want. The broker then applies the election to the generic instrument in order to generate
- the new instrument version
- an effect that can be used to upgrade the investor’s holding
The reason why it is not an issue to let the investor pick the time has to do with how the option is represented in the generic instrument (which we call the contingent claims instrument representation).
Basically, the option maturity is the only valid time at which to perform an election. If you try to pick a different time in the script, processing an election will not give back any effect contract.
The story would be different in the case of an american option, which can be exercised at any time before maturity. In this case, you want to ensure that the investor cannot exercise “retroactively” (that is, create today an election dated as of yesterday). This problem is currently not addressed in Daml Finance, as it requires intimate knowledge of how you model time in your application.
- That’s right, the event contract can in principle by provided by anybody (and made visibile to the issuer / lifecycler). The current assumption is that the lifecycler is trusted with lifecycling the instrument at the correct time.
Similarly to the election, typically when lifecycling at the wrong time no effect will be returned.
I hope this provides some clarity, let me know if you have further questions!
Thank you for your answers!
-
Yes, no effect will be generated if the incorrect time is picked. The idea is that the investor can choose the maturity date for electionTime at any time.
Say I create an Election on the 1st of December (real time) but set the electionTime to the 30th of December which happens to be the maturity date of that Option.
You can then say that the lifecycler is responsible for only processing elections on maturity date to avoid this issue. But as you pointed out, this would only work in the case of a European Option.
This issue seems to make generic claims-based instruments unusable, at least when elections are involved.
As this would require very careful specific analysis of each generic instrument for safety and to understand exactly how to process elections so that no cheating can happen, defeating the whole point of the instruments using generic claims.
-
What is the purpose of Time events and the DateClock template?
My idea at first was that you would have a trusted third party providing clocking events but it seems that this is not the case and the lifecycler can just use whatever time event they want. In this case I don’t understand why have this at all. Why not just have a time parameter when lifeycling, similar to the electionTime on elections.
Thanks for your feedback @drdo.intellecteu, this is valuable!
On 1, I don’t see it too much as a problem if on the 1st of December (real time) an investor puts forward an election for the 30th of December. I think that the opposite would be more dangerous.
That said, I agree with you that you generally want some guarantee that the electionTime is close to real business time (or to ensure that electionTime >= real business time).
There are a few potential approaches to achieve that, depending on how you define “real business time”.
If ledger time is your metric for business time, you could e.g.
-
as an issuer, look at the timestamp of the transaction that created the Election and compare it to electionTime. Only process those elections that you deem valid, according to some pre-defined tolerance
-
provide a custom implementation of the ElectionFactory where the electionTime is checked against getTime
Alternatively, the current business time has to be provided by a trusted party as a contract (e.g. using a DateClock contract).
- in this case, the election factory would need to interact with the current time contract in order to ensure the election is valid
I appreciate that the financial library doesn’t provide much at the moment in order to perform this sanity check on election. For this reason, we are planning to add a TimeObservable back as an input to Exercisable.ApplyElection.
On your second point, there are a few possible uses for the DateClock template and time events.
-
business time + clocking events provided by a trusted party (the lifecycler, which we assume is not cheating, would source clocking events from this trusted party)
-
time synchronization among parties : in order to perform lifecycle, you might need a number of observation contracts to be up to date (e.g. for equity or rate fixings), which could in principle be sourced by multiple providers. The DateClock can be used to signal when data for the corresponding date has been added to the observation contract and is available for consumption
Finally, let me make a suggestion on how to get rid of the assumption that the lifecycler must not be cheating (we have an open issue to track that):
a custom version of the lifecycle rule contract for the instrument can store an additional map observable label -> trusted provider against which to compare the signatory of the provided Observations.
While we strive to provide a solid and complete library to cover most scenarios, it is likely that some customer use-cases do require this sort of custom modifications of (hopefully tiny) parts of Daml Finance.
I hope this helps!
Matteo
1 Like