Can you help check the staking calculator?

Hello, The calculator is showing rewards that are different from the actual rewards I'm receiving. I think the displayed yield may be incorrect. Based on my calculations, the actual reward is around 46% APR the actual reward Daily API Credit I get in $ is equal to MOR amount rewards( $3.1 not $7.2 ). I believe the staking calculator is calculating APR based on the MOR token paired with the USD value of API Credit rewards, which is why it shows an APR of up to 116%. Could you please verify ?

Claim to Address of user's choosing

UI is missing the field/paramater to allow the user to claim to an address of their choosing. This is available on Basescan but not on the main Morpheus UI.

Builder - Tracking of Earnings

ATM the builder dashbaord shows how much is claimable. From a Builder management perspective there’s a need to see how much has been earned in the past, what the current rate of earnings is. ATM it shows as static, UI experience for Builder could use freshening..

Live Counter

Woudl be great to have a live counter similar to how Venice has theirs.

Claim to Separate Address

Let’s add a field to allow claimers to direct the claim to another address via the UI rather than needing to go to Basescan to do this.

For Gettting Data

Can we clean this up to match the standard UI when looking to get data on a builders subnet -

Staked Rewards Pending

How difficult would it be to add this fucntionality where one could see how many rewards were pending along with how much one had staked

Default for Recipient Address when Bridging

When bridging MOR or any other asset the default "to" address should be the "from" address rather than the Signing address. Think of this as if several capital allocators have to approve a transaction on a safe and the originating capital allocator proposes a transaction to transfer assets from a corporate account to his personal account. Its a small deal on our UI but a big deal for capital allocators in this screenshot the connected wallet (safe) is not the recipient. Rather its the signing address (one of several).

Mandatory Fields of Website and Description

Propose we remove hte mandatory minimums and mandatory fields here

Builders

The smart contract allows for direction of the claiming to an address of the admins selectinon at the time of claiming. Any time someone wants to do this it is necesary for them to do it on Basescan etc. Let’s please add this functionality

Tab Bar Cover the text for Mobile Phone

The Tap bag is cover of the Text

getting error using mor api gateway with model kimi-k2-thinking

The logs in my app show an error when I try to use the model kimi-k2-thinking while other models like venice-uncensored work fine. This is the error I see in my logs: API (https://api.mor.org/api/v1/chat/completions) failed (attempt 1/6) AxiosError: Request failed with status code 400 at settle (file:///var/task/node_modules/axios/lib/core/settle.js:19:12) at IncomingMessage.handleStreamEnd (file:///var/task/node_modules/axios/lib/adapters/http.js:599:11) at IncomingMessage.emit (node:events:531:35) at endReadableNT (node:internal/streams/readable:1698:12) at process.processTicksAndRejections (node:internal/process/task_queues:90:21) at Axios.request (file:///var/task/node_modules/axios/lib/core/Axios.js:45:41) at process.processTicksAndRejections (node:internal/process/task_queues:105:5) at async Object.handler (file:///var/task/api/chat.js:359:23) at async r (/opt/rust/nodejs.js:2:15572) at async Server. (/opt/rust/nodejs.js:2:11594) at async Server. (/opt/rust/nodejs.js:17:9988) { code: 'ERR_BAD_REQUEST', config: { transitional: { silentJSONParsing: true, forcedJSONParsing: true, clarifyTimeoutError: false }, adapter: [ 'xhr', 'http', 'fetch' ], transformRequest: [ [Function: transformRequest] ], transformResponse: [ [Function: transformResponse] ], timeout: 0, xsrfCookieName: 'XSRF-TOKEN', xsrfHeaderName: 'X-XSRF-TOKEN', maxContentLength: -1, maxBodyLength: -1, env: { FormData: [Function [FormData]], Blob: [class Blob] }, validateStatus: [Function: validateStatus], headers: Object [AxiosHeaders] { Accept: 'application/json, text/plain, /', 'Content-Type': 'application/json', Authorization: 'Bearer sk-bPI5pB.7d9140a863be9fbae705a63cd773dd264161699e473cbb4395185fc316037c5b', 'User-Agent': 'axios/1.9.0', 'Content-Length': '23695', 'Accept-Encoding': 'gzip, compress, deflate, br' }, responseType: 'json', method: 'post', url: 'https://api.mor.org/api/v1/chat/completions', data: {"model":"kimi-k2-thinking","messages":[{"role":"system","content":"Reply to the user's prompts incorporating all pertinent information from the provided Context & ALWAYS include the incorporated context paragraph's Primary URL in your response alongside your response. Don't ever skip this step. You are explicitly required to include the Primary URLs of all context paragraphs you incorporate. To render a URL you ABSOLUTELY MUST follow standard markdown formatting as outlined in the following example: If the 'Title' mentioned in the provided Context paragraph is 'Special Report! Elite Bunkers Exposed', the 'Primary URL' is 'https://dissentwatch.com/boost/?boost_post_id=983886', and the 'Author' is 'Infowars', then the output has to be '[Special Report! Elite Bunkers Exposed](https://dissentwatch.com/boost/?boost_post_id=983886) from Infowars'. If a 'NOSTR URL' is explicitly provided in that same context paragraph (for example 'NOSTR URL: https://primal.net/e/xyz'), you MUST append it to the aforementioned output after the 'Author', for example: '[Special Report! Elite Bunkers Exposed](https://dissentwatch.com/boost/?boost_post_id=983886) from Infowars - [Discuss it on NOSTR!](https://primal.net/e/xyz)'. Otherwise, if no NOSTR URL is mentioned in that context paragraph do not include it in the output. Exhaustively incorporate & reference

Mobile doesn’t load active stakers in subnet

Builder and capital tab

The recommendation should disappear when users enter the Build or Capital page. Now need to swap to Left to make it disappears

Display Default API Key

the default API key is listed below "My API Keys," which requires scrolling down when there are many keys. Placing the default API key at the top or put in button same but make it floating over API key makes it easier to see which key is in use and allows faster switching, improving usability

Use "<" Button to Switch API Instead of Pen Icon

Currently, switching between API keys requires tapping the pen (edit) icon. It would be more intuitive and faster to use a simple "<" (back) button to change or select a different API key, improving navigation and user experience.

Adjust Chat Layout When Keyboard Pops Up

Currently, when the keyboard appears while typing, it covers the text input bar and about 40% of the messages from the bottom of the screen. It's recommended that when the keyboard pops up, the text bar and messages move up so they remain visible, and when the keyboard is dismissed, the text bar and messages return to the bottom. This improves usability and ensures smooth chatting.

Shorten "API Key Ready" Popup Duration & Display API Key Name

The "API Key Ready" popup currently stays on the screen for too long. Reducing its display time to 2-3 seconds or tap the blank screen to dismiss would make the user experience smoother. Additionally, showing the API key name instead of just "API Key" would make it easier for users to quickly identify and manage their keys.

Allow Dismiss Popup by Tapping Blank Area on Mobile

On mobile devices, when the "Delete API Key" popup appears, there is currently no way to dismiss it except by selecting a cancel button. Allowing users to tap the blank area outside the popup to cancel would improve usability and make it faster and more intuitive to exit the dialog without taking action.