com.r3corda.core.contracts / NamedByHash

# NamedByHash

`interface NamedByHash`

Implemented by anything that can be named by a secure hash value (e.g. transactions, attachments).

### Properties

id | `abstract val id: SecureHash`

### Inheritors

Attachment | `interface Attachment : NamedByHash` An attachment is a ZIP (or an optionally signed JAR) that contains one or more files. Attachments are meant to contain public static data which can be referenced from transactions and utilised from contracts. Good examples of how attachments are meant to be used include:
BaseTransaction | `abstract class BaseTransaction : NamedByHash` An abstract class defining fields shared by all transaction types in the system.
SignaturesMissingException | `class SignaturesMissingException : NamedByHash, SignatureException`
SignedTransaction | `data class SignedTransaction : NamedByHash` SignedTransaction wraps a serialized WireTransaction. It contains one or more signatures, each one for a public key that is mentioned inside a transaction command. SignedTransaction is the top level transaction type and the type most frequently passed around the network and stored. The identity of a transaction is the hash of a WireTransaction, therefore if you are storing data keyed by WT hash be aware that multiple different STs may map to the same key (and they could be different in important ways, like validity). The signatures on a SignedTransaction might be invalid or missing: the type does not imply validity. A transaction ID should be the hash of the WireTransaction Merkle tree root. Thus adding or removing a signature does not change it.