Operational security

This page describes how Helva operates the beneficiary contract, the keys, and the checks around your Letter of Credit. The short version is Security at a glance.

Some operational details are marked [redacted]. We publish the control, and withhold only what would help someone time or locate an attack: physical sites beyond the sentence below, monitoring endpoints, exact alert timings, payment-rail timings, and internal log locations.

Beneficiary contract and roles

The published beneficiary is an Anvil LOCBeneficiary contract operated by Helva. It is upgradeable. Only the 2-of-3 admin Safe can upgrade it. The published address does not change when the code behind it is upgraded.

Routine redemptions cannot pick a destination. The contract sends them to Helva’s redemption Safe. A redemption to any other destination is a separate two-person action.

Component	Composition	What it controls
Beneficiary contract (LOCBeneficiary)	Upgradeable contract. This is the published Letter of Credit beneficiary.	All of Helva’s Letter of Credit actions go through it. Routine redemptions land only in the redemption Safe.
Admin Safe	2-of-3. Three hardware-wallet keys, one of them a cold recovery key that is not used day to day.	Upgrades, role changes, and any redemption to a chosen destination.
Redemption Safe	2-of-2.	Where routine redemptions land. Moving funds out of this Safe needs both signers.
Operator keys	Two operators. Each key is on a hardware wallet.	Day-to-day cancel and redeem.

Role	Who holds it	What it can do
Admin	Admin Safe	Grant and revoke roles. Upgrade control sits with this Safe.
Redeemer admin	Admin Safe	Redeem to a destination the caller chooses. Not used for routine redemptions.
Redeemer	Each operator	Redeem. The contract chooses the destination. The caller cannot.
Canceler	Each operator	Cancel a Letter of Credit. Collateral returns to the borrower.
Redeem router	Nobody, until the admin Safe grants it for that action and revokes it after	Change where redemptions land.
Transferor	Nobody, until the admin Safe grants it for that action and revokes it after	Sweep tokens or ETH stranded in the contract.
Reader admin	Each operator	Let an address see Letters of Credit in Anvil’s tools. Cannot move funds.

The three wallets involved in administration and recovery (the 2-of-3 admin Safe’s keys) are backed up in three different locations in Switzerland.

Two-tier signing

Two people must sign when value leaves Helva’s Safes, or when policy changes. That includes moving funds out of the redemption Safe, changing roles, upgrading the contract, redeeming to a chosen destination, changing the redemption destination, and sweeping stranded funds.

One operator can redeem or cancel, after a mandatory checklist. A redeem from that operator still lands in Helva’s redemption Safe, because the contract enforces the destination. A cancel only returns collateral to the borrower. A single operator cannot point a routine redemption at an outside address, and cannot upgrade the contract.

A hardware wallet holds the key offline and shows the transaction on its own screen. Operators sign on those devices.

Deployment and handover

Before the beneficiary address is published, control of upgrades and admin roles is handed to the admin Safe. Both operators independently verify that handover: who holds each role, where redemptions land, and that upgrade control sits with the admin Safe. The address is published only after that check.

The contract is set up in the same deployment that creates it, so setup cannot be front-run, and the deployment is registered with Anvil.

Pre-signing verification

Every operator signature follows the same ritual.

1. Read the Letter of Credit from the chain, not from the app. The endpoints used for that read are [redacted]. Check that it exists, that the beneficiary is Helva’s contract, and that the amounts and expiry match the loan. For a redeem, also read the destination and confirm it is Helva’s redemption Safe.
2. Write those fields on paper from the chain read, not from the app.
3. At signing, compare the hardware-wallet screen with the paper note, field by field. If the device shows raw transaction data, decode it independently and compare that with the paper note before sending. On a two-person action, each signer does this alone. They do not share notes beforehand. A mismatch is the alarm.
4. A cancel is signed only after written confirmation that the repayment is final.

Why we don’t use signed cancel authorizations

A signed cancel authorization would have no expiry and no conditions. Anyone who later obtained it could release collateral. Helva does not issue them.

Cancels are direct calls by an operator with the canceler role, and only after repayment is final. See Repaying your loan.

Key generation and backup

• Each owner key is generated on the hardware wallet, not on a computer. Firmware is checked before first use.
• The recovery key is generated in one ceremony with both operators present. The device is wiped after the seed is backed up. It is not a day-to-day device.
• Backups are metal, not paper, except as a short-term measure. Seeds are not photographed, typed, or stored in the cloud. Each backup is checksum-checked when it is made.
• Where the hardware wallet supports SLIP-39, the seed is split into shares, so one share is not the whole seed.
• No location holds two owner seeds. No location holds a device together with its own seed.
• The three wallets involved in administration and recovery (the 2-of-3 admin Safe’s keys) are backed up in three different locations in Switzerland. Further location detail is [redacted].
• Once a year, Helva runs a recovery drill: the recovery seed is restored on a wiped device and checked against the expected address.

If a key is lost, the remaining signers replace it. A suspected compromise is treated immediately, before the next redemption, and Helva reviews role changes, destination changes, and Safe history for unexpected activity. If an operator is unavailable, the other operator and the recovery key still reach the 2-of-3 quorum. How the recovery key is accessed in that case is [redacted].

A single lost key does not freeze operations. The admin Safe is 2-of-3, so the other two keys can replace the lost one. Funds already sitting in the 2-of-2 redemption Safe need both of those signers to move out. If one of those keys is lost, the admin Safe can point later redemptions at a new Safe.

Owner and role changes are announced in the changelog on Security at a glance. The published beneficiary address does not change.

Monitoring

Helva’s operating rules require alerts ahead of every Letter of Credit expiry, plus watches on position health, Letter of Credit events, Anvil governance, and Safe or role changes. Those watches call the contracts directly. They do not depend on a website staying up. Exact alert timings are [redacted]. Monitoring endpoints are [redacted].

Anvil also allows anyone to liquidate an unhealthy position if a watch fails. Proceeds of that path still go to the Letter of Credit’s beneficiary. See What happens if….

Loan acceptance checks

Before a loan is activated, Helva reads the Letter of Credit from the chain, not from the app:

• It exists.
• The beneficiary is Helva’s beneficiary contract.
• The credit asset and the credit amount match the loan, including the FX buffer on a CHF loan.
• Expiration is loan maturity plus 5 days.
• The creator is the borrower’s registered wallet.

Any mismatch: the loan is not activated. See Verify your transactions.

Collateral release

Collateral is released only after your payment is final. Per-rail timings are [redacted].

Review cadence

When	What is reviewed
Before go-live	Handover of the beneficiary contract, including the independent check, and a dry run of create, verify, redeem, and cancel
Quarterly	Admin Safe signers, the role table, where redemptions land, and outstanding allowances
Annually	Recovery-key drill, and this setup against the current Anvil contracts
On every Anvil governance execution	Redeem, cancel, and convert behavior, plus the role table and redemption destination

Team background

The founding team has 10+ years each in crypto, including leading roles at Swiss crypto banks, funds, custodians, and custody-technology providers. See helva.finance/team.