• spread build_docker.sh logic into makefile targets
• basic ci testing for ref-farming and ref-exchange (equivalent of running cargo test in each)

successful ci tests evidence: https://github.com/fuzzylemma/ref-contracts/actions

This reduces amount of gas used and makes it compatible with Sputnik DAO UpdateRemote.

Usage from CLI:

> near repl
const fs = require('fs');
const account = await near.account("<account>");
const newContract = fs.readFileSync("<path>");
const result = account.signAndSendTransaction(
    <contract>,
    [
        nearAPI.transactions.functionCall("upgrade", newContract, 20000000000000, "0"),
    ]);

Example: https://explorer.testnet.near.org/transactions/GLwdTBVTrguY7mERg997MK5mxnfbAkVgW78sKPprhMge

The idea is to add "direct swap" approach that doesn't require deposit/withdraw in most cases. The way it will work:

• User calls ft_transfer_call on the token that wants to swap. Passing "<pool_id>:<token_out>:<min_amount>:" as msg
• Ref Exchange when receiving tokens tries to swap.
• If successfully swaps (pool is good, token out is there, min amount is met), sends token_out directly to the user
• Now if that fails (the user is not registered), on callback it records that user has them in portfolio in Ref Exhcange

Note that user still MUST be register for outgoing token ahead of time to prevent loss of funds in case they are not registered on the receiving end.

This requirement can be lifted by the caller by passing force=1, if they guarantee that user's account is registered. In case the user is not registered at the end - the funds will be returned to the exchange owner.

Proposal

Currently we only require that the first swap action amount_in is set. In the subsequent actions, however, it's more intuitive to always use the output of the previous action.

After a user is registered they should be able to deposit amounts smaller than the Account::min_storage_usage.

Right now it costs 800000000000000000000 to hold a token, but the minimum allowed to deposit is 840000000000000000000. Meaning that you have to over deposit to hold an additional token.

https://explorer.near.org/transactions/2Qcph7Kc1kC4ifshN1q6cTdhto9XRjj8G8d93CJyA2ZK

• Instant swap
  • users can swap directly using ft_transfer_call without deposit and withdraw;
  • old users's inner ref assets won't be touched in successful situation;
  • Any failure before swap completion would cause a refund of token_in token back to user's wallet;
  • Any failure after swap completion would cause token_out token into inner account or lost-found account;

This implements #24: allows to swap with a single transaction without needing to deposit / withdraw. Not even storage deposits are required for the pool, if force=1 is passed (but FE must make sure that receiver is registered in the outgoing token)

Example usage:

        contract.ft_transfer_call(
            to_va(swap()),
            to_yocto("1").into(),
            None,
            format!("{{\"force\": {}, \"actions\": [{{\"pool_id\": 0, \"token_in\": \"dai\", \"token_out\": \"eth\", \"min_amount_out\": \"1\"}}]}}", force)
        ),

Specifically for TokenReceiverMessage message parameters are:

enum TokenReceiverMessage {
    /// Alternative to deposit + execute actions call.
    Execute {
        referral_id: Option<ValidAccountId>,
        /// If force != 0, doesn't require user to even have account. In case of failure to deposit to the user's outgoing balance, tokens will be returned to the exchange and can be "saved" via governance.
        /// If force == 0, the account for this user still have been registered. If deposit of outgoing tokens will fail, it will deposit it back into the account.
        force: u8,
        /// List of sequential actions.
        actions: Vec<Action>,
    },
}

where Action is either SwapAction or any future action added there.

withdraw now returns withdrawal amount on success and 0 otherwise. This way the caller will be able to take appropriate actions on withdraw fail

withdraw_owner_token also affected in the same way

https://github.com/ref-finance/ref-contracts/blob/173cbce929a17d999c7965194bcb10b5c48deee3/README.md?plain=1#L10 link whiffs on https://docs.ref.finance/smart-contracts/ref-exchange.

I would open a PR, but unsure what the link should be updated to. Also, since there is ref-farming contract added, unsure if that should be added, along with the other test token. Assume this might want to be updated to https://guide.ref.finance/

Someone finding a bug will probably do it by looking at code on GitHub. It'd be great to also have the security process on the same repository to make it easier for them to follow the team's suggestions. For reference, yearn.finance does a great job imo by including this file which redirects to their full security process

Uniswap has a to field allowing the output tokens to be sent to an address other than the signer.

https://github.com/Uniswap/v2-core/blob/4dd59067c76dea4a0e8e4bfdda41877a6b16dedc/contracts/UniswapV2Pair.sol#L159

function swap(uint amount0Out, uint amount1Out, address to, bytes calldata data)

Ref should implement this. Suppose we have a proxy contract for swaps-

1. In EVM, we can set the the to field as the signer's address. This way the tokens directly go to the user.
2. With Ref, the proxy contract will get the output tokens. Sending the tokens to the user will require another transfer. This more more code and higher gas fee.

I'm trying to make a swap from wnear -> usdt by trading bot can you tell me what wrong here ? https://explorer.mainnet.near.org/transactions/4YDCicMAY7cFLotBA2iDH2RZU7aSbBTWpo7gn9Pj5yUn

Deployment costs per byte of code are going to be increased by a factor of ~5 with this change to NEAR protocol: https://github.com/near/nearcore/pull/6397 I believe this does not break any of your code but I want to raise awareness so that you can double-check before this is deployed.

Probably this will be included with protocol version 53, which would be released on testnet by March 23 and on mainnet by April 20.

Why am I even contacting you? To find everyone affected by this change, I listed all the indirect deployments from the past that would fail with the new cost, if all gas attachments stay the same. One deployment from v2.ref-finance.near and one from v2.ref-farming.near showed up in this list. Meaning that the mechanism used to deploy them in the past might no longer work after the new release.

I am guessing ref-exchange is deployed on v2.ref-finance.near and ref-farming on v2.ref-farming.near, right? Both seem to follow a similar pattern for upgrades. Here is the code I found for ref-farming.

https://github.com/ref-finance/ref-contracts/blob/2ecbe5c7897e9ad1783fb5378d17eab66bad7436/ref-farming/src/owner.rs#L57-L102

First of all, props to you for let attached_gas = env::prepaid_gas() - env::used_gas() - GAS_FOR_MIGRATE_CALL;. Using this dynamic gas value for the following function call means that you are probably fine with the upgrade even without any changes. (Other contracts use hard-coded values and they are breaking with the increased cost.)

What I want to tell you is that the cost to deploy ref_farming_release.wasm, or any contract of size 416KB, will go from ~6.04TGas to ~30.07Tgas. (That is pure deployment cost, without function call costs or storage costs.) After a quick scan over your code, I see nothing that would break because of this increase. But please review this for yourself.

Looking at Eugene's token factory:

https://github.com/evgenykuzyakov/token-factory/blob/15aae092a4cae928f119140632af0512448071ae/frontend/src/Tokens.js#L343

we run into an issue

Error: Querying call/ref-finance.near/get_number_of_pools,AQ4 failed: wasm execution failed with error: FunctionCallError(CompilationError(PrepareError(Deserialization))).
{
  "error": "wasm execution failed with error: FunctionCallError(CompilationError(PrepareError(Deserialization)))",
  "logs": [],
  "block_height": 59982114,
  "block_hash": "5D6urqUnTgcAxuHAqTe54qhRsffE1YS9ZUHsrvD9VuCe"
}
    at JsonRpcProvider.query (json-rpc-provider.js:80:1)
    at async ConnectedWalletAccount.viewFunction (account.js:271:1)
    at async Tokens.refreshRefPools (Tokens.js:346:1)
    at async Promise.all (:3000/index 0)
    at async Tokens.refreshRef (Tokens.js:335:1)

Running this command on NEAR CLI also throws the same error:

NEAR_ENV=mainnet near view ref-finance.near get_number_of_pools