tx-sender) into the Heirloom vault contract, increasing the vault’s sbtc-balance. The vault must exist and must not be distributed. The calling address must be the vault owner because only the owner’s vault entry is looked up via tx-sender.
Function signature
Parameters
The amount of sBTC to deposit, denominated in satoshis (the smallest sBTC unit). sBTC has 8 decimal places.
Amount must be greater than zero.
| Human amount | Satoshi value |
|---|---|
| 0.001 BTC | u100000 |
| 0.01 BTC | u1000000 |
| 0.1 BTC | u10000000 |
| 1 BTC | u100000000 |
Return value
Returns
(ok true) on success. The vault’s sbtc-balance is incremented by amount.Returns
(err uint) on failure. See error codes below.Error codes
| Code | Constant | When returned |
|---|---|---|
| u103 | ERR-VAULT-NOT-FOUND | The calling address has no vault |
| u110 | ERR-VAULT-DISTRIBUTED | The vault has been distributed or cancelled |
| u113 | ERR-NO-BALANCE | amount is zero |
How the transfer works
The function uses Clarity 4’srestrict-assets? with with-ft to enforce the exact transfer amount as a post-condition within the contract itself. This prevents callers from submitting transactions that transfer a different amount than the deposit function expects:
ST1F7QA2MDF17S807EPA36TSS8AMEFY4KA9TVGWXT.sbtc-token. Tokens are transferred to current-contract — the vault contract’s own principal.
JavaScript example
postConditionMode: 'allow' is used to avoid post-condition conflicts. Because the contract enforces the exact transfer amount internally via restrict-assets?, external post-conditions are redundant. Using allow mode prevents wallet-level post-condition failures if the transaction errors before reaching restrict-assets? (for example, when ERR-VAULT-NOT-FOUND is returned).