Implement Make Offer Functionality

[jaykayudo]

Description

This PR introduces the Make Offer functionality, which is a core part of the peer-to-peer lending protocol.

The ability for a lender to make an offer on a borrower's collateral listing is a critical interaction that drives the entire lending lifecycle. Securely creating and validating offers ensures the trust, safety, and reliability of the protocol, making this feature essential for core protocol operations.

---

Key Changes:

• Onchain Signature Verification:

  • Validates the authenticity of the offer using StarkNet’s signature verification (starknet.py).
  • Ensures that all parameters (loan terms, collateral information, lender identity, etc.) are properly signed and match the submitted data.

• Listing Status Check:

  • Verifies that the associated collateral listing is active and eligible to receive offers.

• Offer Duration Validation:

  • Confirms that the offer’s loan duration falls within the allowed minimum and maximum duration ranges defined by the protocol.

• Repayment Amount Validation:

  • Ensures that the repayment_amount is greater than the principal (guaranteeing a positive yield for the lender).

• Signature Data Integrity Check:

  • Cross-verifies the offer data integrated into the signature to prevent mismatch attacks or parameter tampering.

---

Why This Is Core Functionality:

• Trustless Interaction:
  Verifying lender offers securely enables borrowers to interact with unknown lenders without requiring trust.

• Protocol Safety:
  Ensures that offers cannot be spoofed, mismatched, or forged, preserving the financial integrity of loans.

• Lifecycle Foundation:
  Making an offer is the starting point of the loan negotiation and execution process. Without reliable offers, no loans can be initiated.

---

Acceptance Criteria:

• Offers must only be accepted if all checks pass.
• Offers with invalid signatures, inactive listings, incorrect durations, or invalid repayment amounts must revert.
• Fully covered by unit tests validating each scenario.

---

Notes:

• This lays the groundwork for secure off-chain offer creation and on-chain offer acceptance.

Related Issue

Fixes #14

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Performance improvement
• Code refactoring
• Documentation update
• Test coverage improvement
• CI/CD related changes

How Has This Been Tested?

• Unit tests
• Integration tests
• Manual testing

Checklist

• My code follows the project's style guidelines
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

Security Considerations

• This PR introduces no security concerns
• This PR modifies authentication/authorization
• This PR handles sensitive data
• This PR modifies financial transaction logic

Performance Impact

• This PR has no significant performance impact
• This PR improves performance
• This PR may impact performance negatively (explain why it's necessary)