Description

There are two functions, namely create() and deploy(), available in both the FixedTerm and FixedExpiry tellers, which do not check whether the expiry_ has passed the current block.timestamp or not.

In the case of the deploy function, this implies that a bond token can be created for a past block.timestamp, which could jeopardize the concept of bond tokens and their expiry.

function deploy(ERC20 underlying_, uint48 expiry_) external override nonReentrant returns (uint256) {
    uint256 tokenId = getTokenId(underlying_, expiry_);

    // @audit make sure that expiry_ is in the future.

    // Only creates token if it does not exist
    if (!tokenMetadata[tokenId].active) {
        _deploy(tokenId, underlying_, expiry_);
    }
    return tokenId;
}

For the create function, however, it implies that bondTokens would be issue for an already vested bond position.

Impact

In both of the aformentioned cases, having the expiry_ in the past could potentially lead to bad user experience as well as undesired results in terms of bond issuance and redemption.

Recommendations

We recommend implementing checks that would block the issuance or deployment of bondTokens that have an expiry in the past.

require(expiry_ > block.timestamp, "error: expiry is in the past");

Remediation

Bond Labs acknowledged this finding and implemented a fix in commits 4eb523da↗ and 453d02e0↗.