# How can an observer verify he has a contract

**URL:** <https://forum.canton.network/t/how-can-an-observer-verify-he-has-a-contract/4224>\
**Category:** App Development\
**Tags:** daml\
**Created:** [March 29, 2022, 10:52am UTC](https://forum.canton.network/t/how-can-an-observer-verify-he-has-a-contract/4224 "2022-03-29T10:52:55Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![cohen.avraham](https://avatars.discourse-cdn.com/v4/letter/c/a87d85/32.png) [@cohen.avraham](https://forum.canton.network/u/cohen.avraham)\
**Post date:** [March 29, 2022, 10:52am UTC](https://forum.canton.network/t/how-can-an-observer-verify-he-has-a-contract/4224/1 "2022-03-29T10:52:56Z")

</div>

G-d willing

Hello,  
assuming the following template

```haskell
template Agreement
  with 
    sideA: Party
    sideB: Party
    identifier: Text
  where
    signatory sideA
    observer sideB
    key (sideA, sideB, identifier): (Party, Party, Text)
    maintainer key._1

```

While sideA can do lookupByKey and then, in case there is a contract, he can do fetchByKey, how can sideB know if sideA created an Agreement contract for him without having a chance to get an exception?  
If executing lookupByKey, it won’t return any contract since sideB is not a signatory. And executing “fetchByKey” alone, can fail if there is no contract.

So, how can I verify there is a contract before doing “fetchByKey”?

Thanks

---

<div class="post-metadata">

**Author:** ![Gary\_Verhaegen](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/gary_verhaegen/32/81_2.png) [@Gary\_Verhaegen](https://forum.canton.network/u/Gary_Verhaegen)\
**Post date:** [March 29, 2022, 3:44pm UTC](https://forum.canton.network/t/how-can-an-observer-verify-he-has-a-contract/4224/2 "2022-03-29T15:44:55Z")

</div>

The issue with `visibleByKey`/`lookupByKey` you’ll hit here is not that `sideB` is not a signatory, per se, but that at the point of querying they do not have the authorization of all the maintainers. Now, you do need to be a signatory to be a maintainer, but you don’t need to be a signatory to _have the authority_ of the maintainers.

For example:

```haskell
module Main where

import Daml.Script

template Agreement
  with 
    sideA: Party
    sideB: Party
    identifier: Text
  where
    signatory sideA
    observer sideB
    key (sideA, sideB, identifier): (Party, Party, Text)
    maintainer key._1

template TryVisible
  with
    submitter: Party
    requester: Party
  where
    signatory submitter
    observer requester
    preconsuming choice VisibleKey: Bool
      with
        key: (Party, Party, Text)
      controller requester
      do
        visibleByKey @Agreement key

setup : Script ()
setup = script do
  alice <- allocatePartyWithHint "Alice" (PartyIdHint "Alice")
  bob <- allocatePartyWithHint "Bob" (PartyIdHint "Bob")
  aliceId <- validateUserId "alice"
  bobId <- validateUserId "bob"
  createUser (User aliceId (Some alice)) [CanActAs alice]
  createUser (User bobId (Some bob)) [CanActAs bob]

  ag_alice <- submit alice do
    createCmd Agreement with
      sideA = alice
      sideB = bob
      identifier = "1"
  
  q <- submit alice do
    createCmd (TryVisible alice bob)
  bob_can_see <- submit bob do
    exerciseCmd q (VisibleKey (alice, bob, "1"))

  assert bob_can_see

  pure ()

```

---

<div class="post-metadata">

**Author:** ![cohen.avraham](https://avatars.discourse-cdn.com/v4/letter/c/a87d85/32.png) [@cohen.avraham](https://forum.canton.network/u/cohen.avraham)\
**Post date:** [March 30, 2022, 9:52am UTC](https://forum.canton.network/t/how-can-an-observer-verify-he-has-a-contract/4224/3 "2022-03-30T09:52:18Z")

</div>

> [@Gary\_Verhaegen](#):
>
> ```haskell
> q <- submit alice do
> createCmd (TryVisible alice bob)
> bob_can_see <- submit bob do
> exerciseCmd q (VisibleKey (alice, bob, "1"))
> 
> ```

Thanks @Gary_Verhaegen for the detailed answer with the example.  
In your example, in order for Bob to view the agreement, he has to know the contract id of the “TryVisible” contract.  
Well, that brings the issue back from a different angle… how can bob knows that there is a “TryVisible” contract?

The only way I can think of resolving it is by adding a new type of contract that defines the relationship between him and Alice, and in that contract, Alice will store the contract id of the Agreement. And in that contract, Bob will be the maintainer. But I find this approach kind of extravagant.  
Creating a new contract in order to be aware of another, sounds unright to me… if there is nothing else than that, I won’t have any other choice but to follow this approach.

---

<div class="post-metadata">

**Author:** ![Gary\_Verhaegen](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/gary_verhaegen/32/81_2.png) [@Gary\_Verhaegen](https://forum.canton.network/u/Gary_Verhaegen)\
**Post date:** [March 30, 2022, 10:11am UTC](https://forum.canton.network/t/how-can-an-observer-verify-he-has-a-contract/4224/4 "2022-03-30T10:11:58Z")

</div>

Right, so there are two different issues here, and I got confused.

On the one hand, there is the question of how does Bob, the “person” behind the Party and the entity sending gRPC requests to create contracts and execute choices, know about contracts they’re an observer on.

On the other hand, there is the question of how, from Daml code, the `bob` party can fetch a contract by key when they are a non-signatory observer of said contract.

Hopefully my previous message answers the second question, so I’ll focus on the first one now. But please do not hesitate to ask follow-up questions on both.

As an entity interacting with the ledger, Bob needs to be using the gRPC API. (For our purposes here, the HTTP JSON API, if used, is transparent.) The gRPC API, broadly speaking, lets Bob do two things:

1. Act on the ledger: send Create and Exercise commands to “make things happen”, or, from another perspective, “record” things on the ledger.
2. Subscribe to the ledger to get notified when other people do things.

That second point is very important. The ledger is a synchronization point between multiple parties and, when you create a contract, you do want to know when someone else exercises a choice on your contracts. Similarly, you also want to know when someone else creates a contract you’re an observer on.

The `Script` mechanics you can use in the IDE accurately reflects point 1, but sort of sidesteps point 2 completely. In a real Daml system, point 2 is essential and every entity involved with a given Daml ledger will be listening to ledger updates in some form.

Exactly how you subscribe to notifications will depend on what your program is and does, but any application (or UI, as in the [getting started](https://docs.daml.com/getting-started/index.html) example app) that interacts with a Daml ledger will have some form of subscription to change notifications.

---

<div class="post-metadata">

**Author:** ![cohen.avraham](https://avatars.discourse-cdn.com/v4/letter/c/a87d85/32.png) [@cohen.avraham](https://forum.canton.network/u/cohen.avraham)\
**Post date:** [March 30, 2022, 11:01am UTC](https://forum.canton.network/t/how-can-an-observer-verify-he-has-a-contract/4224/5 "2022-03-30T11:01:51Z")

</div>

@Gary_Verhaegen I truly appreciate your detailed answers.

Basically, I am trying to do it only using the Daml code, and I will explain why.  
Let’s say Alice is a seller, Bob is a broker, while Charlie and David are potential buyers.  
Alice is telling Bob that she wants to sell a product she is having, and notifying Bob she is publishing a bid for it.  
For that, Bob needs to notify all of his buyers about the bid. Note: Alice is not aware of Bob’s buyers.  
Bob’s job is to pass Alice all of the offers he received from his buyers without any filtering.  
So I don’t want the UI to go through all the offers (one by one) and send them to Alice. In this approach, a bug can cause an offer not to be sent to Alice. In addition, the UI cannot be a part of the business logic.

Hence, I want to exercise a choice where all of the buyers’ offers will be sent to Alice.  
I hope this explains what I need to do, and that there is a nice solution for it.

---

<div class="post-metadata">

**Author:** ![Gary\_Verhaegen](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/gary_verhaegen/32/81_2.png) [@Gary\_Verhaegen](https://forum.canton.network/u/Gary_Verhaegen)\
**Post date:** [March 30, 2022, 12:13pm UTC](https://forum.canton.network/t/how-can-an-observer-verify-he-has-a-contract/4224/6 "2022-03-30T12:13:57Z")

</div>

The details will depend a lot on exactly who can know what in your model, but the basic issue here is that there is no query mechanism in choices.

So you have to work around that, for example by having a single contract that keeps track of all the offers, and that Alice would be an observer on.

In short, discovering contracts should be done through the observer mechanism, as explained in my previous post. That leads to the next problem, which is the discovery of party IDs, and that one is simply not covered within the ledger. We assume parties are somehow communicated off band: with all of its privacy features, Daml is designed for people who _already know who they want to talk to_.

Things like open chat rooms (or, in this case, bids) that anyone can join are thus a bit tricky to model in a Daml system (though not impossible).

---

<div class="post-metadata">

**Author:** ![cohen.avraham](https://avatars.discourse-cdn.com/v4/letter/c/a87d85/32.png) [@cohen.avraham](https://forum.canton.network/u/cohen.avraham)\
**Post date:** [March 30, 2022, 12:36pm UTC](https://forum.canton.network/t/how-can-an-observer-verify-he-has-a-contract/4224/7 "2022-03-30T12:36:21Z")

</div>

Thank you very much @Gary_Verhaegen  
So I guess my own solution is to have another template that will store the contract id of the agreement contract.