New Funder
New Funder

The funder sets up the hot allowance, deploys the smart contract, and provides key management for the receiver. In the traditional "parent-child" allowance, the parent is the funder.

New Receiver
New Receiver

The receiver gets a periodic payment on a single device and outsources all crypto complexity to the funder. In the traditional "parent-child" allowance, the child is the receiver.

Enter the 20 character code found at the end of the installation url. Only 1 install per url.

Existing Funder
Existing Funder

After deployment, the funder can manage the allowance. Existing hot allowances can be temporarily stopped, restarted or the funds can be swept back to the original funding wallet.

Existing Receiver
Existing Receiver

Once the allowance has been installed and the specified timeframe elapses, the receiver can claim the tokens. Claimed tokens can then be transferred outside the allowance.

Frequently Asked Questions
A funder can create a hot allowance for crypto beginners, family or friends. Hot allowances can be used as a crypto replacement for traditional allowances. They also make perfect gifts.
For the receiver, it's as simple as opening a link in a web browser and entering a security phrase. There's no key management, credit card information, social logins, web extensions, mobile apps, phone numbers, bank account information, etc. For the funder, the process is similar to crypto sites that connect a web wallet to sign transactions.
Hot allowances use smart contracts that timelock funds. If the receiver gets phished or compromised, timelocked funds can be swept back to the funder. In addition, hot allowances are recommended to be of low value to further reduce crypto risk.
Yes. Hotallowance.com never takes custody of any funds. The funder and receiver have control over the hot allowance. Moreover, the hot allowance is generated and stored locally on the funder and receiver devices. Hotallowance.com is a pass-thru entity that streamlines the initial handshake and provides an interface to manage the allowance.
Hot allowances have no hard dependency on hotallowance.com. The funder handles key management for the receiver and can directly interact with the allowance contract. All the data is stored locally on either the funder or receiver's device. Hotallowance.com acts as a pass-thru entity during the initial handshake.
No.
Hotallowance.com is used during the initial funder-receiver handshake as a pass-thru entity. The funder uses a security phrase to encrypt the allowance data locally on the funder's device, using the AES-GCM encryption of the Web Crypto Api. The encrypted data is passed thru hotallowance.com where it's stored locally by the receiver.
The current blockchain-token combinations include: bitcoin on the Bitcoin network, ethereum on Ethereum Mainnet, Arbitrum, Optimism, and Base, avax on Avalanche-C chain, matic on Polygon POS, and bnb on Binance Smart Chain.
An installation url can only be used 1 time. The funder should not test the installation url before giving it to the receiver because that counts as the install.
Yes, but each installation url can only be installed 1 time. So the funder will have to generate multiple installation urls using the Manage Allowances button at the top of the page. For bitcoin, it is recommended to only have 1 allowance on 1 device.
Each installation url can only be installed 1 time. If the url is lost, the funder can generate a new url for an existing allowance using the Manage Allowance button at the top of the page. Compromised allowances can be stopped and swept by the funder.
The receiver keys are generated locally on the funder's device during the allowance creation. For evm-based allowances, the keys are generated using the popular Ethers library. For bitcoin allowances, the keys are generated using the popular bitcore library. The funder stores these keys for backup, and then uses a security phrase to encrypt the allowance data. This encrypted data is then transmitted to the receiver's device where the receiver can decrypt the data using the security phrase.
The security phrase is a funder-supplied password used to encrypt the allowance. The longer and more random the security phrase, the more secure and difficult to brute force. For high valued allowances, hotallowance.com recommends 15-20 character random security phrases. The security phrase should be kept private and only shared between funder and receiver.
The funder can generate a new installation url for an existing allowance using the Manage Allowances button at the top of the page. If the allowance is compromised, the funder can sweep the funds and then create a new allowance.
If the receiver gets phished or hacked, the funder can sweep or stop the allowance. In addition, the funder can use the receiver's private keys to move funds to a new wallet.
The funder always has direct access to the receiver's funds because they have the private keys of the receiver. In addition, the funder can stop, restart, or sweep an allowance. These features can be found using the Manage Allowances button at the top of the page.
At the top of the page, there is a Manage Allowances button. Here the funder can connect their funding wallet to stop or restart the allowance. Only the funding wallet can access these features. Stopped allowances prevent the receiver from claiming tokens.
At the top of the page, there is a Manage Allowances button. Here the funder can connect their funding wallet to sweep the remaining funds from the allowance. Only the funding wallet can access this feature. Swept funds go back to the funding wallet.
The funder needs to provide initial gas for the receiver to make the first claim. If the contract wasn't deployed, the handshake would require at least 2 more steps during the setup. By deploying first, the receiver can immediately start the allowance with minimal friction.
A funder can add a deployed hot allowance to multiple devices by using the Manage Allowances button at the top of the page. To add an allowance, you use either the contract address or receiver address.
The funder's private credentials are never accessed directly by hotallowance.com. Much like with the Uniswap or Aave website, the funder connects a wallet extension like Metamask or Coinbase Wallet when deploying the hot allowance.
Hot allowances are simpler than hot wallets but they both have some similar features. Both are supposed to be limited in value and connected to the internet. Hot wallets typically require the spender to handle key management, whereas hot allowances split key management between the funder and receiver.
Hotallowance.com has inverted the social recovery process. The standard social recovery starts with a person creating a wallet and then assigning guardians to help recover the wallet. The drawback with standard social recovery is the original person must be crypto savvy. With hot allowances, the guardian creates the allowance and delivers it to the receiver.
Yes. There is a testnet link above. Choose your test blockchain, get some faucet tokens, and then create the allowance on the testnet. It's the same code used for live deployments.
The allowance receiver should ask the allowance funder for any help. The funder can ask questions on reddit for any issues.
The code is open source and MIT licensed. The smart contract is shown at the bottom of this page.
Once open source contributions have commenced, coders can submit their own allowance contracts (upgradeable allowances, renewable allowances, multi-coin allowances, stablecoin allowances, etc.) and security issues.
It's recommended that the funder only create allowances of limited value, within a $20 to $100 range. Higher valued allowances should use longer security phrases that contain random characters.
No. Be suspicious of any mobile app directing you to install a hot allowance. Bad actors may be trying phishing tactics to steal your crypto.
Hotallowance.com does not send any emails and doesn't collect email addresses. Be suspicious of any emails directing you to install a hot allowance. Bad actors may be trying phishing tactics to steal your crypto.
No.
Hotallowance.com was created by the same entity who developed the Celody and Stakedy protocols. Celody and Stakedy have been running for over 5 years without issue. No hacks. No scams. No rug pulls.

// SPDX-License-Identifier: MIT
pragma solidity 0.8.18.0;

contract Allowance {
  address payable public immutable funder;
  address payable public immutable receiver;  
  uint public immutable total;  
  uint public immutable timing;    
  uint public immutable numberSteps;  
  uint public immutable timeStampStart;  
  uint public currentStep;
  enum State { Open, Stopped, Swept, Closed }
  State public state;

  constructor(address _receiver, uint _timing, uint _numberSteps, uint _initGas) payable {
    require(address(msg.sender) != address(0),"funder address is 0x0");   
    funder = payable(msg.sender);
    require(address(_receiver) != address(0),"receiver address is 0x0");   
    require(address(_receiver) != address(funder),"receiver same as funder");   
    receiver = payable(_receiver);    
    require(msg.value > 0 && msg.value < type(uint256).max,"value not valid");    
    require(_initGas > 0 && _initGas < msg.value,"initGas not valid");        
    total = msg.value - _initGas;
    require(_numberSteps > 0 && _numberSteps < type(uint256).max,"numberSteps not valid");
    numberSteps = _numberSteps;
    require((total / numberSteps) > 0,"claim amount empty");
    // using timestamp over block.number with assumption for claim tolerance in minutes
    timeStampStart = block.timestamp;        
    require(_timing > 0 && (timeStampStart + (_timing * 60 * numberSteps)) < type(uint256).max,"timing not valid");
    timing = _timing;            
    state = State.Open;
    currentStep = 0;        
    // send initial gas to receiver for token claim
    (bool success, ) = receiver.call{value:_initGas}("");    
    require(success, "initial gas send failed");
  }
 
  function claimToken() external {
    require(msg.sender == receiver,"receiver access only");
    require(state == State.Open,"allowance not open");
    require(address(this).balance > 0,"balance empty");    
    require((timeStampStart + (timing * 60 * currentStep)) < block.timestamp,"current claim not available");
    require(currentStep < numberSteps,"all claims sent");         
    currentStep += 1;    
    uint sendValue = (total / numberSteps);    
    // check for last step - send remaining balance and close
    if (currentStep >= numberSteps) {      
      state = State.Closed;      
      sendValue = address(this).balance;      
    }      
    (bool success, ) = receiver.call{value:sendValue}("");    
    require(success, "claim send failed");    
  }

  function stopAllowance() external {
    require(msg.sender == funder,"funder access only");    
    require(state != State.Closed,"allowance already closed");
    require(state != State.Swept,"allowance already swept");
    state = State.Stopped;
  }

  function startAllowance() external {
    require(msg.sender == funder,"funder access only");    
    require(state != State.Closed,"allowance already closed");
    require(state != State.Swept,"allowance already swept");
    state = State.Open;
  }

  function sweepAllowance() external {
    require(msg.sender == funder,"funder access only");
    require(address(this).balance > 0,"balance empty");
    require(state != State.Swept,"allowance already swept");    
    state = State.Swept;    
    (bool success, ) = funder.call{value:address(this).balance}("");    
    require(success, "sweep failed");
  }            

  function getContractData() public view returns (uint _total, uint _timing, uint _numberSteps, uint _currentStep, address _receiver, State _state, uint _timeStampStart, address _funder) {
    return (total, timing, numberSteps, currentStep, receiver, state, timeStampStart, funder);
  }
}