# Class BSV::Wallet::Store::Models::Output <a id="class-BSV-Wallet-Store-Models-Output"></a>

**Inherits:** `Sequel::Model`

## Attributes
### `expected_root_script` [RW] <a id="attribute-c-expected_root_script"></a> <a id="expected_root_script-class_method"></a>
Returns the value of attribute expected_root_script.

## Public Instance Methods
### `basket()` <a id="method-i-basket"></a> <a id="basket-instance_method"></a>
Not documented.

### `spendable?()` <a id="method-i-spendable-3F"></a> <a id="spendable?-instance_method"></a>
- **@return** [Boolean]

### `validate()` <a id="method-i-validate"></a> <a id="validate-instance_method"></a>
Application-layer mirror of the `outputs` table's two structural CHECKs
(`controls_all_or_nothing` and `spendable_recoverable`, HLR #467 /
<code>intent-and-outcomes.md</code>). The DB enforces the same rules — these
validators surface failures as field-level errors before the DB rejects, so
callers see clean app-level messages rather than raw
`CheckConstraintViolation` noise.

Sequel calls <code>#save</code> which raises
<code>Sequel::ValidationFailed</code> when `errors` is non-empty; `Store`
wraps that and re-raises as <code>BSV::Wallet::InvalidParameterError</code> at
the insertion boundary.