<p>I think you must be using the datatype in some way if you're doing <em>anything</em> with this type.</p>
<p>However, perhaps you just don't care about the <code>Nat</code> index. It would be nice to be able to ignore this, but how would you communicate this to the compiler? You really want to say &quot;don't use this definition of the type, use this <em>other</em> definition of the type that doesn't have this parameter&quot;. But the simplest way to do that is just to: use the other definition of the type, which is what you're doing.</p>
<p>Possibly we could ignore phantom type parameters in general, but we'd have to be very careful that this didn't result in ill-typed Plutus IR. Generally throwing away bits of type information and hoping it will be okay is risky!</p>

CC BY-SA 4.0
2022-04-27T10:18:12.797Z
Okay. Exchanging types sounds not pretty and a takeaway would be to use less-fancy types if we want to re-use them in plutus. We will stay with the conversion or move to a simpler type which we could re-use between off- and on-chain. Thanks.
Sebastian Nagel
CC BY-SA 4.0
2022-04-27T10:13:45.670Z
2022-04-27T10:13:45.670Z
michaelpj
<p>I'm having a <code>newtype VerificationKey = HydraVerificationKey (VerKeyDSIGN Ed25519DSIGN)</code> and I would love to be able to use that type directly in our plutus scripts. While I can implement <code>PlutusTx.ToData</code> et al for it and satisfy ghc, I get runtime errors like</p>
<pre><code>Benchmark tx-cost: RUNNING...
tx-cost: Error: Unsupported feature: Kind: GHC.Types.Nat
Context: Compiling definition of: Hydra.Contract.HeadTokens.validateTokensMinting
Context: Compiling definition of: Hydra.Contract.HeadTokens.validate
Context: Compiling expr at &quot;hydra-plutus-0.5.0-inplace:Hydra.Contract.HeadTokens:(120,8)-(120,101)&quot;
</code></pre>
<p>Likely because the <code>VerKeyDSIGN</code> (from <code>Cardano.Crypto.Class</code>) is implemented using some reflection on key size using Nat, as it's defined:</p>
<pre><code>newtype VerKeyDSIGN Ed25519DSIGN = VerKeyEd25519DSIGN (PinnedSizedBytes (SizeVerKeyDSIGN Ed25519DSIGN))

newtype PinnedSizedBytes (n :: Nat) = PSB ByteArray
</code></pre>
<p>But we would not want to be using <code>HydraVerificationKey</code> nor the underlying <code>VerKeyEd25519DSIGN</code> data constructors, but only functions
dealing with the <code>newtype VerificationKey</code> . Is this even possible?</p>
<p>Right now we are converting our off-chain keys to another, simpler type <code>newtype Party = UnsafeParty {vkey :: BuiltinByteString}</code>, but thought we could avoid that conversion.</p>

<plutus><plutustx>
Is it possible to not compile data constructors with plutus-tx?
# Is it possible to not compile data constructors with plutus-tx?

(Asked by: username_0 on 2022-04-27)

I'm having a newtype VerificationKey = HydraVerificationKey (VerKeyDSIGN Ed25519DSIGN) and I would love to be able to use that type directly in our plutus scripts. While I can implement PlutusTx.ToData et al for it and satisfy ghc, I get runtime errors like
Benchmark tx-cost: RUNNING...
tx-cost: Error: Unsupported feature: Kind: GHC.Types.Nat
Context: Compiling definition of: Hydra.Contract.HeadTokens.validateTokensMinting
Context: Compiling definition of: Hydra.Contract.HeadTokens.validate
Context: Compiling expr at "hydra-plutus-0.5.0-inplace:Hydra.Contract.HeadTokens:(120,8)-(120,101)"

Likely because the VerKeyDSIGN (from Cardano.Crypto.Class) is implemented using some reflection on key size using Nat, as it's defined:
newtype VerKeyDSIGN Ed25519DSIGN = VerKeyEd25519DSIGN (PinnedSizedBytes (SizeVerKeyDSIGN Ed25519DSIGN))

newtype PinnedSizedBytes (n :: Nat) = PSB ByteArray

But we would not want to be using HydraVerificationKey nor the underlying VerKeyEd25519DSIGN data constructors, but only functions
dealing with the newtype VerificationKey . Is this even possible?
Right now we are converting our off-chain keys to another, simpler type newtype Party = UnsafeParty {vkey :: BuiltinByteString}, but thought we could avoid that conversion.

**Tags:** plutus, plutustx

---

## 1 answers

### Answer by username_1 on 2022-04-27. Score: 3 | Accepted answer

I think you must be using the datatype in some way if you're doing *anything* with this type.

However, perhaps you just don't care about the `Nat` index. It would be nice to be able to ignore this, but how would you communicate this to the compiler? You really want to say "don't use this definition of the type, use this *other* definition of the type that doesn't have this parameter". But the simplest way to do that is just to: use the other definition of the type, which is what you're doing.

Possibly we could ignore phantom type parameters in general, but we'd have to be very careful that this didn't result in ill-typed Plutus IR. Generally throwing away bits of type information and hoping it will be okay is risky!

> **Comments:**
> **username_0**: Okay. Exchanging types sounds not pretty and a takeaway would be to use less-fancy types if we want to re-use them in plutus. We will stay with the conversion or move to a simpler type which we could re-use between off- and on-chain. Thanks.  

---

