If you need the signature to come from a key you control, use a device or a Safe. Do not use the default service key and rename it.
HardwareGnosis SafeYou control keysNot the default key
The signer is a phone approval, and the treasury policy says two people. A board minute says the company holds its own keys, and the only key in the product is the service key. A hardware device is in a drawer and has never been the signer. A Safe exists and the owners are still the service.
Those are the signs.
JIL Wallet has a default service key, and it has other ways to sign. The default key reconstructs the secret on the server. There is no user-held shard. This article is about the other ways. A hardware wallet keeps the signing key on a device you hold, and you confirm the action on that device. A Gnosis Safe keeps a list of owner addresses on an Ethereum contract, and the contract accepts a transaction only when enough of those owners have signed. In both cases the signature the chain checks is not the default service key. That is what this site means by non-custodial hardware and by Safe.
The hardware families the wallet ships adapters for are Ledger, Trezor, Keystone, BitBox02, and OneKey. Connection depends on the model: USB, Bluetooth, a QR exchange, or NFC. The adapter asks the device for an address and, when you send, for a confirmation. The confirmation happens on the device, not as a checkbox that asks the server to reconstruct the default key. If a model is not in your hand, the adapter cannot invent the signature. You need the device. Firmware, cable, and the vendor's own app are the vendor's problem as well as yours. JIL does not become the manufacturer by listing the adapter.
A Safe inside this wallet is the Safe Global contract, the same family of contracts people still call Gnosis Safe. It is not a JIL rewrite of multisig, and it is not an account on the JIL Layer-1. The JIL Layer-1 is not EVM, so an EVM multisig cannot live there. Safe is an Ethereum contract. The default chain the product talks to is Ethereum mainnet, and the Safe screen lists the chains it can actually read. Ethereum is reached by a bridge from the JIL side. Do not tell someone their Safe sits on the JIL chain. It does not.
A Safe is not treated as created because a form was submitted. The product wants bytecode at the predicted address, or an import of a Safe that already exists, with the owners read from the chain. Customer deployment is built so you broadcast the create transaction. The platform returns the factory calldata and the predicted address. A relay that pays gas is optional and is not allowed to leave the platform as the only owner. Registering a Safe whose only owner is the platform key is rejected. Owners are external addresses: a hardware wallet, another wallet you control, or a combination. A one-owner Safe is allowed for a personal setup. The copy on that setup must not be twisted into a claim that the default JIL key is a non-custodial multisig. It is not. The one owner has to be a key you control, not the reconstructed service key standing in as you.
Day to day, a Safe transaction is proposed, signed by owners, and executed when the threshold is met. Each owner signs the Safe transaction hash with their own key. The wallet can help you build the payload. It does not replace an owner signature with the default service key. If you lose every owner device, the Safe does not fall back to the server reconstructing a personal shard, because you never had that shard, and the Safe was not that key. Plan owners the way you would plan any multisig: more than one device, in more than one place, with a threshold you can still meet when one device is gone.
Protocol treasury Safes, the kind the company itself would use, are a separate admin path with a higher owner minimum. They are not the retail product. Retail and enterprise Safes are the ones a customer creates or imports. None of them makes JIL a bank, and none of them adds ACH.
Pairing a hardware wallet does not wrap your coins, and it does not insure them. Hold remains free. Wrap and unwrap remain the paid actions, in stablecoins, quoted before you confirm. A device can still sign a bad transaction if you confirm the wrong address on its screen. Read the device screen. The wallet's name for a counterparty is a convenience, not a substitute for the address the device shows.
A hardware wallet also does not move the JIL Layer-1 onto the Ethereum virtual machine. If you hold ether or an ERC-20 on Ethereum, the device is signing Ethereum transactions, and the bridge is how that value is discussed from the JIL wallet side. If you are looking at a JIL-network wrapped token, read the wrap article for what that token is. The device does not turn wrap into a deposit.
Import is free, including connecting a wallet you already use so the product can see an address you control. Connecting is not a request to paste a seed phrase into a server form. Do not type a recovery seed into a browser because a page asked. The device vendors already gave you a way to confirm addresses without revealing the seed. Use that way. The illustration at /wallet/key-recovery is not a hardware restore procedure, and social recovery at /wallet/recovery starts empty.
JIL Federation Technologies, Inc., a Delaware corporation, operates this wallet and the Layer-1 site at jilsovereign.net. getjil.com and wallet.getjil.com are the two hostnames of this one app. Payment integrity, CREB, and AVA are JIL Sovereign Technologies, Inc. at jilsovereign.com. That sister company is not the operator of getjil.com, wallet.getjil.com, or jilsovereign.net. JIL Sovereign Holdings, LLC (Wyoming) owns the intellectual property and licenses it. Holdings is not the operator of this site. No foundation operates these hosts.
Use hardware or a Safe when the sentence you need is that a key you control produced the signature. Use the default service key only when you have read what it actually does and you accept a server-reconstructed secret plus your authorization. Do not mix the sentences. A vault can hold either way. Only one of the ways is you controlling the keys.
The product screens are /wallet/hardware-wallets, /wallet/supported-hardware, and /wallet/safe. Pairing requires the physical device. Creating a Safe requires a broadcast you make, or an import of a Safe you already control, and a chain the screen can read. If the chain read fails, the Safe is not done, no matter what the button said.
No. The device holds the key and you confirm on the device. The default key is a different path. On that path the server reconstructs the signing secret, and you do not hold a shard.
Adapters are shipped for Ledger, Trezor, Keystone, BitBox02, and OneKey, over USB, Bluetooth, QR, or NFC depending on the model. You still need the physical device. Listing an adapter does not make JIL the manufacturer.
No. Safe here is the Safe Global contract on Ethereum, which people still call Gnosis Safe. The JIL Layer-1 is not EVM, so the Safe does not live on that chain. Ethereum is reached by a bridge.
No. A Safe whose only owner is the platform key is rejected. Owners are addresses you control. You broadcast the create, or you import an existing Safe after the owners are read on chain.
No. Hardware and Safe change who signs. Wrap is still an optional protection shell, not a bank deposit and not ACH. Import and hold stay free. Wrap and unwrap are paid in stablecoins.
Keep reading the related guides, or open the product. Paths: wallet.getjil.com, getjil.com, Command, Wrap, Gnosis Safe, Hardware wallets. A person can write to support@jilsovereign.com.
JIL Federation Technologies, Inc. operates getjil.com and wallet.getjil.com, the same company as the Layer-1 at jilsovereign.net.