Security Considerations in the API

Nyvo’s abstraction is powerful, but developers should still be aware of the security model. The internal API ensures that only authorized actions are exposed. For example, the governance module’s API will not provide a direct way to, say, drain the treasury unless the user is recognized as an admin via their wallet. Under the hood, the program will enforce that check, and the API will only allow calling such instruction if the connected wallet matches the required signer. Nonetheless, Nyvo’s documentation (and this guide) encourages developers to use the provided API calls rather than crafting custom transactions, because the API will include the proper safeguards. If custom transactions are needed, developers should carefully follow Solana best practices (which Nyvo’s internal code can serve as a reference for).

In summary, Nyvo’s internal API structure divides responsibilities into clear layers: contract generation, transaction building, and UI components. Each layer abstracts Solana’s complexity:

• Contract generation uses templates/IDL to avoid manual Rust coding.

• Transaction building uses high-level functions to avoid manual instruction encoding.

• UI components tie into wallet and data flow so developers avoid writing boilerplate React+Web3 code.

By leveraging these, even experienced developers can save time and reduce errors, focusing instead on the unique aspects of their application.